Re: [whatwg] DOMContentLoaded, load and current document readiness

On Fri, 20 Apr 2012, Henri Sivonen wrote:
> On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Tue, 31 May 2011, Henri Sivonen wrote:
> >>
> >> Recently, there was discussion about changing media element state in 
> >> the same task that fires the event about the state change so that 
> >> scripts that probe the state can make non-racy conclusions about 
> >> whether a certain event has fired already.
> >>
> >> Currently, there seems to be no correct non-racy way to write code 
> >> that probes a document to determine if DOMContentLoaded or load has 
> >> fired and runs code immediately if the event of interest has fired or 
> >> adds a listener to wait for the event if the event hasn't fired.
> >>
> >> Are there compat or other reasons why we couldn't or shouldn't make 
> >> it so that the same task that fires DOMContentLoaded changes the 
> >> readyState to "interactive" and the same task that fires load changes 
> >> readyState to "complete"?
> >
> > Fixed for 'load'. I don't see a good way to fix this for 
> > 'DOMContentLoaded', unfortunately.
> 
> It turns out that Firefox has accidentally been running defer scripts 
> after DOMContentLoaded. I haven't seen bug reports about this. Embracing 
> this bug might offer a way to always keep the readystatechange to 
> "interactive" in the same task that fire DOMContentLoaded.
> 
> See http://hsivonen.iki.fi/test/moz/readystate/defer-script.html

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.

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

Received on Wednesday, 13 June 2012 21:22:29 UTC