Re: XTHML 1.0 Strict validation of noscript

> jkorpela@cs.tut.fi wrote:
>
> It is advisable to drop the "<!--" stuff, which is nothing
> but useless technobabble copied from old documents and no
> books. [...] Far from protecting anything, the technobabble
> creates a pointless risk.

Well, they use it at w3schools:

http://www.w3schools.com/tags/tag_noscript.asp

:P

Actually I rarely use them in my pages (at least not since 2000), but this
is an old page that I'm updating, the comment was there, w3schools seemed
to agree and the validator didn't complain, so I left it.

> The real reason is that you have <noscript> inside a <p> element.
> That's not allowed.

But a <script> is?

Considering that in 99% of cases a <noscript> will be used to provide an
alternative to the output of a <script>, why allow one and not the other?

>> So why do I have to enclose it in an <ins> container (for example)?
>
> You don't. That would be a wrong move. First, it would be semantically  
> wrong markup, because it's not really inserted content in the sense of  
> being an addition to a previous version. Second, the document would  
> definitely violate HTML specifications, [...] "The INS and DEL elements
> must not contain block-level content

And in this case it doesn't. The contents of the <noscript> block in this
case is all inline (text and / or an image). But I agree about the
semantics. Or do you mean <noscript> is block? Is that the issue here?
<noscript> is block while <script> is inline? Again, I don't think that
makes much sense, but it would explain it. I thought <noscript> was
inline. It's certainly treated as inline by all the main browsers.

In the few situations where <noscript> doesn't immediately follow a
<script>, it would still make more sense as an inline element. Ex.:

<p>Scripting support in your browser is <noscript>not</noscript>
enabled.</p>

I realise this isn't an issue with the validator itself.

> Using <noscript><div><img ...></div></noscript> would be syntactically  
> OK (though not what you want, since <div> implies a line break before  
> and after, as any block element does).

Exactly.

> Assuming you wish to make the greeting a <p> element
> (it's not really a paragraph by my book,

The greeting is _part_ of a paragraph (I didn't copy all the code). But,
as you say, that's not the point.

> This need for duplication might be regarded as a design
> flaw in HTML.

Wouldn't it be simpler for validators to simply ignore the <noscript> tags
(other than checking if they are properly closed, etc.), and treat their
contents as if they were inside the _parent_ element? Isn't that
effectively what all browsers do? Or would this be tricky to specify in a
DTD?

If it _would_ be possible to define that in the DTD, it seems odd that the
XHTML DTD specifically defines a behaviour contrary to the way this
element is used in the vast majority of cases in the real world.

> Actually, it now occurred to me that you could simply have e.g. the  
> content
>
> <p>Hello <span id="userref">dear user</span>, and welcome to our  
> site.</p>
>
> and a <script> element containing code that modifies the text content of  
> the <span> element.

Yes, I know (although I can think of some cases where that wouldn't work),
but as a general rule I don't like to use JavaScript to modify element
contents, so I was hoping there was a way to "explain" to the validator
that the <noscript>'s contents would simply be part of the parent <p>, and
should therefore be validated in that context. Guess not.

>> The weird thing is that I'm pretty sure the first version of the code  
>> validated fine two weeks ago, and the validator only started  
>> complaining recently.
>
> Such things often happen. You have changed something and you cannot  
> quite trace back what the change was that made the markup invalid.

No, the <noscript> has always been there, and it was always inside a <p>.
Maybe the doctype was different. Would a <noscript> be allowed inside a
<p> using Transitional HTML?

Anyway, thanks for the explanation, although I still think this behaviour
makes no sense (but the issue lies with the XHTML DTD, not the validator).

RMN
~~~

Received on Sunday, 15 October 2006 20:57:31 UTC