W3C home > Mailing lists > Public > www-html@w3.org > November 2003

The case against <noscript> (was: <link> vs. <script> for external scripts)

From: Ernest Cline <ernestcline@mindspring.com>
Date: Fri, 21 Nov 2003 13:42:22 -0500
Message-ID: <410-2200311521184222531@mindspring.com>
To: "Toby A Inkster" <tobyink@goddamn.co.uk>
Cc: "W3C HTML List" <www-html@w3.org>

> [Original Message]
> From: Toby A Inkster <tobyink@goddamn.co.uk>
> On Thu, Nov 20, 2003 at 10:00:56AM -0500, Ernest Cline wrote:
> | Toby A Inkster <tobyink@goddamn.co.uk> wrote:
> | 
> | > I'm not even entirely sure that we need <noscript/>. What about:
> | >
> | > <body
> | > 	<h1>Example</h1>
> | > 	<p id="noscript">This paragraph acts more or less the same as a
> | > 	<code>&lt;noscript/&gt;</code> element.</p>
> | > </body>
> | 
> | And what if a user has scripting enabled, but styles disabled?
> | Then the "noscript" elements would still be displayed which is not
> | what is desired..
> I did indeed think about this shortly after posting the message. I
> don't have a great deal of DOM knowledge (getElementById and
> changing the style properties is about as complex as it gets for me)
> although I'm pretty sure there is a way to completely delete a node
> from the DOM.

So in other words, you want to replace the use of the <noscript> element
with requiring the author to write a custom DOM modifying script when he
wishes to provide alternate content when scripting in the language of his
choice is not supported?  All I see are more buggy pages and larger
resource sizes to accomplish a relatively easy task.  Still, taking a longer
look has convinced me that there are alternatives to custom scripts that
might eliminate or reduce the need for the <noscript> element in XHTML2.

  <p type="text/javascript" src="example.js">
    This paragraph acts more or less the same as a
    <code>&lt;noscript/&gt;</code> element.

With embedding supported for most elements in XHTML2,
any use of <noscript> involving external scripts can be handled
via the fallback mechanism provided by embedding.

The only uses of <noscript>not covered by embedding
occur with internal scripts and with independent <noscript> elements.

Support for independent <noscript> elements was needed in HTML4
since the way they were handled there meant that they could not be
restricted from occurring only after a <script> element.  With the
XHTML2 Script Module calling for associated <noscript>'s
to embedded inside instead of after the <script>, independent
<noscript>'s need be supported only if there is a need for them.
 I can't see a need for them, but they could be simulated via
embedding an empty external script, so unless someone can
provide a use case where they would see common use, I would
support allowing <noscript> only as part of the content model
of <script>.

Thus we are left with the use of case of providing alternative content
for internal scripts.  However, with <noscript> being moved from
occurring after to occurring inside its associated <script> element,
does it matter what that containing element is called?  Is there any
real difference between:




?  Both are just as easy to parse.  Both present the same problems
created by putting the <noscript> element inside the <script>.
First off, are the two separate PCDATA regions supposed to be
considered part of the same script or two separate scripts?
If the same script, what effect does the intervening element
have on the data sent to be parsed for the scripting language?
Received on Friday, 21 November 2003 13:42:22 UTC

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