Re: Recommended Processing model for NOSCRIPT element

>     <noscript>
> 
>      JavaScript is not supported!!!

This is an abuse of <noscript> and has no place in an example.  As such,
I think it reflects a false premise in the rest of the text.  (<noscript>
should provide alternative implementations of the function, not complain
about the users configuration.)

I would say that it was bad design practice to mix scripting languages.
If one wants to provide an ECMAScript fallback for VBScript coding
(I'm not sure why, as the object model is common to all scripting
languages, and is the cause of the security concerns, and ECMAScript
is a de facto lowest common denominator), what one needs is an extension
to the object models to allow the scripts to detect the presence of the
other language.

I would say the only sensible clarification would be to require 
<noscript> to only take effect if all scripting options are unavailable.

Received on Thursday, 30 January 2003 02:49:26 UTC