Skip to page content or Skip to Accesskey List.


Main Page Content

Forward Compatibility And Web Standards

Rated 2.9 (Ratings: 32)

Want more?

  • More articles in Code
Picture of ppk

Peter-Paul Koch

Member info

User since: 12 Sep 1999

Articles written: 8

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.

The danger lies exactly in the apparent simplicity of the solution, by which unwary web developers may be lured into a false sense of security. "Just code to the standards and everything will be all right in the long run."

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.

Peter-Paul Koch is a freelance browser expert and JavaScript guru living in Amsterdam, the Netherlands. He has been an Internet professional only since 1998, so he's definitely second generation.

His personal site is It includes the W3C DOM Compatibility Tables, currently the best resource on the Internet for this subject. Because of this research, he has been asked to co-edited chapters 17 to 19 of Flanagan's "JavaScript, the Definitive Guide", O'Reilly, 4th edition.

He is an administrator of the WDF-DOM mailing list, that counts most international JavaScript gurus among its members.

He has written the "Keep it Simple" column on Digital Web Magazine, as well as articles on A List Apart, Apple Developer Connection, and O'Reilly's Web Dev Center, in addition to Evolt.

The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.