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

On Wed, Jun 13, 2012 at 11:21 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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.

Different in what way? From what?

/ Jonas

Received on Sunday, 17 June 2012 02:14:21 UTC