https://bugzilla.wikimedia.org/show_bug.cgi?id=27488
--- Comment #27 from Happy-melon <happy.melon.w...@gmail.com> 2011-04-11 11:47:46 UTC --- (In reply to comment #26) > (In reply to comment #25) > Site JS and user JS should be at top. Users and site administrators load > libraries in their script and they must be read at least on doc.ready and (as > shown in attached test results) this will NOT be guaranteed when they are in > the footer. Again, this is a solution to the immediately apparent problem, not to the problem which actually needs to be solved. Users need to be able to modularise their code, load it via ResourceLoader, and indicate which modules need to be available before rendering. > Also legacy JS is in fact a library that must also be ready before the page is > loaded. On the contrary, it is usually completely useless before page rendering. It only needs to be ready early if it is a dependency for a module which itself needs to be ready early. > I think you should add Mediawiki:com...@footer.js (or similar) so that scripts > that can be moved would be moved by site administrators. Again, this is not taking advantage of the full power of ResourceLoader's modularisation. > This is not true - it doesn't degrade performance. It makes the page start > appearing slower which is not the same. To the 99% of users who do not have extra all-singing, all-dancing JavaScript widgets playing with their interface, slower page loading is a reduction in performance. > Users will mostly want to have scripts > loaded before they work on a page (as shown before). So this might be true in > some cases, but is not a general truth and I find it as a dangerous myth. You and all the people you know to ask might well agree on this. John Smith the Wikipedia reader who wants to know what type of plug they use in the country he's going on holiday to, doesn't give a damn. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
