<noscript> type attribute

[avapoet]

A problem that affected us somewhat during the IE/Netscape browser wars and which could conceivabley happen again is that a user agent may support some but not all of the scripting languages used by a web application. This was most obvious when Microsoft were pushing for VBScript/JScript support early this decade. There is no reason that, if additional scripting languages for the web were developed, that they could be expected to be universally supported overnight.

I would propose that the <noscript> tag has an optional "type" element, which, if specified, would cause the <noscript> tag to be ignored only if the user agent supports and is configured to run scripts of the type requested.

For example, a code block beginning <noscript type="text/javascript"> would only be displayed if the user agent did not support JavaScript, or JavaScript was turned off. The browser would still, potentially, execute other script types.

The ultimate aim of this would be to provide future-proof web applications as (and if) new scripting languages become available, by providing less-ideal fallback languages during the migration period. For example, if a new scripting language (represented here by a fictional language served as type "text/supernewlanguage"), both effecient new supernewlanguage and fallback retro javascript support could be provided with the following code:

Code: Select all

<script type="text/supernewlanguage">
  // supernewlanguage is supported
  superNewLanguageCode();
</script>

<noscript type="text/supernewlanguage">
  <!-- supernewlanguage is not supported -->
  <script type="text/javascript">
    // javascript alternative
    javascript_alternative();
    more_code_for_js_alternative();
  </script>

  <noscript type="text/javascript">
    <!-- javascript isn't supported either -->
    <p>
      I'm sorry, but javascript support (or, better yet, super
      new language support) is required to use this web
      application.
    </p>
  </noscript>

</noscript>

This could, of course, be extended as deep as is necessary. This provides the capability for sites to be backwards compatible as new languages are made available.

Unfortunately, such a change would require several changes to the specification, including the permitting of embedding <noscript> tags.

[zcorpan]

I think there are multiple problems with your proposal.

1. It's a theoretical problem. Catering for possible future scripting languages before they exist isn't useful, because you don't know what the needs are should a new scripting language get into use.

2. It's harder to get interop between implementors when the processing rules are more complicated. We don't quite have interop today wrt noscript handling, so complicating matters more doesn't help to achieve interop.

3. Even with only JS, there is seldom a need to use noscript (see the XHR example in the other thread). If a new scripting language is introduced, it can deal with fallback itself without <noscript>.

4. Noscript elements can't be nested not for theoretical reasons but for practical reasons. When a noscript is "ignored", it means that it is parsed as CDATA, which means that the first matching end tag will close the element. So it really cannot be nested.

[Sander Aarts]

I would propose that the <noscript> tag has an optional "type" element, which, if specified, would cause the <noscript> tag to be ignored only if the user agent supports and is configured to run scripts of the type requested.

For example, a code block beginning <noscript type="text/javascript"> would only be displayed if the user agent did not support JavaScript, or JavaScript was turned off. The browser would still, potentially, execute other script types.

I agree. As long as the <script> tag has a type attribute, it seems most logical that the <noscript> tag should have one as well.

About the fallback of languages: I guess there are other solutions for that (the first language that is supported assures that others will be blocked).

[zcorpan]

I agree. As long as the <script> tag has a type attribute, it seems most logical that the <noscript> tag should have one as well.

Logics aside, what is the use-case? What is the processing model? (Note that with the current processing model it is not possible to nest noscript elements.)

[Sander Aarts]

Logics aside, what is the use-case? What is the processing model?

The use-case is that if there is another front-end scripting language you can have a no-script alternative for the language that is not supported by the used browser.
For the <script> tag it might be important for technical reasons, but in case of <noscript> it's important for the content: what behaviour is not supported (in case you use more than one language) and what alternative content should be presented for that behaviour?
Still logics perhaps, but I don't see why that's a problem, talking about a digital medium

(Note that with the current processing model it is not possible to nest noscript elements.)

As I said: "I guess there are other solutions for that...". So nesting <noscript> tags is not an issue for me.

[Stevie D]

For example, a code block beginning <noscript type="text/javascript"> would only be displayed if the user agent did not support JavaScript, or JavaScript was turned off. The browser would still, potentially, execute other script types.

Everywhere else, type="…" is used to indicate the MIME type of the enclosed or referenced content. So logically, you would have to put <noscript type="text/html">, because that describes the content of the <noscript> element.

If you are worried about catering for different scripting languages, perhaps a better option is to include a <div> with an id or class, containing the text that would have been in the <noscript>, and then use the script to remove that <div> from the DOM if the script is activated.