- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 30 Aug 2012 03:07:09 -0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org
On Wed, Aug 29, 2012 at 8:34 PM, Ian Hickson <ian@hixie.ch> wrote: > On Sun, 17 Jun 2012, Jonas Sicking wrote: >> > On Wed, 25 Apr 2012, Jonas Sicking wrote: >> >> >> >> Hmm.. how long as that been the case? I thought that when we >> >> originally implemented @defer we ran them before DOMContentLoaded was >> >> fired for various internal sanity reasons as well as because it gave >> >> authors better migration paths. >> >> >> >> It seems nice to me to be able to depend on that all scripts have run >> >> by the time that DOMContentLoaded is fired. Except for async scripts >> >> of course, which are always unreliable as to when and which order >> >> they execute. I.e. async scripts is an explicit footgun, but I'd >> >> rather have fewer of those. >> > >> > I haven't changed the spec here. I don't really see what we gain by >> > making the "stop parsing" algorithm different in this way. >> >> Different in what way? From what? > > Different from what it says now in the way you propose above (having > appendChild-inserted <script src> element exection delay DOMContentLoaded). That's not what I'm suggesting. I'm suggesting that <script defer src="..."> and <script defer> elements appearing in the markup and parsed by the parser should always run before DOMContentLoaded firing. This appears to be what Firefox does, and I would expect that the web depends on this. For example I would expect defered to contain document.write which should not blow away the current page. / Jonas
Received on Thursday, 30 August 2012 06:08:07 UTC