On Fri, 20 Apr 2012, Henri Sivonen wrote: > On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson <i...@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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
