Proposal:Reinstate noscript in XHTML5(application/xhtml+xml)

[Jarvklo]

* What is the problem you are trying to solve?
The current version of the HTML5-specification breaks backwards compatibility for noscript in XHTML5 by forbidding it's use entirely in XHTML serializations (XML Documents) of DOM5 documents.
The problem primarilly affects existing pages authored in XHTML 1.1, XHTML Basic or XHTML Mobile Profile that adheres to the guidelines of the W3C "mobileOK" initiative. By various accounts the number of pages at that follow the W3C "MobileOK" guidelines are growing fast, and the "mobile best practices" guidelines encourages the use of "proper" XHTML MIME-types and for example recommends against XHTML MP being served as text/xhtml.

Furthermore, noscript is mentioned as a means to improve/ensure accessibility in eg. WCAG 1.0 and Swedish Governement Accessibility guide "Vägledningen 24-timmarswebben 2.0". And even though both are subject to updates that will not explicitly name elements, several sites are still following these versions of the respective guidelines that explicitly recommends noscript for some accessibility purposes.


The problem is that the current definition of script and noscript risks breaking XHTML pages that uses noscript for accessibility reasons while served as something other than text/html.


* What is the feature you are suggesting to help solve it?
Redefine script and noscript in a way that makes it possible to use noscript in XHTML5 serialisations that equals the possibilities to use it in HTML5 serializations. I.e. make sure they work in an equal way regardless of the authors choice of serialization format.

* What is the processing model for that feature, including error handling? This should be very clear, including things such as event timing if the feature involves events, how to create graphs representing the data in the case of semantic proposals, etc.
The approach described in section 9 of the the OMA XHTML MP 1.1 Specification http://www.openmobilealliance.org/relea ... 1020-A.pdf is hereby suggested.

* Why do you think browsers would implement this feature?
To ensure backwards compatibiity (i.e. not risk breaking existing "proper" XHTML web pages) and not needlessly introduce diverging behaviour for a well established element only in documents served as application/xhtml+xml.
The pages at risk are most likely mainly "mobile web pages" that follows/needs to follow both current W3C "mobile OK" best practices and W3C content accessibility guidelines but all the same currently uses scripts together with a noscript alternative.

* Why do you think authors would use this feature?
noscript is mentioned as a means to improve/ensure accessibility in eg. WCAG 1.0 and Swedish Governement Accessibility guide "Vägledningen 24-timmarswebben 2.0". even though both are subject to updates, several sites are still following the guidelines recommending noscript in these.

noscript and it's current behaviour (i.e. that it works predictably in both "proper" XHTML and HTML) is, simply put, well established on the web and is still needed regardles of which MIME-type the author prefers.


* What evidence is there that this feature is desparately needed?
Several sites use noscript today for various accessibility reasons regardless of markup dialect.
The need to build accessible websites is as urgent for sites serving HTML(text/html) as it is for sites serving XHTML dialects (application/xhtml+xml or application/vnd.wap.xhtml)

The need for accessibility and backwards compatibility is not limited to "the desktop web" but is also a reality for pages built especially for "the mobile web".

[Cerbera]

Sorry, but the W3C's mobile best practise stuff is rubbish. Mobile phones don't need XHTML. Also, any browser has to have text/html support for users to access any significant amount of web content. A browser without that support could only access a tiny fraction of the documents published on the web, and therefore be poor value for money (and probably quite useless) to end users.

My understanding of <noscript> is that its purpose is more effectively handled using unobtrusive scripting techniques. Zcorpan has given examples of these in previous proposals about this, IIRC. But I'm no scripting expert, so maybe there are cases which unobtrusive scripting cannot handle but <noscript> can?

Are the "various accounts" you mention available online anywhere?

[zcorpan]

Jarvklo and I talked about this briefly when we met at geekmeet yesterday.

You said that the point of this thread was to make sure that your proposal to make <noscript> allowed in XHTML5 wouldn't be lost -- you don't necessarily want to actually change the behaviour of how browsers parse <noscript> in XML today, as you suggest in this thread. Correct?

That proposal was forwarded to the WHATWG list and is on Hixie's stack of feedback that he will deal with in due course.

[Jarvklo]

Zcorpan >> Yeah I guess that about sums it up

[Jarvklo]

Sorry, but the W3C's mobile best practise stuff is rubbish.

Hmm.. The MWI seems supported by several of the mobile device manufacturers I know of as well of some other well known and respected companies (like Opera software for example). "rubbish" you say? Perhaps. I respect your having that opinion on this but humbly disagree (obviously ).

Mobile phones don't need XHTML. Also, any browser has to have text/html support for users to access any significant amount of web content. A browser without that support could only access a tiny fraction of the documents published on the web, and therefore be poor value for money (and probably quite useless) to end users.

I'm not arguing against browsers needing support for text/html.
I'm arguing that content negotiated to be "preferably served" as application/xhtml+xml should be allowed to use noscript also in the future. Noscript "works" in content served as application/xhtml+xml today, and IMHO should continue to "work" even when the content served after negotiation will be XHTML5 instead of XHTML1.
Especially since noscript will be allowed in HTML5 and XHTML5 served as text/html. The reasons for my having this opinion I hope are made clear by my proposal.

My understanding of <noscript> is that its purpose is more effectively handled using unobtrusive scripting techniques. Zcorpan has given examples of these in previous proposals about this, IIRC. But I'm no scripting expert, so maybe there are cases which unobtrusive scripting cannot handle but <noscript> can?

