Journal: News & Comment

Why should anyone care about valid XHTML?

Permalinks to this entry: individual page or in monthly context. For more material from my journal, visit my home page or the archive.

At my work we have an intranet where each employee posts a little bio. On mine, I end with the tongue-in-cheek: "He likes coffee. And cheese. And valid XHTML." That's a slightly funny in-joke at a company full of web developers, but there's truth in it. I have, however, had trouble for years explaining what "valid XHTML" means to non-geeky people, and why it should be important.

A good explanation requires not dumbing down a concept, but finding the right metaphor. So here's my latest attempt.

What is valid web page code?

Valid web page code is really irrelevant for most people to know about, even if it's good for the web pages they look at to have it. All it means is that the code behind the web page—the actual text file that your web browser grabs from the website and then interprets to create the web page you see—conforms to a technical standard, where it might not have before. The trend over the past several years among savvy web designers and developers has been to write more and more valid code, although there are still plenty of sites (most, in fact) that aren't built that way.

A web page made with valid code may not look any different when you view it in the browser than an invalid one, but having it validate according to the specification means that you can better rely on more people on more different computers being able to see it roughly the way the designer intended, and that it will be easier to work with in the future. Often that also means that it's more accessible to people with disabilities, is less likely to look break on mobile devices or even old browsers. It's also usually easier (and thus cheaper) to maintain in the longer term.

However, it's just as possible to build an ugly and useless website with valid code—the actual usefulness of the content, usability of the information architecture, and attractiveness of the design are separate matters. Quite often, those who care about elegant code also care about elegance in those other things, but that's not always true.

How building a web page is like constructing a dresser

The difference between valid and invalid web code is sort of like the difference between building, say, a wooden dresser with a rough-and-ready batch of screws and nails and glue and woods of different sizes and types, without a blueprint. A talented woodworker can make it look great and do its job, especially with a nice coat of paint on top. But if you ever need to fix it later, you'll have a heck of a time finding the tools and parts to take it apart and put it back together again, especially if you're not the person who built it. Think of that as old-style "hack it together" web code.

If the dresser is built more elegantly, perhaps without nails at all, it's easier to add to or modify, and easier for others to repair. Plus all the other woodworker geeks will admire your work. Think of that as XHTML (eXtensible HyperText Markup Language) built to conform to the spec.

And of course it's a point of pride among the geeks to have your web pages validate completely to the spec with no errors at all, which in real-world terms has some merit, but isn't the be-all end-all. Still, that's never stopped anyone before, has it?

Oh, and if you want, you can check the validity of the code on this page anytime. Whenever I discover that my home page isn't validating, I compulsively fix it, even though usually there's no practical impact to the problem for anyone visiting.

 |