If you frequently visit personal or non-commercial websites, you’ve probably noticed the small badges at their footers announcing “W3C valid HTML / XHTML / CSS”. Some web developers strongly argue the merits of standard-compliant design, as though it has value in and of itself, and some people seeking a new site will boldly insist that it complies with official standards. However, people chasing the conformance badge often lose track of the real objectives of web design: developing useful, attractive tools with the audience in mind.

Standards can be limiting.

At first, this argument sounds like a whine, issued by developers who can’t be bothered to find ways to work within the new standards. I’m sure many designers were heartbroken when the <marquee> tag didn’t quite make the cut. However, in certain cases, the standards actually DO only provide a subset of the functions developers need, and little recourse. An excellent example of this problem is with the XHTML STRICT spec– the “target” option on links has been removed. You can, therefore, no longer specify a link to open in a new window without either requiring a client-side script, or breaking the spec. Since many sites make use of this feature for user benefit, the standard actually moved the state of the art backwards.

Standards often get misinterpreted

In some situations, the W3C has supplied sample implementations which should clarify how standards are supposed to be implemented. A good example of this is “Amaya“, the obscure browser which serves as a model of how recent HTML specs should work. Sample code is, in theory, the best specification, because it eliminates any ambiguity left in a written guideline. However, not only are many specs without sample implementations, those that do have them are often ignored. This often leads to inconsistent interpretations of the specification, and poor cross-browser compatibility.

An example: Although all major web browsers “support” the CSS standard, only Opera 9 navigates the ACID2 “torture test” page as its designer intended. If your developers write code to the actual CSS spec, they’ll find it looks bizarre in real browsers.

Standards can represent a cop-out for real testing.

A poor designer may try to use the excuse “It’s standard HTML/XHTML/CSS” if you have trouble rendering under a specific browser. He’s blaming the browser because HE chose to ignore compatibility with the real world. This is an unacceptable excuse at any time; the first lesson of web design is that no mainstream browser implements the standards 1000% accurately. Would you trust a car that was built with every part in tolerance, but never test-driven?

Know your audience: Sometimes, standards just don’t work.

The best of modern browsers (IE7, Opera 9, Firefox) generally come within shouting distance of supporting the W3C standards. If you don’t “game” the standards or make excessively complex designs, compatibility is generally good. However, the rules are completely thrown out the window when those aren’t your target market. Internet appliances (WebTV and similar), mobile phones and PDAs, and even just users stuck on specific older browsers can torpedo standards-compliant code instantly. Advanced markup simply goes over their heads, or worse, is interpreted in ways ranging from comical to unusable.

Much like newspapers are written to the lowest reading level of their target audience, so webpages must be written to accomodate the buggiest and most primitive browsers they will encounter. If that means IE-specific tags and browser-detection code to keep order, so be it.

Like the United Nations

I have no problems with the standards-setting bodies themselves. They remind me of the United Nations: well-intentioned, but with little actual enforcement power.

Their lack of power comes from two sources:

First, since HTML and CSS have reached an adequate level for most design needs, there’s little that can be offered in new standards to make them worth embracing. There is very little you can render in XHTML that you couldn’t render in HTML 4.0, so why bother changing existing designs and habits to meet XHTML standards unless you have a very specific need?

Second, the real standards are, perfectly honestly, the behaviours of Internet Explorer 6 and 7 and Firefox 1.5 and 2.0. For an eye-opening experience, try surfing with Amaya (mentioned above), and see how many successful commercial sites have chosen to appeal to the real standard, and not the official demonstration of how HTML and CSS are supposed to behave.

What can make standards matter?

Right now, standards-compliance tends to earn you nothing except a feeling of superiority and likely several more billable hours for fixing the tags that actually work in browsers but cause the validator to puke. Instead, standards need to present a clear value-add to the developer and user. If new standards allow developers to easily add desirable effects you couldn’t do before, then browsers will clamor to embrace them and the standards will succeed. May I suggest:

• A tag structure for the definition of nested, collapsible or drop-down menus.
• The ability to have multiple languages or character-encodings in a page, and let the browser display only the relevant ones
• An embedded font system.

People will embrace those standards, because they fit clear design needs, while things like “Now your webpage is valid XML too!” didn’t.