[whatwg] DOMContentLoaded, load and current document readiness

[Ian Hickson]

On Thu, 30 Aug 2012, Jonas Sicking wrote:
> On Wed, Aug 29, 2012 at 8:34 PM, Ian Hickson <ian at 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?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'