W3C home > Mailing lists > Public > www-html-editor@w3.org > July to September 1997

Re: The Problem With <NOSCRIPT>

From: Russ Thomas <rthomas@easynet.co.uk>
Date: Wed, 16 Jul 1997 10:34:09 +0100
Message-Id: <199707160944.KAA17770@orange.easynet.co.uk>
To: <hwg-newtech@hwg.org>, <www-html-editor@w3.org>, "Rev. Bob" <rev-bob@full-moon.com>
How True...
From: Rev. Bob <rev-bob@full-moon.com>
To: hwg-newtech@hwg.org; hwg-html@hwg.org; www-html-editor@w3.org
Date: Tuesday, July 15, 1997 04:52
Subject: The Problem With <NOSCRIPT>

Has anyone else noticed the fundamental flaw in the <NOSCRIPT> tag as
currently implemented?  Consider the following page (sans DOCTYPE):


The HTML 4.0 draft specification only makes matters worse.  It
depreciates the use of the LANGUAGE attribute for <SCRIPT> in favor of
the TYPE attribute.  Y'know, JavaScript 1.0, 1.1, and 1.2 ALL share the
"text/jss" MIME type!  THIS DOES NOT HELP.

Here's what I propose.  Before the LANGUAGE attribute can be
depreciated, it needs a replacement that will adequately substitute for
the information that it provides.  To that end, I propose allowing the
<NOSCRIPT> tag to take the TYPE attribute, as well as developing a new
VER (version) attribute that would apply to both <SCRIPT> and
Yes, that's workable I believe.  Yet in a multi-scripting environment it may
prove messy - maybe?  If NOSCRIPT was by definition associated with SCRIPT
(aliken this to FRAMESET/NOFRAMES) then a disassociated pair matching need not
take place...

<title>Document Title</title>
<script [who_cares]>Boogedy!<br>
uh... I'm confused...
End of text.

In this model, there is no need to match attr pairs

Anyone see any holes here?

Further - in XML it would be possible to "point" all NOSCRIPTs to one place.
Think the same is almost true with CSS... need to think about that one tho'.

Russ Thomas
Received on Wednesday, 16 July 1997 05:37:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:08:19 UTC