XHTML and WAI compliance

YOu suggest change has been added to the 5.x CVS build.

<!-- is both an HTML and a javascript comment.

The correct usage is:

<script><!--
code here
// --></script>

Note the line breaks. Without the line breaks you make the entire <!-- code here --> snippet a javascript comment. Effectively turning off Google Analytics for 5.x-1.1 of your module.

From the release notes: “Nothing to get excited about.” How‘s that for excitement? ;-)

Fixed in CVS.

immediately?

How rude.

I updated CVS with the change this morning, see here.

I'll await confirmation that its working before tagging a new release.

The current mix of single and double quotes is awkward and you have more \n than you need. But I can confirm that the javascript works now.

Tagged as 1.2 a couple of days ago. However somebody is now saying the <noscript> addition is invalid HTML. Can't win.

IMHO this should be reversed:

1* add a after all script tags. Its needed for browsers that doesnt have javascript supported. like in <script type="text/javascript" src="http://www.google-analytics.com/urchin.js"></script><noscript></noscript>

Why? Because 99% or so of all browsers DO support JavaScript (and in total there's about 98% of those who have it enabled). So get valid XHTML and throw away support for that other percent (most probably even less).

It makes no sense to include a *blank* noscript tag... it's not required to have them, but they should be inside if possible.
So remove the senseless code <noscript></noscript>.
Additional the JS comments are not XHTML valid. XHTML requires to add CDATA. This type of comment is therefor not valid - it's an HTML4.01 JS comment.

Nope. you should add a noscript tag for WAI, yes, but this is only done for ONE reason - IF you do for e.g. a document write or something that change the website, like ajax that is loading text into a selectbox or so on. Google Analytics is NOTHING visible and therefor NO user must see anything. we do not need a "activate javascript please" in a noscript tag. it will make every screenreader to tell you this sentense - but this is not helpfull at all. We are going to track users with Google Analytics. If they deactivate javascript they are lost, as i know - there is no way to track users with google without javascript... i know webtrends provide an alternative for this... but i don't know if we can do such things with google. but nevertheless it helps nothing.

JS deactivated = no tracking pixel executed and there no change in tracking if there is a blank noscript tag... this one will not start to track something with no code inside.

You should spend some more time on WAI rules and not trying to follow a rule that makes no sense at all.

brmassa, you are using a different source than the one I used last time. Not to mention that my point was not how many users have JavaScript enabled, but rather the percentage of users that use browsers that support JavaScript. That's a big difference.

P.S.: your source shows that only 6% turned it off, not 10%.

1. never trust a WAI validator
2. never trust a WAI validator
3. never trust a WAI validator
4. you trust him? don't trust him!!!
5. now validate http://www.einfach-fuer-alle.de/. A german site build for WAI people. How many warnings will you get? many... :-). If you are german - read some of the articles... and follow the links... many are english
6. my site is build on a framework for accessible websites... :-)
7. no one needs a blank script tag - no blind, no deaf and no one else.
8. check out a screen reader. learn how the rules you are talking about will destroy a site.
9. Are you adding a alt="this is a placeholder for keeping layout intact" to image tags, only for the rules? let's have fun and build a site with 50 placeholders... every blind guy will leave your site as quick as possible. He don't like to hear 50 times - this is a placeholder, this is a placeholder, this is a placeholder, this is a placeholder, etc.
10. WAI validator are not comparable with XHTML validators. XHTML validators like HTML Tidy can be 100% sure the code must fulfill a reference, this is not possible with WAI... and this is why you get tons of bad and wrong warnings that are nothing more then information - this will happen in all WAI validators i have tested yet.
11. if you have such "stupid" customers, leave them or explain them something about WAI and accessible websites... you should know better.
12. WAI validators complains about things that are correct... they only tell you - look at this, and think about this, and this, and if this is accessible, the code is WAI compliant... i hate this... it took me days to find out everything is correct, only a validator warns for nothing.
13. turn on common sense
14. i tried to make the same mistakes in past...

Let's stop this senseless discussion now, please.

Well this was a suprise to come bak to after a long weekend break.

John, any thoughts on the above discussion?

I agree that empty tags are pointless, but I have no previous experience with WAI either.

I don’t agree with Hass’ tone (you catch more flies with honey…), but he is right about WAI validators providing warnings even when there are no real-world accessibility problems. The validators show warnings to get developers to focus on those issues. If a website has WAI warnings, it doesn’t mean the site is inaccessible. And, conversely, if a website has no WAI warnings, it doesn't mean the site is accessible. So the empty noscript tags add no accessibility improvements to a website.

In regards to the CDATA inside script tags, here’s what Section 4.8 of the XHMTL spec says:

In XHTML, the script and style elements are declared as having #PCDATA content. As a result, < and & will be treated as the start of markup, and entities such as &lt; and &amp; will be recognized as entity references by the XML processor to < and & respectively. Wrapping the content of the script or style element within a CDATA marked section avoids the expansion of these entities.

So the <![CDATA[ … ]]> sections are only needed if you have < or & in the javascript. The module doesn’t appear to add either of those characters (I haven’t done a full code review), but a user could inject those characters from their username.

I think the best solution would be to not use <![CDATA[ … ]]> (which can cause errors in the javascript), continue to use the <!-- … //--> comments (which provide real-world accessibility improvements), and to strip < and & from {$segmentation}{$codesnippet} to make sure those characters don’t screw up the javascript/browsers parsing.

5.x-dev isn't fixed.

Line 84:

$script .= '<script type="text/javascript">' . "<!--\n_uacct = \"".$id."\";{$segmentation}{$codesnippet}urchinTracker();\n// --></script><noscript></noscript>\n";

Surely stripping characters from the $codesnippet variable could be dangerous and break peoples custom script code?

Please provide a patch to address the issue and I'll review it.

Changing from critical because its not stopping the module from working.

I have found that on pages served as application/xhtml+xml and XHTML 1.0 Strict, Javascript code must not be wrapped in HTML comments. Newer browsers will treat Javascript inside comment tags as actual comments, and ignore it. See a newsgroup discussion about this.

This page demonstrates it: http://ermarian.net/html/javascript/commented. Both text fields should be filled, but the code that fills the second field is wrapped in HTML comments. This does not happen in IE or any other non-XHTML browser (IE cannot accept application/xhtml+xml), but Firefox, Opera and SeaMonkey do not evaluate the wrapped code.

As far as I know, no themes try to serve themselves as application/xhtml+xml to capable browsers, but as this topic is concerned with well-formed XHTML, the issue should probably be kept in mind.

@brmassa: i only reopened to get <noscript></noscript> removed for XHTML compliance.

<noscript></noscript> removed from the dev branch.

read above discussion, please. it is not required, however bad WAI validators complains about. please don't start this discussion again, thx.