<noscript> validation with XHTML problem

[Burton Figg]

My homepage, www.jimpix.co.uk uses transitional XHTML.

The whole thing validates except one line:

<noscript><im g height="1" width="1" alt=""
src="http://u0.extreme-dm.com/0.gif?tag=riggo tt&amp;j=n" /></noscript>

I get this error on this page:

http://validator.w3.org/check?uri=ht...w.jimpix.co.uk

Line 106, column 18: document type does not allow element "noscript" here;
missing one of "object", "applet", "map", "iframe", "button", "ins", "del"
start-tag

this is pointing to the start of the <noscript> tag.

I need the code to enable a site tracker I use (XTreme Tracking).

I have had a look on usenet and the web, but can't find anything to help
solve it.

Thanks

Jim

[Jim Ley]

On Wed, 31 Dec 2003 12:27:56 +0100, Anne van Kesteren
<ma**@annevanke steren.nl> wrote:

Nick Kew wrote:

Can't check while I'm offline, but that probably means you've put
<noscript> in an inline element. I expect you'd also get a more
helpful error message from Page Valet or the WDG Validator.

Correct. <noscript/> may not appear within <font/> or any other inline
element.

<font/> shouldn't appear at all on a page, but that is a different subject.

Neither should noscript... and for much better reasons than font,
font is unlikely to get in the way of the content of the document,
script is and by virtue of having noscript, it's clear that the author
is relying on the script working, something that is never guaranteed.
<NOSCRIPT/> should be removed.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Jukka K. Korpela]

ji*@jibbering.c om (Jim Ley) wrote:

by virtue of having noscript, it's clear that the author
is relying on the script working, something that is never guaranteed.
<NOSCRIPT/> should be removed.

(I wonder why people use notations like <NOSCRIPT/> - maybe because
slashes make _everything_ better? :-) )

The HTML 4.01 specification says, somewhat oddly,

"The NOSCRIPT element allows authors to provide alternate content when
a script is not executed. The content of a NOSCRIPT element should only
be rendered by a script-aware user agent in the following cases:
- The user agent is configured not to evaluate scripts.
- The user agent doesn't support a scripting language invoked by a
SCRIPT element earlier in the document."

This looks self-contradictory, isn't it? If all SCRIPT elements contain
scripts in a language supported by the browser, and the browser is
configured to execute scripts, then the latter part says, very clearly,
that a browser must not render NOSCRIPT content. No matter what happens
when the browser tries to execute the scripts.

But apparently the solution is that the first sentence is just sloppy
language and should be ignored, or interpreted so that "a script is not
executed" _means_ what the text says later.

As far as I know, browsers deal with it even more simplistically. They
render NOSCRIPT content if and only if configured not to execute
scripts. And in a sense this is much simpler.

But you're right in saying that authors _expect_ scripts to work. On
the other hand, what could they do? NOSCRIPT is not supposed to solve
all the problems in the world, or even all the problems with scripts.
Just some of them.

The NOSCRIPT element is poorly designed, and so is SCRIPT. For example,
if you wish to include HTML elements that are present only when
scripting is enabled (e.g., a button that works via scripting only),
you need to take the clumsy way of generating it with document.write( ).

But NOSCRIPT is occasionally useful. For example, if a page essentially
relies on JavaScript being enabled, it is better to say that than to do
nothing about the problem, and NOSCRIPT lets the author do that without
disturbing people who have scripting enabled.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Jim Ley]

On Sun, 4 Jan 2004 23:29:08 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tu t.fi> wrote:

As far as I know, browsers deal with it even more simplistically. They
render NOSCRIPT content if and only if configured not to execute
scripts. And in a sense this is much simpler.
I've certainly seen more advanced behaviour than this.
But you're right in saying that authors _expect_ scripts to work. On
the other hand, what could they do?
Use the appropriate scripting techniques. Visit comp.lang.javas cript
for discussion on them.
The NOSCRIPT element is poorly designed, and so is SCRIPT. For example,
if you wish to include HTML elements that are present only when
scripting is enabled (e.g., a button that works via scripting only),
you need to take the clumsy way of generating it with document.write( ).
Well yes, but you're assuming that having a button appearing when
scripting is enabled is a good idea, it's not generally, it would only
be appropriate where you're refusing to provide any fallback for that
functionality.. (and neither do you need to rely on document.write,
not that there's anything wrong with document.write of course)
But NOSCRIPT is occasionally useful. For example, if a page essentially
relies on JavaScript being enabled, it is better to say that than to do
nothing about the problem, and NOSCRIPT lets the author do that without
disturbing people who have scripting enabled.

Except of course you then leave people who the script errored for not
knowing anything (especially if they aren't informed about script
errors, the default in most UA's.) Much better to hide the message
reporting that script is required as a side effect of the script
working.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/