W3C validation

Hi everybody,
Most Html and CSS tutorials, especially the one found on SitePoint, recommend having our code validated by W3C, I checked a dozen of websites, including SitePoint website, none was validated. Am I missing something here?

Only that most people are lazy and ignorant. Either that, or very arrogant.

Validation is an aid – one of many – to ensure good quality. It’s like spell-checking your article before publishing: it minimizes the risk of misunderstanding.

People who are lazy can’t be bothered to spell-check or to validate. And some are probably arrogant enough to believe that they never make any mistakes.

I’ve been writing HTML documents since 1993. That’s 17 years now. Perhaps 99 times out of a 100, my documents will pass validation on the first go. But at least once it won’t, and the error may cause problems for some users. That’s why I keep using the validator to help me catch those embarrassing faux pas.

Another reason why so many large sites have invalid markup: they usually have some sort of content management system (CMS) for publishing. And those are often written by developers who are skilled in programming, but usually, unfortunately, completely clueless about web standards and accessibility.

Even if you’re not a perfectionist or if you can’t fix every problem it’s still worth the effort to fix as many as possible. IMHO if you want a page to have the best chance possible to look and behave as you want it to in the largest number of browsers with different settings then sticking as close to the standards as you can is your best bet.

Validation isn’t everything, as said, it’s a tool.

To look at this page’s 7 errors and 4 warnings http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sitepoint.com%2Fforums%2Fshowthread.php%3Ft%3D663506&charset=(detect+automatically)&doctype=Inline&group=0

> #  Error  Line 80, Column 27: invalid comment declaration: found name character outside comment but inside comment declaration
<!-- SitePoint Specific --->

Most likely a typo, the others are OK

> #  Error  Line 81, Column 140: document type does not allow element "link" here
…l" title="SitePoint Search" href="http://search.sitepoint.com/opensearch.xml"/>
#  Error  Line 82, Column 109: document type does not allow element "link" here
…ext/css" media="all" href="http://www.sitepointstatic.com/css2/promobar.css" />

I believe these were introduced with SitePoint’s new and improved search feature. And yes, they should be inside the head not the body.

