Infrequently Noted

Like a lot of people who read this blog, I've been writing HTML for a long time. Heck, I remember when "A List Apart" was an actual, honest-to-goodness mailing list. As a certifiable old fart, I remember the "Bad Old Days" only too clearly. <font> tags, tables for formatting, the whole bit. Boy am I glad we've moved past that. Now if only we could move past the mental block of validating markup.

Today, web developers (myself included) are held to a higher standard of accessibility, usability, and visual appeal than ever before. With the recent resurgence of interest in my little corner of the web development world, we're also providing better interactivity, responsiveness, and overall experience.

As the evolution from tinkerers to professionals has progressed, an amazing amount of pressure has been brought to bear, first on browser makers, and then on their fellow developers, by a very vocal segment of the webdev community. Like the internet itself, the net effect has (hopefully) been to reduce costs. No one will argue more strongly than me that this is a Good Thing for everyone. I've been fighting browsers for almost a decade and I'm truly grateful for the effects they've had.

But I've got a beef with one of the agents of this change. The Validation game. As a former true believer, I think it's time that the air was cleared about some of the non-standard things I've done (including the extra attribute syntax in Dojo). You see, I came to web development from programming (not the other way around), and one of the first lessons you learn when writing network programs is "be liberal in what you accept, strict in what you produce". The implication here, of course, is that there's a standard that you can be liberal or strict about. In the case of internet software, there almost always is (whether or not you're ignorant of said standard is another question). This little bit of wisdom has enabled programmers for decades to get along despite products shipping too early, implementations based on draft versions of standards which then diverge, and the general tendency of programmers to be human.

What does this have to do with XHTML? Fire up a browser and point it at google.com. Did that work? If so, you can thank some very fast-and-loose code at almost every point in the chain between you and Google's data center. The TCP stack in your computer's kernel probably re-assembled some fragmented packets for you. The DNS resolver in your OS probably consulted a stale cache, but just kept on working anyway, or fired off an asynchronous request to update it after it knowingly gave you a stale answer. The browser itself likely continued to process the response to your request despite all kinds of behaviors that RFC 2616 frowns very sternly on, and when it came time to process the content...well...I think you can take it from there. Or, rather, the W3C validtor can.

Which makes the W3C validator one of the most widely used academic programs ever to crawl out of a lab. You see, the validator is just an implementation of a client that has been explicitly tuned to be as bitchy as possible. This is the direct opposite of what the client you actually use every day (the browser) is tuned to do. If your browser were as bitchy as the W3C validator, you wouldn't just get frustrated with it, you'd throw it out. Generalizing that point, we can say:

Leniency in the face of incompatibility is a feature of useful software, not a bug.

History sides with the continued existence of bugs in software. Well engineered software doesn't bitch, it just does what you wanted it to do in the first place.

There are very few programs that can provide value by being bitchy, and even those that are explicitly designed to be testy (GPG and SSL spring to mind) often must support multiple incompatible and non-validating modes of operation (S/MIME anyone?). When was the last time you browsed to a site and saw an SSL cert revocation warning based on a CRL or OCSP check? My money is on never. Why? Because you don't have CRL or OCSP checking turned on. Because it's slow. And yet somehow, the sky hasn't fallen and you probably continue to bank online. And if you don't, the odds are pretty high it's because you're worried about spyware or phishing. Not an invalid cert.

Once you're trying to get something done on more than one computer, leniency helps make software useful. Useful software helps me (the user) do things I couldn't before; without complaint. Software that wins markets does that better, faster, and in the face of more incompatibilities than any of the competitors. The market for software will always, always favor the lenient.

The corollary to this is:

By encouraging the use of standards, you in no way decrease the amount of work that will be required of implementors of useful software.

This means that all the arguments about how producing valid XHTML is somehow better for mobile devices aren't just ignorant of Moore's Law, they are wasting our time. Tim Bray didn't get it and now we're all paying for his poor instincts as a software engineer.

Now, before you think that I just said that standards are worthless, let me defend myself a bit. I think they are tremendously useful. In open systems, somewhere between novelty and ubiquity, hopefully a standard gets written. This process is good, inevitable, and gives everyone who's been furiously building stuff a chance to catch their breath and acknowledge where things should be improved. It also help iron out interoperability concerns, which is something that users care very much about. This process is good because it reduces everyone's costs. That's why standards, when done well, are good.

But back to the validation game. I call it a game because that's precisely what it has become for many of us. I'm just as guilty as anyone. Once I've done a lot of actual, hard work figuring out how a page should be structured, worked to make it look right on as many devices as I can lay my hands on, and then fretted about usability (which includes accessibility, brain-damanged WCAG terminology aside), I can then go play the validation game. You start playing the game by scp-ing your files up to a server and them running them through the validation service. Tweak, re-upload, re-check. Does it pass? w00t! I r0xor!

Or not. Either way, no one cares.

What people do care about is whether or not your stuff works for them. And this is fundamentally why web standards have been important. They have allowed WaSP and others to bludgeon and shame browser vendors into submission such that the same amount of effort expended by the same web developer today makes a thing work better for more people than it did before. That behavior is dependent on the clients, not the spec or any adherence to it. Clients define behavior, markup is only a series of suggestions about what that behavior might, possibly, be some day.

For a long time now, I've been adding extra attributes to (X)HTML elements that throw all kinds of warnings in the validator, and I've been conflicted about it, enough to bake in ways around the problem in both nWidgets and Dojo . The hacks rely on the same kinds of (completely validating (X)HTML) value and structure conventions that are now being used to carry microformats. But no one uses those validating structure conventions in nW or in Dojo. They just go ahead and do the low-effort thing by blithely adding non-validating attributes to their tags. When people ask about validation for them, my response has been "well, you can just build a custom DTD". Which is kinda like a cab driver saying "sure, we can go there, just get out and push".

In a recent article, the W3C Validation Team discuss the prospect and end with:

Custom DTDs can be a very useful tool to enrich the existing markup languages or create entirely new ones. One always has to keep in mind that they are tantamount to creating a new language, and that proprietary languages are best kept in closed environments where they can be taught to a limited set of agents and tools, and NOT to make the web a modern version of the Tower of Babel by unleashing them in the wilderness.

It's about here that my bullshit detector started doing the full-on "woop! woop!" thing. Could it really be that they are arguing against the only way out of being both useful and valid? And are they really arguing that we should only be using the full power of the available standards in intranets?

And then I remembered. It doesn't matter. Most of the discussed approaches aren't available. If the clients that people use will accept the extra elements without complaint, and if they don't degrade the experience for anyone and if the dominant browsers don't support custom DTDs or namespaces sanely anyway, then the only people who ever have to wring their hands over this are academics. And their tools. I for one am opting out of this particular full-employment-for-academics plan. And I should have done it a lot sooner.

So until validation actually starts to matter, I'm gonna proudly display my invalidation badge, redirect all questions about validation to this page and get back to work. Although you've gotta admit, beating the validation boss at the end of the InterWebDev game sure was fun while it lasted.

corrections/clarifications

• corrected innacurate statement about clients of microformats (thanks Tantek)