Talk:ResourceLoader/Default modules/Archive

HTML and map modules
I mean e.g. this code: var h = mw.html; var loaderContainer = h.element( 'div', { id: 'ext-foobar-loader' },	new h.Raw( h.element( 'img', {		src: mw.config.get( 'stylepath' ) + '/common/images/ajax-loader.gif',		title: 'Loading...'		}	) ) ); // loaderContainer is '  ' What does this suppose to help with? Maybe the example is bad, but this doesn't seem helpful at all. How is this easier then using innerHTML or even DOM methods? Or maybe it does something extra?

The Map module seems to be at least easier to use, but is it really worth the trouble? It doesn't seem store variables in cookies or localStorage then what is it every day scripter?

Regards, Nux 23:51, 13 February 2011 (UTC)

Hmmm...
The entire mw.html bit except possibly escape seems to be completely useless, mw.config doesn't appear to do anything at all, the mw.legacy object is empty, the mw.user object doesn't appear to have most of the properties listed here (and why would they be functions in the first place, exactly?), mw.util.$content is a jQuery bit without any particular reason for it to be, addOnloadHook is replaced with some odd, seemingly inefficient bit of jQuery... Am I missing something here? --Yair rand 07:23, 15 February 2011 (UTC)
 * (Looks at mw.loader.load source) Ummm... O_O --Yair rand 07:38, 15 February 2011 (UTC)
 * Where are you referring to with "doesn't have most properties". Doesn't have X where, on your wiki ? On Wikipedia ? On MediaWiki.org ? 1.17 is still in development so there may be different versions around. The documentation here describes exactly what the latest version can do, no more (sometimes less since documentation is written afterwards).
 * mediaWiki.legacy is empty because, as the deprecation overview explains, the legacy variables are currently deprecated but not quarantined. Right now we leave a clear window for users to update their scripts. The deprecated functions are at their original locations, for now. During this process we check if the given modern and more compatible replacements in the mw.* library cover all cases without regressions compared to the legacy functions. Once that is completed the functions will be quarantined in mw.legacy so that users who hadn't had the time to convert their scripts can map function calls to mw.legacy as a temporary stop-gap.
 * mediaWiki.loader.load is currently primarily focussed on the loading of (multiple) combined and minified resources including the automatic detection of dependancies etc. That's what it does best and does good. Loading external scripts (or internal ones by full url, like in debug mode) is possible but by no meeans awesome. This has been improved a bit in the trunk development but not yet deployed yet on Wikipedia.
 * the mw.html object is by no means useless, but if you don't need it, don't use it. Krinkle 11:27, 17 February 2011 (UTC)
 * Hm, I thought they were all using the same version. Enwiki, Enwiktionary, and Mediawiki.org all only have the options</tt> propery of mw.user</tt>, and don't have anonymous</tt>, name</tt>, or sessionId</tt>. --Yair rand 11:41, 17 February 2011 (UTC)

$.post.complete is not a function
I tried to use .complete in post but throws error. also i get error if i use  (not a bug in edit mode) ( i think i have to use if( $('#editform') ) ?). Sorry this is a cross posting from Village_pump_(technical). Please help. -- Mahir78 08:37, 26 February 2011 (UTC)
 * Please post a more complete snippet, there's no way of knowing what's wrong with just this. Krinkle 21:01, 2 March 2011 (UTC)

textSelection not working outside edit screen
The jQuery.textSelection seems to be entirely unavailable except on the edit screen. (This is something I really wish I had known earlier...) Whatever the reason might have been for this, wouldn't it make sense to have this bit of information on the page, as well as listing other various jQuery bits that die as soon as the user goes onto a different type of page? --Yair rand 08:33, 4 April 2011 (UTC)