Script, style and backwards compatibility

[zcorpan]

Well - this is IMHO unfortunate at best. It sort of makes it impossible to handle all aspects of eg. http://www.w3.org/TR/WCAG/#tech-scripts in XHTML5.

How so? You can have the "noscript" content as the default (without <noscript>), and then modify the DOM with script to remove the "noscript" content and then do whatever the script was supposed to do.

Eh, - Now I'm even more confused. I wouldnt *dream* of placing a document.write based script inside of a <noscript> even in HTML4 !

No, I meant you would do something like:

Code: Select all

<script>
document.write("foo");
</script>
<noscript>bar</noscript>

...where, if scripting is enabled, you would get "foo", and if scripting is disabled, you would get "bar". (I couldn't come up with a good example, but perhaps this is used for some menu scripts or to insert ads or something.)

[edit:] BTW when you say that <noscript> doesn't work in XHTML you surely must mean XHTML5? Seems to me it works just fine in XHTML 1.0 Strict served as application/xhtml+xml to at least some very common browsers like FireFox/Win and Opera/Win (you can try it out at the frontpage of http://xhtml.se if your browser indicates it prefers application/xhtml+xml over text/html)- or maybe I'm missing something obvious ? (in which case I'd be very geratful for some insightful references)

It only works in the sense that it hides the content, it will still be parsed as PCDATA in XML. Consider this example:

Code: Select all

<form>
<noscript><input name="test" value="test"/></noscript>
<input type="submit"/>
</form>

When parsed as text/html with scripting enabled, the noscript element will only contain a text node, i.e. it will be parsed as an CDATA element, and thus there is no text field in the DOM. When scripting is disabled, noscript is parsed as PCDATA, and there will be a text field in the DOM. XML cannot switch parse modes like HTML, so it will always be PCDATA in XHTML.

So, "doesn't work" might be a bit of a stretch, especially since the same applies to e.g. <iframe>. Perhaps it shouldn't be disallowed in XHTML5?

As for a reference, search for "noscript" in the parsing section. (I believe this was either undefined in HTML4, or defined to be something different from what implementors do.)

[Jarvklo]

How so? You can have the "noscript" content as the default (without <noscript>), and then modify the DOM with script to remove the "noscript" content and then do whatever the script was supposed to do.

Well - you *could* do it that way in text/html HTML5 as well - the ability to supply an alternative without a <noscript> alone doesn't motivate excluding <noscript> from XHTML5 while keeping it in HTML5 IMHO

No, I meant you would do something like:

Code: Select all

<script>
document.write("foo");
</script>
<noscript>bar</noscript>

...where, if scripting is enabled, you would get "foo", and if scripting is disabled, you would get "bar". (I couldn't come up with a good example, but perhaps this is used for some menu scripts or to insert ads or something.)

Yeah - and I would like to still be able to use something like

Code: Select all

<noscript>Note: Scripting is disabled in your browser, please refer to our <a href="...">accessibility policy</a> for the implications of this</noscript>

regardless if I work in XHTML5 or HTML5 for the moment.
Following your line of reasoning I'd say that you'd might as well remove <noscript> from *both* HTML5 and XHTML5 (but IMHO *that* would be a rotten idea )

So, "doesn't work" might be a bit of a stretch, especially since the same applies to e.g. <iframe>. Perhaps it shouldn't be disallowed in XHTML5?

BINGO! That's what I wish for!
IMHO having as few differences between HTML5 and XHTML5 as technically possible is a good way to "sell" (X)HTML5 to people like me (i.e. old stubborn farts with a WCAG/XHTML intense background) at least.

As for a reference, search for "noscript" in the parsing section. (I believe this was either undefined in HTML4, or defined to be something different from what implementors do.)

Tried that - All I found besides statements describing that the difference is there was the mentioning of "historical reasons" without reference or motivation so I still felt I needed to ask

[zcorpan]

Well - you *could* do it that way in text/html HTML5 as well - the ability to supply an alternative without a <noscript> alone doesn't motivate excluding <noscript> from XHTML5 while keeping it in HTML5 IMHO

Indeed. The difference is that in HTML5 you can use document.write(), plus that <noscript> is parsed differently whether scripting is enabled or not. Using document.write()+<noscript> is simpler and possibly safer than document.write()+DOM methods to remove "noscript" content, or DOM methods for both insertion and removal. In XML, using DOM methods is the only option for insertion (well and .innerHTML), and <noscript> content will still contain real elements, running the risk of e.g. submitting form controls that only were intended to be submitten when scripting was disabled.

[Jarvklo]

Well I honestly don't see document.write() as the only vehicle around for implementing "AJAX-library based thingies" that results in script based, user interaction driven, insertion mechanisms ... X or no X prefix on the HTML

Noscript, however, is IMHO, the only 100% safe (and at the same time elegantly simple) way to get to the user in an environment where scripting is disabled.

Perhaps I'm just jaded by trying to grasp the current state of affairs in the "mobile CSS"- arena, but relying on a script to hide a passage using script inserted CSS properties triggered "on document load" seems less reliable to me these days than using noscript

Anyway - and either way in my *very* humble opinion - handling noscript the same way in both XHTML5 and HTML5 is the important suggestion here.

[zcorpan]

Well I honestly don't see document.write() as the only vehicle around for implementing "AJAX-library based thingies" that results in script based, user interaction driven, insertion mechanisms ... X or no X prefix on the HTML

That's not what I said, though. I said that I thought document.write() was the primary use-case for using <noscript>, and since document.write() doesn't work in XML... (I could be mistaken -- Anne suggested that using <img src=tracker> in <noscript> was the primary use-case for <noscript>, which might or might not work in XML (if it works, it's because display:none images aren't fetched).)

Noscript, however, is IMHO, the only 100% safe (and at the same time elegantly simple) way to get to the user in an environment where scripting is disabled.

However, scripting being enabled doesn't imply that the script works. For instance, if the script uses XMLHttpRequest but the browser doesn't support that, but has scripting enabled, then the user would end up with neither of the script or <noscript>. If you only removed the "noscript" content with script if the script was successful, then the user would always end up with one or the other.

e.g.:

Code: Select all

<p id="target">fallback</p>
<script>
var xhr = new XMLHttpRequest();
var elm = document.getElementById("target");
xhr.open("GET", "foo");
xhr.onreadystatechange = function() { 
  if (xhr.readyState == 4 && xmlhttp.status == 200)
    elm.innerHTML = xhr.responseText;
}
xhr.send(null);
</script>

...instead of:

Code: Select all

<p id="target"></p>
<script>
var xhr = new XMLHttpRequest();
var elm = document.getElementById("target");
xhr.open("GET", "foo");
xhr.onreadystatechange = function() { 
  if (xhr.readyState == 4 && xmlhttp.status == 200)
    elm.innerHTML = xhr.responseText;
}
xhr.send(null);
</script>
<noscript>fallback</noscript>

Perhaps I'm just jaded by trying to grasp the current state of affairs in the "mobile CSS"- arena, but relying on a script to hide a passage using script inserted CSS properties triggered "on document load" seems less reliable to me these days than using noscript

I didn't refer to hiding content with CSS on load, but rather removing it from the DOM altogether using e.g. removeChild() or innerHTML.

[Jarvklo]

Fair enough.
And like I said

Anyway - and either way in my *very* humble opinion - handling noscript the same way in both XHTML5 and HTML5 is the important suggestion here.

Further elaboration on the rest of the details I happily leave to better qualified scripting experts than me

[Jarvklo]

Hate to be a pain..., but I feel I have to pitch in another two cents here to extend my argument for a "regardless of serializations" handling of noscript.

To me it seems like it's actually the HTML5 spec that introduces changes to the <noscript> element that turns it into something that cannot be handled from XHTML5.
Now - I'm sure there are good reasons for this, but I'm still not sure that I see them yet. And I'm definately not convinced that the reasons for introducing such a barrier between HTML5 and XHTML5 (that also affects at least some interpretations of "good practices" based on what WCAG1 says about using noscript) are strong enough.
Please bare with me!

In HTML it is parsed differently depending on whether scripting is enabled or not. That cannot be done with an XML parser.

In XHTML1.0, the content type of nosctipt is either %Block; or %Flow; depending on if you are using "Strict" or "Transitional".
In XHTML 1.1 it's " (Heading | List | Block)+"

Either way, this suggests that any "generic XML parser" must treat the content of <noscript> as simply "some markup that follows some rules", and that there has to be some type of "additional semantic handling step" in the parsing/"compiling" process that prunes the resulting - generic - XML DOM if you want the result to behave like XHTML (i.e. noscript node excluded if scripting disabled or not present) and not just "semantics outside of the DTD/Schema neutral" XML.

Now what I don't understand is why a model is chosen for HTML5 that excludes noscript from XHTML5 *by design*.

You mention that XML parser cannot change parsing based on - basically - an exernal setting (eg. "Scripting enabled")
If you are familiar with SAX this could be accomplished for XHTML 1.x whithout much inconvenience actually (i.e. set up event handlers that simply "ignore the content and balance the depth of noscript elements" as they go along). If you load everything into a generic DOM tree, XSLT could be used to prune either the <script> or <noscript> parts of a tree before it's passed on to "execution of semantics" (i.e. issue http-requests for imaages, execute script blocks etc. etc. etc.).

Now, I don't mention this to imply anything than "Hate to bother you, but if I'm not entirely mistaken it *can* actually be done under some circumstances".

My point is - as you also mentioned actually zcorpan, I just didn't pick it up at the time - that <noscript> is not the only element with "extra semantics" that cannnot be expressed in generic XML and therefore needs "an extra step" to be handled from an XML perspective, but it non the less actually works, today and in practice, in XHTML sent as "application/xhtml+xml"

And - Again - Please make noscript either work in both HTML5 and XHTML or chuck it out of both.

Thanks for listening (again)

[zcorpan]

The parsing section was written by reverse engineering what browsers do. The goal here is to achieve interoperability. Unless I'm mistaken, parsing <noscript> as CDATA when scripting is disabled, and as PCDATA when scripting is enabled, is something that all browsers already do. If we already have interop on something, it seems unwise to specify something different.

Parsing XHTML5 is nothing more than parsing XML with namespaces. We already have interop here as well: <noscript> is always parsed as PCDATA by all XML processors, without exception. It seems unwise to require XHTML-aware UAs to modify the DOM after parsing or ignore some parse events, since that would mean that the parsed tree would be different depending on whether the UA is XHTML-aware or not.

To put it in another way, what is specified as to what UAs have to do is largely what they are already doing.

With this situation, it is still possible to allow authors to use <noscript> in XHTML5, it's just that it will contain elements if you put elements inside... (UAs could still apply display:none when scripting is disabled.)

My point is - as you also mentioned actually zcorpan, I just didn't pick it up at the time - that <noscript> is not the only element with "extra semantics" that cannnot be expressed in generic XML and therefore needs "an extra step" to be handled from an XML perspective, but it non the less actually works, today and in practice, in XHTML sent as "application/xhtml+xml"

I'm not sure I understand what you mean here. No element is given special treatment in XML from the UA's perspective, AFAICT.

[Jarvklo]

We already have interop here as well: <noscript> is always parsed as PCDATA by all XML processors, without exception.

To put it in another way, what is specified as to what UAs have to do is largely what they are already doing.

Do me a favour - Fire up Opera 9 or FireFox 2 on Windows.
Disable scripting and point your browser to http://xhtml.se.

Once you've done that please explain to me again why the linked word "Jag" in the noscript section works as a link (and the p elements withing noscript as paragraphs) in both Opera and FireFox (yes I content negotiate so I send application/xhtml+xml for those browsers - also indicated by the use of PI-inclusion of the stylesheets on that site when using application/xhtml+xml).

Perhaps I do something there that I shouldn't be doing with a noscript that could explain why we don't seem to live in the same reality right now - if not, ... well ...

[zcorpan]

We already have interop here as well: <noscript> is always parsed as PCDATA by all XML processors, without exception.

To put it in another way, what is specified as to what UAs have to do is largely what they are already doing.

Do me a favour - Fire up Opera 9 or FireFox 2 on Windows.
Disable scripting and point your browser to http://xhtml.se.

Once you've done that please explain to me again why the linked word "Jag" in the noscript section works as a link

Because <noscript> is parsed as PCDATA (just like any other element in XML). This is also the case when scripting is enabled, i.e. the link will be there in the DOM regardless. It is thus when scripting is enabled that handling of <noscript> differs between HTML and XML. Look in the DOM inspector in Firefox.

[Jarvklo]

OK - I see the missing piece of my puzzled puzzle now Thanks for your patience and your help.

Now all that's left for me then, is to wait and see how it turns out in the end

[zcorpan]

http://lists.whatwg.org/pipermail/whatw ... 11893.html

[Jarvklo]

Indeed...

Like the Swedish saying goes: "Goddag yxskaft"

[zcorpan]

HTML5 now includes an example for how to use <noscript> and how to do the same thing without <noscript>.
http://www.whatwg.org/specs/web-apps/cu ... pt-element

Also, lang="" is now allowed in XHTML5, and xml:lang="" is now allowed in HTML5, <base href> is allowed in XHTML5, <meta charset="utf-8"/> is allowed in XHTML5 (but only for utf-8).