CSS/ xhtml: does validation matter?
Last Updated on
“In a code-shop version of Guantanemo Bay, validation failures are assumed guilty until they can prove their innocence.”
One of the questions I was asked at the mediaelements conference was by a guy who’d read my tirade against the invalidity of embedding Flash. The question was "Does validation matter?". It’s a question that is being discussed a lot lately, and I pitched in with my unfashionable opinion.
Validation is important as a step to making your sites work, but it’s not the be-all and the end-all. If I were running a team, for example, I would require full xhtml and css validation as part of the acceptance process, unless there was justification for accepting invalid code. In a sort of code-shop version of Guantanemo Bay, validation failures are assumed guilty until they can prove their innocence.
The only acceptable defences would be:
-
Correcting Internet Explorer’s broken keyboard navigation by adding the invalid attribute
tabindex="-1"on headings etc that are the target for in-page links to correct IE’s broken keyboard navigation. -
The need to
<embed>Flash into a page. The Flash Satay method of creating a very small container movie, in which the first frame loads in the real movie we want to play, is a testament to Drew Mclellan’s genius, but seems less elegant to me than letting an invalid page go live (and plus, I don’t know enough about Flash to do this!). This is the only circumstance I can see for allowing an invalid xhtml file to go through.Additionally, Andrew Kirkpatrick of the National Center for Accessible Media writes that Flash Satay renders the entire Flash movie inaccessible to JAWS.
(Update, June 05) Patrick Lauke has found a Firefox and Flash Satay bug: flash content embedded this way swallows the tab focus, making it impossible to proceed beyond the movie when using keyboard navigation.
-
The need for non-contiguous list numbering in xhtml. (You might think that this is an arcane example, but I’ve needed to do it twice in two months.
-
The need to hover over anything in IE. Using the microsoft-only property
behavioron the body selector, thus:body {behavior: csshover.htc;} and offering the IE behavior file csshover.htc allows you to fix the fact that IE only allows the hover pseudoclass on links, instead of any element as the CSS spec allows. This solution allows drop-down menus without JavaScript and introduces one validation error to fix poor old broken IE, and therefore allows you to make semantic lists and turn them into sexy menus with CSS. What’s not to love, Mr PuristPants? -
The need for user-friendly print stylesheets. I like to make print stylesheets, and because (like everyone else) the majority of my clients’ audiences use IE, there’s an extra lovely bonus I can offer them. If I define all images in the print stylesheet to use an MS-only filter, we can protect poor Mr and Mrs Public from using endless quantities of hyper-expensive colour ink cartridges by automatically making all images grey-scale:
img {filter: gray();}Again, what’s not to love about that? (As an aside, is this the only time when IE users get a better experience?) -
Make pages cross-browser. Many hacks – including the box model hack – seem to upset the validator. But then, of course, we need these hacks. (More’s the pity).Lachlan Hunt wrote to point out that I’ve made a mistake. For a time, the CSS validator flagged the box model hack as an error, but the validator was wrong and it’s fixed now. (D’oh!)
Now, obviously, your mileage my vary, but I consider that these real-world examples justify ignoring validation errors. Any other times, documents should validate. I always bear in mind that clients increasingly demand accessibility, the ability to render on PDAs, mobiles, and reduced download time and bandwidth bills – and these are all products of using xhtml and css. But no client has ever demanded that the pages validate – itself a sign that validation is a means rather than an end. Do, of course, flame me.
Anyway, validity and accessibility by no means guarantee a good page, as my work-in-progress submission to the CSS Zen Garden, Geocities 1996, demonstrates.
(References: Mozilla CSS extensions, Microsoft filters).
5 Responses to “ CSS/ xhtml: does validation matter? ”
Validation does not matter. Try to validate some of the msot prominent sites ont he internet, today. Guess what?- none are valid.
Try amazon.com ..
ebay.com
Considering the fact the big sites on the internet have masses of resources it is a real shame that they don’t set a good example, especially when a lot of the hypocrites are members of the w3 consortium.
The most prominent sites don’t validate because idiot online validators can’t deal with the scripting and programming used to create them.
Try to validate a PHP-based or .Net-driven site and the online validators puke all over themselves.
It has nothing to do with available resources or ne’r do well attitudes. I write perfectly valid and perfectly validating sites in XHTML. As soon as I add the PHP scripts, the validators throw hissy fits because I must – absolutely must – declare a variabel to pass between pages.
Like me, developing working websites demands that the developer use for cost offline packages that can handle scripting languages when we test our sites.
Better to say, “A pity that with all their resources, the W3C and the WDG can’t write an online validator that understands that a scripted pages need to pass variables…” But then, that’s not their interest.
Or maybe we can try to teach everyone else that the one-size-fits-all online validators really don’t.
[…] CSS/ xhtml: does validation matter? by Bruce Lawson (November 21, 2004) But no client has ever demanded that the pages validate – itself a sign that validation is a means rather than an end. Categories: Web Development Tags: Comments (0) Trackbacks (0) Leave a comment Trackback […]
You say that “The need to hover over anything in IE” is an acceptable reason for using invalid CSS. You’re right in that it generates just one validation error, but this error could be avoided by placing the invalid CSS in a separate CSS file, then using a conditional comment ( http://www.quirksmode.org/css/condcom.html ) to feed that file only to Internet Explorer. You would still be using invalid CSS, but at least you’d avoid getting a validation error, and I’m sure that the file would come in useful for other IE-only hacks and fixes.
My other point is in regard to the “The need for user-friendly print stylesheets”. Automatically printing images in grayscale is a nice idea, but in my experience browsers aren’t set up to print images or colours anyway; it’s a setting that the user needs to enable. If the user has to enable this in the browser (and in Internet Explorer it’s a fairly well-hidden option), then can’t we assume that the user is also knowledgeable enough to change their print settings? That way, the option to print in colour or not is left up to the user, wheras your
solution takes that option away from them.
These are small things, but I thought them worth mentioning.