Noscript Processing

[Guest FirefoxRocks]

I initially thought that browsers that understood scripts and had scripting enabled would ignore contents within <noscript> elements.According to the HTML4 specification:

18.3.1 The NOSCRIPT element ... (snip)... Start tag: required, End tag: required The NOSCRIPT element allows authors to provide alternate content when a script is not executed. The content of a NOSCRIPT element should only be rendered by a script-aware user agent in the following cases:

• The user agent is configured not to evaluate scripts.
• The user agent doesn't support a scripting language invoked by a SCRIPT element earlier in the document.

User agents that do not support client-side scripts must render this element's contents. In the following example, a user agent that executes the SCRIPT will include some dynamically created data in the document. If the user agent doesn't support scripts, the user may still retrieve the data through a link.

<script type="text/tcl"> [i]...some Tcl script to insert data...[/i]</SCRIPT><NOSCRIPT> <P>Access the <A href="http://someplace.com/data">data.</A></NOSCRIPT>

But in HTML5, it says:

Outside of head elements, if scripting is enabled for the noscript element The noscript element must contain only text, except that the text must be such that running the following algorithm results in a conforming document with no noscript elements and no script elements, and such that no step in the algorithm causes an HTML parser to flag a parse error:...snip...The noscript element has no other requirements. In particular, children of the noscript element are not exempt from form submission, scripting, and so forth, even when scripting is enabled for the element.

The part I'm particularly concerned about is that children of the noscript element are not exempt from form submission even when scripting is enabled. So supposing my form looks like this:

<form id=something action=somepage.php method=post>    <p>         <label for=user>Username</label> <input type=text name=user id=user maxlength=48>        <br>        <label for=pass>Password</label> <input type=password name=pass id=pass maxlength=64>         <noscript><p><input type=hidden name=a value=true></noscript>     <p> <button type=submit>Login</button></form>

Does that mean that even with scripting enabled, a POST request will be sent for "a"?In my PHP script, I'm checking for:

<?php if(isset($_POST["a"]) && $_POST["a"]==="true") { /* some stuff */ } else { /* some stuff */ } ?>

This means that if the browser submits the hidden input in the noscript, it will always flag is set and true in PHP, which defeats the whole purpose.Yes, I know that I can test it out, I can use Firebug to monitor the data sent, etc. But HTML5 might change the behaviour of the browsers so I need clear confirmation on this.I know I can write JavaScript to set the value of the hidden input to something else, so if a certain value is passed then JavaScript is enabled, otherwise JavaScript is not. But do I really have to do this?

[Guest FirefoxRocks]

Does no one know the answer to this or what?

[Ingolme]

Well, if that's what the specification says, then it's how it should be.It's still early to be looking at HTML 5, in my opinion. But if you wanted to be sure things worked properly, you could use a script to look through all the <noscript> tags and delete all the content within.

The noscript element must contain only text

I'd say you're not actually supposed to have form elements inside the <noscript> tag, if it's only supposed to have text.

[Guest FirefoxRocks]

Well if the <noscript> element must contain text, that doesn't make sense because you can't put inline elements or text directly within a noscript element. And for some reason my page validates. And HTML5 is supposed to be compatible with existing browsers (like the stuff that already exists, not the new stuff), and <noscript> has been around since HTML 4, so I'm wondering about this...

[Synook]

I suppose they want you to take a bottom-up approach to compatibility as opposed to a top-down one...