[whatwg] <noscript> should be allowed in <head>

Ian Hickson ian at hixie.ch
Thu Jun 21 01:59:18 PDT 2007


On Tue, 29 May 2007, David Hyatt wrote:
>
> WinIE allows it, and we just changed WebKit to allow it too.

Done. However, the way the spec does it (in order to be consistent with 
everything, and to enable sane conformance checking) is rather different 
to how you do it. You might want to reimplement your <head> parsing to be 
more like the spec, in due course. (Though I recommend waiting a while for 
this to settle down.)


On Wed, 30 May 2007, Anne van Kesteren wrote:
> 
> So what exactly do you do when scripting is _disabled_ in this case? For 
> instance with <noscript><p></noscript> or <noscript><b></noscript>?

The <noscript> element in the <head> in the spec autocloses when it hits 
anything that isn't a <link>, <style>, <head>, <html>, comment, space, or 
end tag.


On Tue, 29 May 2007, David Hyatt wrote:
>
> We'd have to decide if <noscript> reopens across closures of <head>.

I don't think we need it to reopen. Round-tripping of broken content is 
already not going to work in many cases.


On Wed, 30 May 2007, Simon Pieters wrote:
> 
> I tested this briefly.
> 
>   http://simon.html5.org/test/html/parsing/noscript-in-head/

Nice.


> For reference, the input documents were:
> 
> 
> 001-BL
>   <!doctype html><head>X</head><body>Y</body>
> 
> 001
>   <!doctype html><head><noscript>X</noscript></head><body>Y</body>
> 
> 002-BL
>   <!doctype html><head><link title="A">X<link
>   title="B"></head><body>Y</body>
> 
> 002
>   <!doctype html><head><noscript><link title="A">X<link
>   title="B"></noscript></head><body>Y</body>
> 
> Results:
> 
>                               .innerHTML
> 
> Test |                   IE7                    |         Opera
> -----+------------------------------------------+-----------------------
> 001- | <HEAD></HEAD>                            | <HEAD><BODY>XY
> BL   | <BODY>XY</BODY>                          |
> -----+------------------------------------------+-----------------------
> 001  | <HEAD><NOSCRIPT></HEAD>                  | <HEAD><BODY>XY
>      | <BODY>X</NOSCRIPT>Y</BODY>               |
> -----+------------------------------------------+-----------------------
> 002- | <HEAD><LINK title=A></HEAD>              | <HEAD><LINK
> BL   | <BODY>X<LINK title=B>Y</BODY>            | title="A"><BODY>X<LINK
>      |                                          | title="B">Y
> -----+------------------------------------------+-----------------------
> 002  | <HEAD><NOSCRIPT><LINK title=A></HEAD>    | <HEAD><LINK
>      | <BODY>X<LINK title=B></NOSCRIPT>Y</BODY> | title="A"><BODY>X<LINK
>      |                                          | title="B">Y
> 
> In Firefox, <noscript> always imply <body>.

So Opera drops <noscript> altogether (not an option), Firefox doesn't 
support <noscript> in <head> (also not an option, given the whole point 
here is to support that), and IE creates non-tree DOMs. Horrah.


> If we want to allow NOSCRIPT in HEAD, then it seems to me that the most 
> logical way to parse non-HEAD content inside it (which would be a parse 
> error) is to pop the NOSCRIPT element and then reprocess as if it was 
> found in HEAD directly.

That's what I did (though I did it for some head content too; let me 
know if you think there are use cases for the other cases).


On Wed, 30 May 2007, Ivo Emanuel Gonçalves wrote:
>
> I'm not in favor of this.
> 
> As Anne pointed out, <noscript> is used to display alternative content 
> that <script> would have shown.  The kind of content that goes only in 
> <body>, usually block elements, and never in <head>.
> 
> If the WebKit developers want to follow IE's broken model on parsing 
> even basic HTML like <noscript>, be my guest, but don't try to force 
> this into HTML 5 and make it a standard.

<noscript> in <head> is useful for changing the CSS shown.


On Wed, 30 May 2007, Lee Kowalkowski wrote:
> 
> You could include a style sheet for non-JS visitors.  Especially useful 
> if either using javascript in CSS (using expression() in IE), or more 
> commonly seen when people hide elements by default and reveal them using 
> JS (bad practice I know but prevents potential flicker and jiggle).

Indeed.


> Perhaps some layouts don't make sense when JS isn't available, so a 
> different layout entirely is desired.  Authors may prefer this to 
> keeping all the JS and non-JS version styles in one style sheet and 
> class name switching to indicate JS is available.

Indeed.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


More information about the whatwg mailing list