I don't argue against any of that since it seems to be a reasonable conclusion.
But if that conclusion is an important enough reason to exclude noscript from one serialization, it's probably as important a reason to exlude it from *all* serializations in order to acheive the "unified language" that will replace both HTML and XHTML. Again, my humble opinion of course

Are the "various accounts" you mention available online anywhere?

Certainly. You could for example browse through the news from the MWI or their sponsors.
You will also find references to statistics claiming that the number if "mobile browsers" installed "outh there" is about to outnumber the number of desktop installations here and there in "the realm of the .mobi" and in the general news.

Constructively yours
/Åke Järvklo

[Cerbera]

Calling the guidelines "rubbish" was a rather imprecise, sorry.

• They don't match the reality of current mobile browser capabilities.
• They have contradictory advise (one web page for all devices versus XHTML Mobile Profile).
• They don't add anything on top of existing best practise for creating websites.

So I think justifying <noscript> in terms of W3C's Mobile Best Practise is a bit weak. There could be other justifications, of course.

I looked through the news to the 4th page and some Press Releases but couldn't find those stories. Could you provide direct links to them, please?

Good point about how unobtrusive scripting solves the <noscript> cases more elegantly in text/html as well as XML formats. This means it isn't necessary for accessibility, making that justification a bit weak as well. UAs still need to support <noscript> in text/html because it too common too ignore. I didn't think it was common in XML formats, but perhaps it is after all.

As I understand it, XML parsers are intended to be as straightforward as possible and require no "knowledge" of the markup they are working with. In contrast, text/html parsers are inevitably complex and already need "knowledge" of HTML to process it. A difference between the two serialisations could be appropriate to maintain the integrity and simplicity of XML?

Do you know whether the XML implementations which allow <noscript> are conforming to the XML specification?

[Jarvklo]

[...] So I think justifying <noscript> in terms of W3C's Mobile Best Practise is a bit weak. There could be other justifications, of course.

OK. I respect you having that opinion. I just don't agree since I see them actually being used. But whatever. This will not likely change since both are opinions
The MWI supplies a "MOBILE OK" validator that advocate "no text/html". People tend to use validators every once in a while and follow their advice. Noscript is "working" if you serve XHTML "as XML" today. The use of noscript is advocaded through (at least some prominent) accessibility guidelines. Like you say - Noscript is too commonly used to exclude from (X)HTML5. The current spec removes any possibility to use noscript (if you wish to produce conformant code) if you wish to continue to serve your content as application/xhtml+xml. I find that very unfortunate. Thats all.

I looked through the news to the 4th page and some Press Releases but couldn't find those stories. Could you provide direct links to them, please?

Look again. I've read enough of them lately to note the trend - I didn't keep the links or recall exactly where since I didn't expect to be forced to enter them as evidence in a cross-examination style debate - and I don't stock-pile newspapers.

Good point about how unobtrusive scripting solves the <noscript> cases more elegantly in text/html as well as XML formats. This means it isn't necessary for accessibility, making that justification a bit weak as well. UAs still need to support <noscript> in text/html because it too common too ignore. I didn't think it was common in XML formats, but perhaps it is after all.

Fair enough

As I understand it, XML parsers are intended to be as straightforward as possible and require no "knowledge" of the markup they are working with. In contrast, text/html parsers are inevitably complex and already need "knowledge" of HTML to process it. A difference between the two serialisations could be appropriate to maintain the integrity and simplicity of XML?

Of course I agree with the last statement - Anyone with even a basic understanding of XML does I think
But I don't agree that the statement needs to cover the script/noscript issue.

It's an opinion. Offered as constructive feedback.
IMHO the "issue" is technically solveable if you deem it important enough to be solved equally for HTML5 and XHTML5.

That's all. Really.

[mogmios]

My understanding of <noscript> is that its purpose is more effectively handled using unobtrusive scripting techniques. Zcorpan has given examples of these in previous proposals about this, IIRC. But I'm no scripting expert, so maybe there are cases which unobtrusive scripting cannot handle but <noscript> can?

One reason I use the noscript tag is to switch stylesheets for users without scripting. This is handy if you want to have elements look a certain way for users with scripting that wouldn't work for users without scripting. Every scripting method I've tried to do the same thing with results in a visual flicker, in some browsers, as the styles are changed whereas noscript results in a flicker-free experience. Unless there is going to be some way to force scripting to run before the page is displayed to the user, or tell the browser to use or not use different stylesheets based on the availability of scripting, I think noscript is useful.

[zcorpan]

One reason I use the noscript tag is to switch stylesheets for users without scripting. This is handy if you want to have elements look a certain way for users with scripting that wouldn't work for users without scripting. Every scripting method I've tried to do the same thing with results in a visual flicker, in some browsers, as the styles are changed whereas noscript results in a flicker-free experience. Unless there is going to be some way to force scripting to run before the page is displayed to the user, or tell the browser to use or not use different stylesheets based on the availability of scripting, I think noscript is useful.

Scripts are executed when the script elements are inserted into the document, i.e. as soon as possible. For you use-case your can use:

Code: Select all

<head>
<script> document.documentElement.className += " hasjs"; </script>
<style>
  .foo { /* styles for "no script" */ }
  .hasjs .foo { /* styles that override the above when scripting is available */ }
</style>
...

This will not flicker.

[Jarvklo]

In reference to the WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0 and the proposition from them to ban noscript altogether I'd yet again like to point out that

But if that conclusion is an important enough reason to exclude noscript from one serialization, it's probably as important a reason to exlude it from *all* serializations in order to acheive the "unified language" that will replace both HTML and XHTML. Again, my humble opinion of course