[whatwg] DOMContentLoaded, load and current document readiness
Ian Hickson
ian at hixie.ch
Wed Jun 13 14:21:07 PDT 2012
On Fri, 20 Apr 2012, Henri Sivonen wrote:
> On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson <ian at 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list