- From: Russ Thomas <rthomas@easynet.co.uk>
- Date: Wed, 16 Jul 1997 10:34:09 +0100
- 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): <snip> 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 <NOSCRIPT>. ================== 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> <noscript> uh... I'm confused... </noscript> </script> 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