Re: [whatwg] DOMContentLoaded, load and current document readiness
On Wed, Aug 29, 2012 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 17 Jun 2012, Jonas Sicking wrote: 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? Different from what it says now in the way you propose above (having appendChild-inserted script src element exection delay DOMContentLoaded). That's not what I'm suggesting. I'm suggesting that script defer src=... and script defer elements appearing in the markup and parsed by the parser should always run before DOMContentLoaded firing. This appears to be what Firefox does, and I would expect that the web depends on this. For example I would expect defered to contain document.write which should not blow away the current page. / Jonas
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Thu, 30 Aug 2012, Jonas Sicking wrote: On Wed, Aug 29, 2012 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 17 Jun 2012, Jonas Sicking wrote: 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? Different from what it says now in the way you propose above (having appendChild-inserted script src element exection delay DOMContentLoaded). That's not what I'm suggesting. I'm suggesting that script defer src=... and script defer elements appearing in the markup and parsed by the parser should always run before DOMContentLoaded firing. This appears to be what Firefox does, and I would expect that the web depends on this. For example I would expect defered to contain document.write which should not blow away the current page. That's what the spec says, no? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Thu, Aug 30, 2012 at 11:30 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 30 Aug 2012, Jonas Sicking wrote: On Wed, Aug 29, 2012 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 17 Jun 2012, Jonas Sicking wrote: 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? Different from what it says now in the way you propose above (having appendChild-inserted script src element exection delay DOMContentLoaded). That's not what I'm suggesting. I'm suggesting that script defer src=... and script defer elements appearing in the markup and parsed by the parser should always run before DOMContentLoaded firing. This appears to be what Firefox does, and I would expect that the web depends on this. For example I would expect defered to contain document.write which should not blow away the current page. That's what the spec says, no? I thought so, but the comments in this thread made me think otherwise. If that's the case then I'm happy. / Jonas
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Thu, 30 Aug 2012, Jonas Sicking wrote: That's what the spec says, no? I thought so, but the comments in this thread made me think otherwise. If that's the case then I'm happy. I strongly recommend only believing what the spec says, not what is said in threads. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Sun, 17 Jun 2012, Jonas Sicking wrote: 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? Different from what it says now in the way you propose above (having appendChild-inserted script src element exection delay DOMContentLoaded). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Wed, Jun 13, 2012 at 11:21 PM, Ian Hickson i...@hixie.ch wrote: 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. Different in what way? From what? / Jonas
Re: [whatwg] DOMContentLoaded, load and current document readiness
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Fri, Apr 20, 2012 at 3:43 AM, Henri Sivonen hsivo...@iki.fi 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 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. / Jonas
Re: [whatwg] DOMContentLoaded, load and current document readiness
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 -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] DOMContentLoaded, load and current document readiness
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. Note that 'readystatechange' events do fire synchronously with 'readyState' changes so you can always just use that instead of 'DOMContentLoaded' and 'load'. I haven't changed 'pageshow', so you could still get code running between 'load' and 'pageshow'. Let me know if you think we should merge those into one task as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
