xHTML, the best thing since 8-track
Remember 8-track? ... No, well how about ever hearing of it? Possibly? Anyway, xHTML has the same potential of being great and through no fault of it’s own vanishing from this great blue marble. Just like Betamax.
Do we need real xHTML? Yes. Do we have real xHTML? No. (as we all know by now, IE doesn’t support application/xhtml-xml). Will it matter five years down the road, probably not. What matters is now, what the client is paying for today. No more no less. These days the requirements often say that the site, intranet or any webapplication you can think of should adhere to xHTML and work with a plethora of web browsers and clients ask for this for no real reason. Just because some zealot told them to? For most clients the bandwidth argument is mute due to fixed costs and the fact that most sites never exceed their bandwidth quota. Speed can be timed but what we time may vary and allows for vague arguments by account managers to gloss over some of the sites shortcomings. Clients generally don’t pay for a future proof website. Why? Because you can’t in good faith quantify such a thing. Knowing the future burst along with the internet bubble. The sad truth is that nobody cares because tomorrow it won’t be your problem, or your client for that matter. Clients come and go and so do their websites. As soon as the check is out the door everybody seems to move on. How many sites are still intact after five years? Not that many, if any at all, I’d dare to wager. Sites are alway rebuilt, redisigned or simply axed.
So we write for the clients customers today and code for their browsers today. Whether we code in HTML, xHTML or XML even is not going to have clients lay awake worrying about it. Eventhough content is king how it’s parsed isn’t. So don’t look surprised if a client raises an eyebrow or two on hearing the benefits of xHTML and the webstandards they seem to imply. Which it doesn’t by the way.
So xHTML isn’t future proof and the clients couldn’t give a flying whatchamecallit about it and they’re certainly not going to pay for the overpriced privilege. So do I still care? Well yes. On the developer side of my work using xHTML does provide benefits that make it worth all the hassle. Despite the fact that HTML works no matter how badly you f*** it up. In the end bad HTML (is that an oxymoron?) is more trouble to the developer than it’s worth. In almost all my clientside endeavours I’ve had to go back into the code and fix a problem or make an alteration. Webstandards will most definitely cut the time spent messing around looking in the tag soup you cooked up two months ago. xHTML at least forces me to some degree to keep my pathetic coding skills up to a (re)usable level. Designers playing with HTML is like a toddler playing with matches. Someone can end up getting burnt.
Standards and best practises (to some dregree) will allow us to build better websites whether the clients ask us or not and in most cases they won’t. But that shouldn’t allow us to get away with creating garbage. You know what they say: “Garbage in, garbage out”. Remember most of us are not being paid to play janitor.
Article revised on 10 / 09 / 2004