- From: <bugzilla@jessica.w3.org>
- Date: Sun, 24 Feb 2013 03:29:23 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21074 --- Comment #9 from Kyle Simpson <w3c@getify.myspamkiller.com> --- I personally don't understand the need to avoid the `onload` blocking (and I happen to have plenty of experience in this area, as the author of LABjs script loader). I think the far bigger culprit is blocking the DOMContentLoaded event, and thankfully all the `async` and dynamic-script-element approaches take care of that part. That having been said, even if I don't see the need for this, PLEASE do not piggyback on, and/or change, in any way, how `async` works (as I saw suggested in this thread). There are many, MANY script loaders, mine included, which rely on very specific behavior of `async`. It's a very tenuous and delicate balance we're currently in, where it barely works, but works just well enough. On a side note, I doubt this request is going to get very far, because I have been trying to get another helpful change (script preloading: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14194) made to the script loading behaviors of the browser for well over 2 years now, and keep getting stonewalled on it, mostly for the "just tell authors to do something different" excuse. I think the same fate is likely here, that they'll just say "why can't you just tell authors not to load stuff before `onload` if they don't want to block `onload`... wait until after it passes to start the loading." I know, and you know, that's suboptimal compared to what you're asking for itself, but it's the same reasoning as what has blocked my requests for ages. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 24 February 2013 03:29:25 UTC