XHTML2.0 and the noscript element.

Apologies for not replying directly to the relevant message; I am not 
subscribed to this list. Please CC me on any replies.

I wrote [1]:
 >Is this element necessary? Shouldn't the onus be on document authors 
 >and script authors to ensure that documents function appropriately
 >whether scripts are executed or not? The functionality of noscript
 >(only rendering certain content when scripts are unavailable) is easily
 >duplicated by approaching the problem from the other direction:

To which Jonny Axelsson replied [2]:
 >It is better to specify this in a declarative fashion, this makes the
 >relation clearer to non-scripting user agents as well as user
 >agents/programming languages that don't support DOM. One goal is also
 >to link noscripts to a specific script, probably with nesting, e.g.
 >
 > <script type="text/perlscript" src="a.pl">
 >   <script type="text/pythonscript" src="a.pt">
 >     <noscript>Neither Perl nor Python supported</noscript>
 >   </script>
 > </script>

Linking noscript to a specific script is a good idea - I'm in support of 
this one. I'm not sure I like the nesting approach though - how about 
using an id-based mechanism, similar to that used for form 
labels/controls in previous versions of (X)HTML? For example:

<script id="myScript" type="text/javascript" src="script.js" />

<noscript for="myScript">
   <p>Javascript not supported.</p>
</noscript>

The 'for' attribute could be either of type IDREF or IDREFS. This 
decouples things more, allowing authors to keep their scripts in the 
document head (which I find a much cleaner approach compared to 
scattering scripts throughout the document), whilst having the noscript 
elements placed appropriately within the body. It also would allow for 
multiple noscript elements referring to the same script - so if for 
example a given script handled two tasks, two separate noscript elements 
could be used (conceivably at very different places in the document). 
This also could allow the noscript element to refer to a script included 
with the link element - which is impossible under the mechanism you've 
described.

The concept of being able to nest scripts is something I don't see as 
much need for. I presume the intention in the example you gave is for 
the user agent to attempt to download and run the perl version, and if 
(and only if) this is not possible, due to file not found or perl not 
enabled, attempt to download and run the python version. I can't say 
I've ever seen a need for this sort of functionality - and given the 
prevalence of javascript on the web, I daresay it would see very little use.

I'd also like to state my support for deleting the 'src' attribute from 
the script element - this functionality can be achieved with the 'link' 
element.


Chris Mannall


[1] http://lists.w3.org/Archives/Public/www-html/2002Aug/0017.html
[2] http://lists.w3.org/Archives/Public/www-html/2002Aug/0023.html

Received on Thursday, 8 August 2002 10:50:41 UTC