Backwards compatibility when rendering documents

Yesterday I was venting my frustrations about the suckiness of Internet Explorer 6. Today the blogosphere is buzzing about Microsoft's plan to introduce a completely new rendering engine in IE8 with a couple of tricks to support both the latest web standards and backwards compatibility.

A List Apart has all the details and there is quite a lot of discussion going on. Eric 'CSS' Meyer chimes in with some interesting points. All in all, a lot of interesting stuff to read for everybody involved in designing and building web sites.

In my opinion, the discussion goes beyond web design. It touches the universal problem of backwards compatibility, especially when rendering documents. At my former employer (Inventive Designers) we often had similar discussions when we were fixing bugs in the XSL-FO formatter/renderer of the Scriptura product. What do you do with a bug when the fix changes the layout of the output? There are three options:

  1. You fix the bug because the spec says so. This will surely annoy a lot of existing customers because they often consider the bug 'a feature'. Especially if the bug has been present for a long time.
  2. You do not fix the bug because backwards compatibility is king. This is typically what existing customers want. Unfortunately you'll have a hard time explaining prospects and new users why something does not work according to the spec.
  3. You fix the bug but make the behavior configurable. Sounds like a smart things to do: existing customer get backwards compatibility and new customer gets standards compliance. Unfortunately you'll end up with code that is littered with bizarre if-then-else constructs. Before you know it you'll end up with a legacy print engine, a classic print engine and a modern print engine ;) Just try to maintain, test and document all that.

What is the solution? I don't know. It all depends.

Topic: 

Add new comment