W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 17 Jun 2012 04:13:18 +0200
Message-ID: <CA+c2ei96_vm-7C5LdhcVnWyhoo7Gb-8mXNGuNaoFK4YQDYCYLg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Henri Sivonen <hsivonen@iki.fi>, whatwg@whatwg.org
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC