- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 30 Aug 2012 11:45:32 -0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org
On Thu, Aug 30, 2012 at 11:30 AM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 30 Aug 2012, Jonas Sicking wrote: >> 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. > > That's what the spec says, no? I thought so, but the comments in this thread made me think otherwise. If that's the case then I'm happy. / Jonas
Received on Thursday, 30 August 2012 14:46:36 UTC