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

[whatwg] DOMContentLoaded, load and current document readiness

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 20 Apr 2012 13:43:32 +0300
Message-ID: <CAJQvAucJQE=WjQQ6dsYvjcnr+9EWJkc6T4kB-xNL8qe9RoM0YA@mail.gmail.com>
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

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Friday, 20 April 2012 03:43:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:07 GMT