<noscript> validation with XHTML problem

Burton Figg wrote:

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

The whole thing validates except one line:

<noscript><img height="1" width="1" alt=""
src="http://u0.extreme-dm.com/0.gif?tag=riggott&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.

As far as I can see the <noscript> is a child of a <p> element, if you
look at the definition for <p> you will find
<!ELEMENT p %Inline;>
with
<!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*">
and with
<!ENTITY % misc.inline "ins | del | script">
and with
<!ENTITY % inline "a | %special; | %fontstyle; | %phrase; |
%inline.forms;">
and none of those contain the <noscript> element which only occurs in

<!-- these can only occur at block level -->
<!ENTITY % misc "noscript | %misc.inline;">

so basically <noscript> is not allowed inside of a <p> element.

Of course your content is text/html and existing browsers for that
content type use tag soup parsers and don't care about placement of the
<noscript> element.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Burton Figg wrote:

My homepage, www.jimpix.co.uk uses transitional XHTML.
Out of curiousity, why xhtml and not html? and why transitional and
not strict?
The whole thing validates except one line:

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

I get this error on this page:

Line 106, column 18: document type does not allow element "noscript" here;
missing one of "object", "applet", "map", "iframe", "button", "ins", "del"
start-tag
The noscript element's child must be a block level element. <img> is
inline.
I need the code to enable a site tracker I use (XTreme Tracking).
That sounds unfortunate.
I have had a look on usenet and the web, but can't find anything to help
solve it.

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

--
Brian
follow the directions in my address to email me

Brian wrote:

Burton Figg wrote:

My homepage, www.jimpix.co.uk uses transitional XHTML. I get this error on this page:

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

The noscript element's child must be a block level element. <img> is
inline.

With the transitional document type the noscript content is flow which
allows inline or block content.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Martin Honnen wrote:

Brian wrote:

Burton Figg wrote:

My homepage, www.jimpix.co.uk uses transitional XHTML. I get this error on this page:

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

The noscript element's child must be a block level element.
<img> is inline.

With the transitional document type the noscript content is flow
which allows inline or block content.

Oops. My bad. I've never used html transitional, and am unfamiliar
with its dtd. I failed to consider that noscript might be different
in regards to allowed content. My apologies.

--
Brian
follow the directions in my address to email me

Martin Honnen wrote:

Brian wrote:

The noscript element's child must be a block level element.
<img> is inline.

With the transitional document type the noscript content is flow
which allows inline or block content.

I must say, upon reflection, I'm puzzled by this. Why is inline
content allowed in the transitional dtd, but not in the strict one? I
don't see this as a presentational (x)html issue.

--
Brian
follow the directions in my address to email me

Brian wrote:

With the transitional document type the noscript content is flow
which allows inline or block content.

I must say, upon reflection, I'm puzzled by this. Why is inline
content allowed in the transitional dtd, but not in the strict one? I
don't see this as a presentational (x)html issue.

Becuase the difference between Transitional and Strict is not just about the
removal of presentational markup.

--
David Dorward <http://dorward.me.uk/>

In article <bs**********@titan.btinternet.com>, one of infinite monkeys
at the keyboard of "Burton Figg" <so*****@somewhere.com> wrote:

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

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.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

On Tue, 30 Dec 2003 13:49:28 +0000 (UTC), "Burton Figg"
<so*****@somewhere.com> wrote:

The whole thing validates except one line: [...]this is pointing to the start of the <noscript> tag.

Martin has pointed out your specific problem - but as a general rule,
validators never point out where the error _is_, they point out the
place where the error becomes obvious. The thing causing it is almost
always earlier on in the input.

--
Klein bottle for rent. Apply within.

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.

--
Anne van Kesteren
<http://www.annevankesteren.nl/>

On Wed, 31 Dec 2003 12:27:56 +0100, Anne van Kesteren
<ma**@annevankesteren.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.javascript FAQ - http://jibbering.com/faq/

ji*@jibbering.com (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

On Sun, 4 Jan 2004 23:29:08 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.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.javascript
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.javascript FAQ - http://jibbering.com/faq/