Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 8/28/12 1:51 PM, Ian Hickson wrote: I beg of you, let's not make it any more complicated. :-) Amen. Just trying to catch up on what the state of things is now... ;) -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 8/28/12 1:27 PM, Ian Hickson wrote: The latter. The blocking only affects scripts that are "prepare the script"ed by the "top-level" parser, not a reentrant parser. OK. I see. This requires the "blocked by" state to live on an individual script instead of on the document, right? I _think_ right now Gecko blocks all scripts (not just parser-inserted ones) on pending stylesheet loads. Not sure what other UAs do It might not matter for web compat, I guess. (This is in the spec if you want to examine the precise wording I'm proposing here.) I'll do that, sure; I just want to understand intent before I try to see whether the spec matches the intent. ;) -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 28 Aug 2012, Boris Zbarsky wrote: > > Ah, I see. So is what you're proposing that stylesheets that are > inserted by a "nested tokenizer" not block scripts in general, but > stylesheets that are inserted by a top-level tokenizer block scripts as > usual? > > Or is what you're proposing that scripts that are inserted by a "nested > tokenizer" not block on stylesheets? The latter. The blocking only affects scripts that are "prepare the script"ed by the "top-level" parser, not a reentrant parser. (This is in the spec if you want to examine the precise wording I'm proposing here.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 8/28/12 2:12 AM, Ian Hickson wrote: On Tue, 28 Aug 2012, Boris Zbarsky wrote: As far as I can tell, "0 1 2" in your testcase at http://damowmow.com/playground/demos/document-write-and-scripts/002.html is consistent with the following order of execution: 1) x=0 2) x1=0,x=1 (nothing else has run yet because we're waiting on blank.js) 3) setTimeout fires, sets x2 = 1 3) second external script runs, sets x = 2. There's only one external script. The script after the style sheet is internal. Agreed. If it blocks, you get "0 1 2" (when x2 gets set to x in the timeout, it's still x=1, because the next script, which sets x=2, hasn't run). In Gecko, however, that internal script doesn't block, and so the timeout runs after x has been set to 2. Hence "0 2 2". Right. The reason for having the external script in 002.html is that it causes document.write() to return right there Ah, I see. So is what you're proposing that stylesheets that are inserted by a "nested tokenizer" not block scripts in general, but stylesheets that are inserted by a top-level tokenizer block scripts as usual? Or is what you're proposing that scripts that are inserted by a "nested tokenizer" not block on stylesheets? -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 28 Aug 2012, Boris Zbarsky wrote: > On 8/28/12 12:46 AM, Ian Hickson wrote: > > I've updated the spec to not block on style sheets for nested parser's > > scripts. > > I'm not sure I follow. What is not going to block on what with this change? > > As far as I can tell, "0 1 2" in your testcase at > http://damowmow.com/playground/demos/document-write-and-scripts/002.html is > consistent with the following order of execution: > > 1) x=0 > 2) x1=0,x=1 (nothing else has run yet because we're waiting on > blank.js) > 3) setTimeout fires, sets x2 = 1 > 3) second external script runs, sets x = 2. There's only one external script. The script after the style sheet is internal. If it blocks, you get "0 1 2" (when x2 gets set to x in the timeout, it's still x=1, because the next script, which sets x=2, hasn't run). In Gecko, however, that internal script doesn't block, and so the timeout runs after x has been set to 2. Hence "0 2 2". The reason for having the external script in 002.html is that it causes document.write() to return right there (except in IE9, but that's another story, not sure what that's about), so you can tell the difference between how the internal
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 8/28/12 12:46 AM, Ian Hickson wrote: I've updated the spec to not block on style sheets for nested parser's scripts. I'm not sure I follow. What is not going to block on what with this change? As far as I can tell, "0 1 2" in your testcase at http://damowmow.com/playground/demos/document-write-and-scripts/002.html is consistent with the following order of execution: 1) x=0 2) x1=0,x=1 (nothing else has run yet because we're waiting on blank.js) 3) setTimeout fires, sets x2 = 1 3) second external script runs, sets x = 2. So it looks like the second external script in your testcase there is in fact blocking on the stylesheet... or something. And I'm not sure how reconcile that with the behavior at http://damowmow.com/playground/demos/document-write-and-scripts/001.html What am I missing? -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Wed, 6 Jun 2012, Boris Zbarsky wrote:
> >
> > Unless I'm mistaken, nothing in the HTML spec does anything
> > differently based on whether a script comes from document.write() or
> > not. The information about whether a character in the tokeniser came
> > from the network, document.write() during a network parse, or
> > document.write() on a completely script-written document, is not
> > stored along with the character in the tokeniser's input stream.
>
> Oh, I see. The problem with that is situations like this script:
>
> var x = 0;
> document.write("" +
> "
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Thu, Jun 7, 2012 at 2:47 AM, Ian Hickson wrote: > On Fri, 27 Jan 2012, Boris Zbarsky wrote: >> On 1/27/12 1:30 AM, Ian Hickson wrote: >> > On Wed, 5 Oct 2011, Henri Sivonen wrote: >> > > On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky wrote: >> > > > What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 6/6/12 7:47 PM, Ian Hickson wrote: On Fri, 27 Jan 2012, Boris Zbarsky wrote: On 1/27/12 1:30 AM, Ian Hickson wrote: On Wed, 5 Oct 2011, Henri Sivonen wrote: On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky wrote: What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Fri, 27 Jan 2012, Boris Zbarsky wrote: > On 1/27/12 1:30 AM, Ian Hickson wrote: > > On Wed, 5 Oct 2011, Henri Sivonen wrote: > > > On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky wrote: > > > > What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 1/27/12 1:30 AM, Ian Hickson wrote: On Wed, 5 Oct 2011, Henri Sivonen wrote: On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky wrote: What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 4 Oct 2011, Julien Chaffraix wrote: > > following WebKit's attempt at implementing the behavior of |sheet| and > |disabled| per HTML5 / CSSOM [1], we have found that the specs [2] [3] > either under-specify the behavior or do not match what browsers are > doing. The spec has changed a bit since your e-mail; can you check again and see if the improvements are sufficient? > * Opera and FF always have an associated stylesheet if |link.rel| > matches a stylesheet and |href| is set. > * They both fill link.sheet with default values even if the stylesheet > was / ends up in error. This is per the spec now. > * However, FF loads the stylesheet synchronously whereas Opera does it > asynchronously from a JS perspective This is required per the spec: a pending load does block certain scripts from executing. See: http://www.whatwg.org/specs/web-apps/current-work/#has-a-style-sheet-that-is-blocking-scripts > * Some websites (4chan.org for examples) assumes that the |sheet| is > always available and that |disabled| will work properly regardless of > when it is called. This is now per spec as far as I can tell. See: http://www.whatwg.org/specs/web-apps/current-work/#styling On Wed, 5 Oct 2011, Henri Sivonen wrote: > On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky wrote: > > What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 10/5/11 9:01 PM, Julien Chaffraix wrote: Ah. Do they set disabled and expect it to take effect whenever the sheet actually appears? Yes, we have seen some regressions because people were expecting exactly that. So for what it's worth, Gecko implemented the current behavior of creating the stylesheet immediately as soon as we know the is linking to a stylesheet in https://bugzilla.mozilla.org/show_bug.cgi?id=107567 One of the considerations there was in fact allowing pages to change disabled state without having to wait for the sheet to load. That includes things like selection of alternate stylesheet sets working correctly even if not all the alternate sheets have finished loading and so forth... -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
>> Thanks for the explanation. I took a black-box approach in testing - I >> don't pretend to know how Firefox works - and from that perspective, >> it looked like it was synchronous as the |sheet| was present and >> properly populated in JS. > > Try setting an interval to poll right before the is parsed. That > will black-box show that it's not synchronous. ;) I stand corrected. ;) >> It is. However the specification states that |disabled| would be >> ignored if there is no |sheet|. It looks like web-authors don't factor >> this into their code. > > Ah. Do they set disabled and expect it to take effect whenever the sheet > actually appears? Yes, we have seen some regressions because people were expecting exactly that. Thanks, Julien
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky wrote: > What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 10/4/11 5:43 PM, Julien Chaffraix wrote: Thanks for the explanation. I took a black-box approach in testing - I don't pretend to know how Firefox works - and from that perspective, it looked like it was synchronous as the |sheet| was present and properly populated in JS. Try setting an interval to poll right before the is parsed. That will black-box show that it's not synchronous. ;) It is. However the specification states that |disabled| would be ignored if there is no |sheet|. It looks like web-authors don't factor this into their code. Ah. Do they set disabled and expect it to take effect whenever the sheet actually appears? I would totally believe the web depending on that -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
>> * However, FF loads the stylesheet synchronously whereas Opera does it >> asynchronously from a JS perspective > > Uh... Firefox does not load anything synchronously. > > What Firefox does do is block execution of
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 10/4/11 2:41 PM, Julien Chaffraix wrote: * However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective Uh... Firefox does not load anything synchronously. What Firefox does do is block execution of
