W3C home > Mailing lists > Public > www-validator@w3.org > December 1998

RE: Bug? Javasvript and the <p> tag

From: Jukka Korpela <jkorpela@cc.hut.fi>
Date: Tue, 15 Dec 1998 09:37:49 +0200 (EET)
To: www-validator@w3.org
Message-ID: <Pine.OSF.3.96.981215092502.21863A-100000@beta.hut.fi>
On Tue, 15 Dec 1998, Brian Gilkison wrote:

> It is my understanding that a <NOSCRIPT>...</NOSCRIPT> definition
> qualifies as a block-level element

That is correct. The ultimate references are the DTDs, where NOSCRIPT
occurs (apart from its own declaration) only in the declaration for
the entity %block. This means that NOSCRIPT may only occur within
an element for which the content model contains %block. See
for an explicit list.

The validator error message (referring to </P> for a P element
which is not open) is adequate, but not always easy to understand.
One needs to learn that NOSCRIPT is a block-level element and thereby
has implicitly closed the open P element. I don't think there is
much one could improve in the diagnostics, though. An attempt to
keep track of implicitly closed P elements and to refer to such
an element (which of them? the last one before the error?) when
reporting to a homeless </P> might sometimes help the author in seeing
the problem; but in other cases it might be very misleading.

In practice, if an author wishes to write a paragraph where some
text fragment is either generated by a client-side script or
a static fallback (for situations where client-side scripting is not
supported or not enabled), it seems that one needs to write
alternatives for the entire paragraph. That is, there would be
a SCRIPT element which generates the paragraph and a NOSCRIPT
element which contains the static fallback.

Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Received on Tuesday, 15 December 1998 02:37:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:58:11 UTC