Forward Compatibility And Web Standards

Forward compatibility and web standards

In my opinion the current definition of forward compatibility in web design leans far too heavily on web standards. This short article gives my arguments against intertwining these two concepts.

Forward compatibility is a good idea. When creating a web site, you should make sure that it can be viewed on future or uncommon devices, like PDAs or mobile phones. Secondly you should make sure that the site remains easy to update for future programmers, copywriters and designers.

However, the problem is that "forward compatibility" is currently equated with "web standards." In my opinion this equation is false. It is perfectly possible to create a forward compatible site without reference to the web standards, or to create a perfectly standards compliant site that contains no forward compatibility to speak of. Web standards do not automatically lead to forward compatibility, nor vice versa.

Sure, there's an overlap between forward compatibility and web standards, especially in the deprecation of silly coding habits like nesting nested tables in nested tables, using 50 FONT tags in your pages and similar rubbish. Unfortunately this overlap has caused much confusion.

The official argument goes like this: "Forward compatibility ensures that your sites will always be usable in any browser". This is a fallacy. Keeping your sites usable in any browser is the purpose of forward compatibility, so this "argument" simply repeats the definition. Not particularly useful.

What people really seem to mean is "Web standards ensure that your sites will always be usable in any browser". Although this argument makes somewhat more sense and applies to the new browser releases of the past year or so, ultimately the verdict on this argument must be Not Proven.

If the history of the WWW teaches us anything, it is that we simply cannot know in advance whether future browsers or other devices will implement the entire standard (or, indeed, any feature at all). Since the argument makes assumptions about future browsers that may turn out to be incorrect, it cannot serve as a solid basis for developing web sites.

Besides, the unspoken version is "Only web standards ensure that your sites will always be usable in any browser". This, now, is completely untrue. All current standards-compatible browsers also support old-fashioned tag soup, and they will always continue to support it.

If they didn't, users of the browser wouldn't be able to access tag soup sites any more and would eventually in exasperation download a new browser, which is bad for the business of the browser vendors. So future browsers must continue to support tag soup. I call this the "principle of browser conservatism".

Thus web standards are by no means required. It's perfectly possible to code a forward compatible site with the techniques of a few years ago. Although I'm not saying this would be good practice, it does prove that forward compatibility and web standards are not the same.

Though the semantic concepts behind web standards will certainly help to ensure forward compatibility, the mix-up between the two is too simplistic and ultimately dangerous.

Unfortunately this is not the case. Creating a forward compatible website takes more than just validating your code. It requires you to think about the structure of your site, about how to achieve the effects you want and about a host of minor matters. Besides, there are still grave browser compatibility problems to be pondered.

The process of creating a forward compatible site isn't simple, though the resulting code should be. Although web standards and the semantic concepts behind them certainly help, in and of themselves they do not ensure forward compatibility.

So let's treat forward compatibility and web standards as two different concepts, to be studied and pursued separately. When applied properly they strengthen each other, but they are not, and never will be, the same.