[whatwg] DOMContentLoaded, load and current document readiness

On Fri, Apr 20, 2012 at 3:43 AM, Henri Sivonen <hsivonen at iki.fi> 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

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.

/ Jonas

Received on Wednesday, 25 April 2012 10:53:35 UTC