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

See http://hsivonen.iki.fi/test/moz/readystate/defer-script.html

Henri Sivonen
hsivonen at iki.fi
Received on Friday, 20 April 2012 03:43:32 UTC

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