Backwards compatibility on the web

I just noticed the following excerpt in the web page describing a rich-text editing component:

Supported Browsers (Confirmed)
… list …

Note: This list is now out of date and some new browsers such as Safari 3.0+ and Opera 9.5+ suffer from some issues.
(Free Rich Text Editor – www.freerichtexteditor.com)

In odd moments I have recently been working on bringing vfridge back to life.  Partly this is necessary because the original Java Servlet code was such a pig1, but partly because the dynamic HTML code had ‘died’. To be fair vfridge was produced in the early days of DHTML, and so one might expect things to change between then and now. However, reading the above web page about a component produced much more recently, I wonder why is it that on the web, and elsewhere, we are so bad at being backward compatible … and I recall my own ‘pain and tears‘ struggling with broken backward compatibility in office 2008.

I’d started looking at current  rich text editors after seeing Paul James’ “Small, standards compliant, Javascript WYSIWYG HTML control“.  Unlike many of the controls that seem to produce MS-like output with <font> tags littered randomly around, Paul’s control emphasises standards compliance in HTML, and is using the emerging de-facto designMode2 support in browsers.

This seems good, but one wonders how long these standards will survive, especially the de facto one, given past history; will Paul James’ page have a similar notice in a year or two?

The W3C approach … and a common institutional one … is to define unique standards that are (intended to be) universal and unchanging, so that if we all use them everything will still work in 10,000 years time.  This is a grand vision, but only works if the standards are sufficiently:

  1. expressive so that everything you want to do now can be done (e.g. not deprecating the use of tables for layout in the absence of design grids leading to many horrible CSS ‘hacks’)
  2. omnipotent so that everyone (MS, Apple) does what they are told
  3. simple so that everyone implements it right
  4. prescient so that all future needs are anticipated before multiple differing de facto ‘standards’ emerge

The last of those is the reason why vfridge’s DHTML died, we wanted rich client-side interaction when the stable standards were not much beyond transactions; and this looks like the reason many rich-text editors are struggling now.

A completely different approach (requiring a  degree of humility from standards bodies) would be to accept that standards always fall behind practice, and design this into the standards themselves.  There needs to be simple (and so consistently supported) ways of specifying:

  • which versions of which browsers a page was designed to support – so that browsers can be backward or cross-browser compliant
  • alternative content for different browsers and versions … and no the DTD does not do this as different versions of browsers have different interpretations of and bugs in different HTML variants.  W3C groups looking at cross-device mark-up already have work in this area … although it may fail the simplicty test.

Perhaps more problematically, browsers need to commit to being backward compatible where at all possible … I am thinking especially of the way IE fixed its own broken CSS implementation, but did so in a way that broke all the standard hacks that had been developed to work around the old bugs!  Currently this would mean fossilising old design choices and even old bugs, but if web-page meta information specified the intended browser version, the browser could selectively operate on older pages in ways compatible with the older browsers whilst offering improved behaviour for newer pages.

  1. The vfridge Java Servlets used to run fine, but over time got worse and worse; as machines got faster and JVM versions improved with supposedly faster byte-code compilers, strangely the same code got slower and slower until it now only produces results intermittently … another example of backward compatibility failing.[back]
  2. I would give a link to designMode except that I notice everyone else’s links seem to be broken … presumably MSDN URLs are also not backwards compatible 🙁 Best bet is just Google “designMode” [back]

paying the tax

tax collectors get a bad press, but we have just got to the end of filling in our annual tax returns online and is an amazingly trouble free process … I can still remember when it was paper forms and 2 days before the final deadline we’d discover we needed extra green pages for this thing or other. Now-a-days you just fill in the boxes on the web form, if you haven’t got the figures it just remembers it all for later, then at the end you press the button and it works out everything. And even better, they said they owed me £80 🙂

If only every online service was as good. A short while ago we tried to open a savings account with the Northern Rock and gave up as the applet-based system they use is not compatable with Apple Macs … other banks seem to be able to use SSL for security and browser-independent HTML, so why not them! Suffice to say we went elsewhere.

Even worse was an experience early last year. I’d given a seminar at another university and submitted an expense claim. The university sent me payment advice as an email, but it displayed oddly when I viewed it and got a high spamassassin rating. A bit of digging and I found that the high spam rating was due to the fact that there was not a closing body tag in the HTML. I was going to mail the university IT support and then saw that the company who supplied the software, Albany Software, was named in the email and decided to mail them directly to avoid embarassing them to their client.

So I went to their web site … but it didn’t display properly in Firefox, I tried Safari … even worse! Eventually I got their ‘support’ contact email by using view source and mailed them, mentioning both the broken HTML in the email and the broken website.

The reply from their ‘support’ email:

“Try using Microsoft Internet Explorer. Though Firefox is vastely superior, most websites/applications are only compatible with Internet Explorer.”

Who said the days of the old sys admins had gone!

The happy end to the last story is that I just revisited their site, they have at last got it working cross browser … well I guess better late than never.

Anyway thumbs up for Her Majesty’s Revenue & Customs, even if others need to catch up a little.