17 March 2004
This site gave me a good laugh when I clicked on the splash image in IE 6.
For anyone whose user agent actually does identify as "Netscape", I'll save you some trouble and tell you that up came this message: "Sorry, but this presentation cannot run on your browser. We recommend using Netscape Navigator/Communicator 4.x+".
As laughable as installing Netscape 4 is now, back then (HTML 3.2!!!) it would have seemed perfectly reasonable. But then again, restricting year dates to 2 digits in software programs seemed reasonable too. There's no guaranteed way to future proof anything you make, but there are ways you can make sure that they at least have a chance. Restricting content based upon something which you think you can detect is one guaranteed way to go out of date, and at worst make your content inaccessible to users in the present.
Often I'll visit a Flash based site and have the site's scripts say that I don't have the correct version of the plugin, then offer me no way of getting any further. Sometimes I do have the correct version; sometimes I've got a lower but compatible version. I might even have a plugin from an entirely different company which somehow lets me read Flash. Either way, I'm not going to spend a couple of minutes downloading yet another plugin just to view your site, particularly when I don't even have any idea what your site can offer me yet. So, you can warn me that I might not be able to view your content properly, then give it to me to make heads of, or you can lose a visitor entirely. Is it really a choice?
This isn't just my usual Flash beat up though. I can see the same problems occurring with CSS Hacks. When you specify a rule in a stylesheet that is designed to cause errors for one particular set of browsers, your code immediately becomes obsolete. You can't predict what future versions of the browsers will do with that hack. They might apply it properly, they might not. If they don't, you'll have to modify your code – find a new hack, nest hacks, re-write rules – it's a downward spiral. Then, when the next version comes out, you'll do it all again.
All this is totally counter-intuitive to Standards. Standards are there to provide a stable, compatible platform on which to build web pages. A Standards-compliant page written now should be readable by an agent in 10 years time, that's the beauty of them – no compromises, no special treatment; standardisation. In the current climate of frozen browser development it's tempting to ignore the lessons from the past, but if you do, you'll get burnt, and I don't want to be cleaning up your code.
Follow me on Twitter
To hear smaller but more regular stuff from me, follow @themaninblue.
- Resolution dependent layout update
- footerStickAlt: A more robust method of positioning a footer
- widgEditor: A simple, standards-compliant WYSIWYG HTML editor
- Accessible, stylish form layout