« Morning paper | [dandruff::main] | Morning paper »

Web standards and forward compatibility (Ohh I am weak)
Recently, Peter-Paul Koch has written an article about forward compatibility and web standards (see also an interview some time ago). I don't know what he seeks to achieve by this article, but I shall cave in to temptation and do a kind of deconstruction. He is right on two points — forward compatibility is not web standards, and that nothing ensures forward compatibility — but he is also somewhat short-sighted on many others. In his article, he claims that browsers will always have to support tag soup because they are bound to succeeding in business goals. Needless to say, this in itself is an unproved assumption. By PPK's words, it seemed as if he was referring merely to web browsers on computers, therefore, effectively discounting other kinds of user-agents. What about those which will be accessing content but do not require a human interface? What about browsers, user-agents on phones and PDAs, which, at this point in time, leans towards the need for more lightweight content? (Let's face it, tag soup isn't exactly lightweight.) Business success is based on being able to supply what the customer demands. We might be able to predict short term demands, but who knows what may change? The more designers develop compliant sites, the more developers create tools which generate standards complaint code, the more clients demand standards-compliance, browsers will be forced to be compliant. There is a convenient clause in the HTML 4.01 specification. It says that if a user-agent encounters a tag which it does not handle, it should ignore the tag and try to display its contents. So, even if I'm using a tag-soup free, standards-compliant browser, chances are, I can still access the information. Current browsers like Mozilla, Konqueror and Safari have a "quirks" mode which handle tag soup based on the document's doctype (if it exists), but they also do a good job at presenting standard-compliant websites. Such standards-compliant browsers are already in existence; you can safely say that if you don't employ web standards, at some time in the future, your websites might not display as expected. And after all that, forward compatibility is not the sole argument for web standards, and there is little point in stirring up confusion with rhetoric. A site that is XHTML/CSS (and not using tables for layout) brings with it advantages such as basic accessibility and the ability to leverage other Web technologies. A website is a product, hence bound by infrastructural, technological specifications as much as high-level requirements from customers. If you want to buy a fast pink car, you can have a fast pink car, but it still has to comply with safety regulations. Web standards are specifications — we often use the term "web standards" too loosely, and I think for the most part, many designers tend to only refer to XHTML/CSS. Web standards are also XML, XSL, SVG,DOM, RDF, WCAG, HTTP, amongst others. There has been significant noise around XHTML 2.0, about its backwards-incompatibility and its drawbacks. Perhaps we are forgetting that standards, or specifications, are a kind of roadmap. A particular standard might exist in telling us what is the acceptable composition of certain compounds in soap, or the diameter of the pipe which goes into your kitchen sink — so we know how to make soap, and how wide to make our pipes. A Web standard exists as a description of how user-agents, servers or authoring tools and their products should function accordingly; embedded within Web standards is the construct of how these bits and pieces should behave and interact together. More importantly, the specification has to exist before the product is built; we need not get unnecessarily worked up about something that is still being designed — in the meantime, we can assist in improving the specification's design because current processes of the W3C allow us to contribute. The mess we have had with existing browser quirks had to do with the lack or the inadequacy of past standards, and sadly, the ignorance of developers. Now that we have specifications — however imperfect — what is the sense in not adhering to them? If the standards are inadequate, not testable or insufficiently clear, then we as the web community can and should contribute to improve them. If a road is being designed in such a way that will benefit the inhabitants of a city is being planned and built, why make maps for mud tracks? Anyway, I'm looking forward to the day that neither you or I talk about web standards; by then, everything is running as it should be. Incidentally, one finds a Box Model Fix. Posted by sniffles at April 09, 2003 10:01 PM