Anne van Kesteren

noscript per HTML 4.01

There are about two people that care about this stuff. So if they can please pay attention. Here is a very basic noscript element testcase. It tests some of the functionality described for the noscript element in HTML 4.01. Because it is quite vaguely defined and it is not clear which noscript elements are in scope this section is basically found unimplementable. Yet there is no errata to make it more clear: HTML WG, where art thou? However, there is a catch. Opera does have an implementation of this!

After some more testing it turns out that Opera looks at the next Element sibling when it does not understand the script. If that Element happens to be a noscript element its contents will be rendered. Testcases have been written with this in mind. So the earlier in the document statement from HTML 4.01 section 18.3.1 second point is implemented as the first previousSibling of nodeType1” that also happens to have a nodeNamescript” in Opera. Glad we cleared that up.

Comments

  1. I'm the second one? Right.

    • Opera follows the HTML 4.01 specification for script and noscript. If any script element doesn't execute, all subsequent noscript element are displayed.

    (From http://www.opera.com/docs/specs/opera6/#html)

    Has this been changed in Opera 9?

    Posted by Krijn Hoetmer at

  2. A note on Krijn Hoetmer's Javascript: some MIME types page:

    The "text/ecmascript" MIME type works for me using Firefox 1.5. It displays "Working." in green under the MIME type name.

    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

    Only "text/jscript","text/vbscript" and "text/fluffscript" failed the test. You're right about the <noscript> element not working to spec in Firefox 1.5, though. Neither does IE 6.0. The interesting thing about IE, though is that it doesn't seem to work on my system for the MIME type "text/vbscript". Odd.

    Posted by Matthew Raymond at

  3. The noscript tag is silly anyway; it was designed to complement the (lack of) Javascript in a browser.

    To be really useful (or at least to solve problems like this) you should either be able to attach it to a certain script element with either the 'for' attribute (the preferable option) or putting noscript inside the script element (which would cause problems with unobtrusive Javascript).

    An attribute to link noscripts to scripts would offer a lot more flexibility in the following case:

    [script type="application/blah-script"][/script] [script type="application/javascript-script"][/script] [noscript]which script does it refer to? JS/Blah or both?[/noscript]

    Note: Addding a type attribute to the noscript element would still be limiting when multiple scripts are used. Also, the multiple script problem is far - far - more likely to occur than different script problems in most cases.

    Posted by James / AkaXakA at

  4. does the noscript tag work at all for Opera ?

    Posted by Stanley Smith at

  5. What might be useful would be to specify a MIME type in the noscript element, and if that type of script isn't supported, then the alternate content could be shown. For example:

    
    <script type="application/javascript" src="foo.js"></script>
    <script type="text/vbscript" src="bar.vb"></script>
    

    Then, later in the document:

    
    <noscript type="application/javascript">
    <p>alternate content for javascript...<p>
    </noscript>
    

    I also like the idea of a for attribute to explicity associate script and noscript elements.

    Posted by Lachlan Hunt at

  6. Or write unobstructive scripts.

    Posted by me at

  7. I had to temporarily unsubscribe from your feeds in bloglines, as it saw <noscript> in the title as an html tag, leaving everthing after it unrendered.

    Posted by Sjoerd Visscher at

  8. Lachlan - sure, but what about multiple scripts?

    Posted by James / AkaXakA at

  9. Krijn: the old implementation caused double sets of adverts to appear all over the web when a bit of vbscript was used for plugin sniffing and Opera would consequently both run scripts and show NOSCRIPT for the rest of the document. Current implementation is better.

    Posted by Hallvord at

  10. I had to temporarily unsubscribe from your feeds in bloglines, as it saw <noscript> in the title as an html tag, leaving everthing after it unrendered.

    So that explains it! Quick, someone alert Phil Ringnalda, we've found another annoying thing to add to all his post titles.

    Back on topic: I am not one of those two people. On reflection, I've decided that I quite like that about my life.

    Posted by Mark at

  11. Great! Yet more inconsistency. This one was new to me. How do you find time to find these little things out?

    @James: Good idea but a bit of an overhead for something that is hardly implemented.

    Posted by Edward Clarke at

  12. The most obvious and flexible solution would be to have both a FOR and TYPE attribute on the NOSCRIPT element. That would allow you to couple a given NOSCRIPT element with a given SCRIPT element through the FOR attribute, and allow for more general NOSCRIPT elements tied up with a given MIME type in the TYPE attribute.

    An elegant "hack" would of course be to use FOR for both cases: <noscript for="#my-script">...</noscript> and <noscript for="text/javascript">...</noscript>. A bit messy, perhaps, but so is two attributes.

    Posted by Asbjørn Ulsberg at

  13. ...the earlier in the document statement from HTML 4.01 section 18.3.1 second point is implemented as the first previousSibling of nodeType “1” that also happens to have a nodeName “script” in Opera.

    This would logically extend to say if ANY CONSECUTIVE previous-siblings of node-type "1" that also happend to have a node-name "script".

    Or to put it another way, perhaps, any [script] element with an un-recognised type attribute value should fail to the next [script] or [noscript] element sibling.

    This is all the more poingant now that Eolas and Micrsoft have decided that the world didn't have enough trouble with literal object embedding msdn article.

    Posted by Nick Breen at

  14. There is a "validator" page at http://validator.w3.org/
    which complained about using the paragraph markers:
    <body onload="firstfocus()">
    <!-- (firstfocus is my initial JavaScript function) -->
    <p>
    <script type="application/javascript"></script>
    <!--
    //(my JavaScript code is actually in the <head> block,
    // because I recall the browser choking on "firstfocus"
    //when not located in the page before the function is called,
    //like a "no prototype found error" in the C language.
    //But that was a couple years ago;
    //I suppose I should test to see if the conundrum is fixed.)
    // -->
    <noscript>This Page requires JavaScript support.</noscript>
    </p>
    <form>
    </form>
    </body>

    I think it's because the paragraph markers are outside the <form> section, but I still have lots to learn about this stuff. The validator did not complain when I removed the paragraph tags, and my Mozilla browser also correctly displayed the "JavaScript required" message when JavaScript was disabled. IE's security settings has an "Active Scripting - disable" option, which just plain doesn't seem to work for me, so I don't know if it would show the noscript message. I don't have Opera, but FireFox works, and I expect SeaMonkey also to work.

    Posted by Vernon Nemitz at