> #  Warning  Line 107, Column 18: character "<" is the first character of a delimiter but occurred as data
			for(var i=0;i < ca.length;i++) {
#  Error  Line 126, Column 40: document type does not allow element "div" here
…		document.write(	'<div id="promobar2"><div id="jqwrap"><div id="jqbody"><div …

Javascript can be a bit tricky. XHTML requires that the content not be parsed as mark-up but as some browsers (IE) don’t support XHTML fixing the error would break the javascript for them. AFAIK it can be done with “switching” but I’m guessing this is an “acceptable” error.

> #  Warning  Line 939, Column 156: cannot generate system identifier for general entity "num"
…t=SITEPOINT_HOMEPAGE_ROS&tr=FORUMS&num=4&layt=4&fmt=simp"></script>
#  Error  Line 939, Column 156: general entity "num" not defined and no default entity
…t=SITEPOINT_HOMEPAGE_ROS&tr=FORUMS&num=4&layt=4&fmt=simp"></script>
#  Warning  Line 939, Column 159: reference not terminated by REFC delimiter
…t=SITEPOINT_HOMEPAGE_ROS&tr=FORUMS&num=4&layt=4&fmt=simp"></script>
#  Warning  Line 939, Column 159: reference to external entity in attribute value
…t=SITEPOINT_HOMEPAGE_ROS&tr=FORUMS&num=4&layt=4&fmt=simp"></script>
#  Error  Line 939, Column 159: reference to entity "num" for which no system identifier could be generated
…t=SITEPOINT_HOMEPAGE_ROS&tr=FORUMS&num=4&layt=4&fmt=simp"></script>

Whew! With cascading errors all the ruckus a simple single ampersand can raise.

> #  Error  Line 1108, Column 5: end tag for "tr" which is not finished
</tr>

I don’t know if this is “real” or an artifact caused by a previous error (i.e. the javascript < ??), sorry but I don’t have the patience right now to deal with nested table layout (vBulletin) that isn’t consistently indented.

It can be fixed by wrapping the JavaScript in an XHTML CDATA tag and then using JavaScript comments to comment out the CDATA tag so it doesn’t get IE confused.

The easier fix is to just make the JavaScript external in its own file.

Yes, this is a very interesting topic. I have struggled a lot on getting my pages to “pass,”
and so I now look a bit wearily at sites which do not pass as well. Maybe it’s because I have no deadlines, am retired and such. But the last time I checked, at least two major computer company pages “passed,” but another one had over 300 errors. Interesting, to say the least. I have always suspected that many companies rush to get out their products before adequate testing, just to be “first!” Big mistake, probably.

:do’h: How could I have forgotten about external files? That’s what I do simply because it’s easier to maintain one file than it is to edit every page with javascript in it. But yes, that of course does solve the problem nicely. The only script that I have now like that is a drop-in Google tracker bit in the footer include, and I had to hack the http<->https document.write stuff out since document.write isn’t OK in XHTML Luckily it doesn’t have a less-than to muck things up.

And not just W3C. TV’s validation page includes an accessibility validator that I find very useful, and other features as well.

Accessibility validators are MUCH worse than code validators. Code validators at least help do their job to a pretty decent extent (in the fact they can notice common errors and generally have a valid impact). Accessibility validators are redundant in the sense that 2/3rds of the stuff in accessibility specs and recommendations is impossible to be determined through the use of a code validation method (which those sites use). As much as I like tools to assist users, those validators cause more harm than good in that people assume their sites are accessible when they wouldn’t pass the conventional check-list.

Arrgghh! Back in the day, there used to be the “Bobby seal of approval” from CAST, which I gather is still around under [URL=“http://www.accessible.org/bobby-approved.html”]another provider. I remember validating a couple of early sites I designed with Bobby. But that was then, this is now. Aside from a good understanding of accessibility issues and a determination to sort through your site to ensure such accessibility, is there another method to “validate” your site as accessible, at least to a certain extent?

I am search engine optimizer. Site validation is much important to us. So, always I use w3 validation for every site validation. Still now, I have not found any problem.

Bobby never was an appropriate solution Max, in fact the entire premise of Bobby is identical to Cynthia and the others. The seal of approval they offered was simply an empty promise of accessibility claims. Accessibility isn’t about the way code is written, it’s more than just adding a few bits of code to a website. There’s stuff in WCAG about color usage, spacing, readability and more, to which it’s physically impossible for some automated checker on the basis that machines just don’t understand context. It’s like content translation… sure you could use Google Translate to get something partially readable, but it’s nowhere near as good as professional translation, more-so, accessibility isn’t something you want to risk your visitors ability to use your website on the basis of what a computer manages to work out! As far as tools out there, there isn’t really anything which I could honestly give a “seal of approval” for in terms of accessibility validation.

You aren’t missing anything - It’s true that most Web pages don’t pass W3C Validation. Unfortunately, I believe, in my honest opinion, this is because of lazyness and ignorange as AutisticCuckoo mentioned above but also because of a lack of professionalism.

I now find it very easy to create validated Web pages that pass both the Markup validator and the CSS validator. Of course I check my pages regularly but generally speaking, once you’ve been doing it the right way for a long while, you get used to it to the point where it becomes a habit. You should always check your Web pages for validation errors though no matter how long you’ve been doing it for.

You may find the following Web pages an interesting read regarding W3C Markup and CSS validation.

• Opera MAMA Report
• Opera MAMA - W3C validator research
• Opera MAMA: Markup validation report

Andrew Cooper

Excellent input from all of you!!! This forum is really a wealth of information about web designing. I can’t thank you enough for that!

Lila, thanks for the kind words. Having real gurus like Alex and Tommy around make knuckleheads like myself look good.

Alex, I gave up on Bobby (and his cousin Cynthia) a long time ago, after I did some reading that made me realize just how lacking those ratings were. But you know me, always on the lookout for a quick and dirty solution. In this case, there ain’t one. I’ve seen some accessibility checklists out there (this, for example, and [URL=“http://www.sitepoint.com/forums/showthread.php?t=209820”]this FAQ in SP’s Accessibility forum). Any preferences?

Max: How about the official W3C checklist for WCAG?

WCAG 1.0 - http://www.w3.org/TR/WCAG10/full-checklist.html
WCAG 2.0 - http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html

Nothing beats the original source! Plus their pretty easy to follow… It’s all “Yes / No” questions.

It’s really a shame that some people dont’ take the time to validate. They should validate their HTML and CSS.

HTML: http://validator.w3.org/
CSS: http://jigsaw.w3.org/css-validator/

Alex, I like yes/no questions.

BMorgan, how right you are.

The main problem with the accessibility check-lists are that accessibility is then only viewed like tick-boxes - by some. Unfortunately I’ve seen countless people use them and think they are passing priorities and forget reading the supporting recommendations themselves.

So please be aware they are meant to be used as a cross-reference to other related material for example (http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/) and not as a definitive checklist.

Robert, like a lot of people, I do fall prey to the “tickbox” mentality sometimes. Good reminder.