Glass Maze Every jumbled pile of person

In Defense of Quick and Dirty

Came across this post in the Opera developer blog, on why you should never use browser detection in your javascript to work around browser bugs:

The TinyMCE/Opera 9.5 compatibility problem is a textbook example of why browser sniffing should be avoided at all costs. While it may seem like a quick and simple shortcut to work around a bug in the short term, browser sniffing creates a maintenance nightmare further down the road …

Also, whether you develop your own site or write script libraries that will run on thousands of other websites, the chances are that mistakes you make today will stay on the web for years to come, preventing users from upgrading to newer and better browsers because sites they want to use break.

I have to admit, I’ve often been tempted to use browser detection — and, worse, occasionally succumbed to that temptation. Wrestling with the deficiencies of certain browsers (*cough* IE *cough*) is such a horrible, dispiriting experience that eventually you’ll do pretty much anything to make the pain stop. And if relief is just one if (navigator.userAgent.indexOf()) away, then by golly why not do it?

Well, the Opera dudes make a very good case for why not. It seems to me there are basically four things you need to worry about when you’re writing code:

1. Does it work?
2. Will it work tomorrow?
3. Is it reasonably easy to understand, and maintain?
4. Is it fast enough?

Everything else is a distraction. The TinyMCE fix that the article describes fails test (2), and the alternative solution they propose seems to satisfy all four. So worth doing.

In this case, quick and dirty was a bad idea. But I don’t think it’s always a bad idea. Case in point: CSS layouts. There’s a certain area of dogma in the design community that maintains that all layouts should be handled exclusively by CSS positioning, and never with tables. Tables are for displaying data. CSS is for layouts.

Which makes sense. Tables were certainly not intended to be used for formatting, and you’re sort of committing the cardinal sin of mixing model and presentation if you use them that way — so there’s theoretically very little to disagree with here. But the picture gets murkier when when you descend from the lofty realms of theory into the muck of actual implementation, at which point you run into the raging shitstorm that is CSS.

This isn’t intended to be an anti-CSS diatribe, but any non-gurus who’ve attempted to format their stuff with CSS know what I’m talking about. As soon as you try to do anything even mildly complicated — where by “complicated” I mean more ambitious than changing your background color — you’re suddenly in a scary realm of floats and bounding boxes and content edges and border edges and padding edges and margin edges. I’m not even talking about shitty browser support here — although Jobs know that stuff certainly doesn’t help — I’m just talking about the basic “language”, whose designers appear to have made a calculated decision to sacrifice usability for flexibility. It does seem possible to do pretty much anything in CSS, but the penalty you pay is that everything you do is hard. Which is to say: you have to understand everything if you want to do anything.

I’m certainly no CSS expert, and I’m sure there are several arguments floating around in the vast universe of my ignorance to refute most of the sputtering, incoherent calumny I hurl daily in CSS’s direction. But I honestly don’t think my central point is especially controversial: CSS is really hard to use, and — once there’s a lot of it — really hard to maintain, and it imposes a fund of complexity on your stuff that you shouldn’t have to pay for doing simple things.

Like, for example, laying stuff out in configurations that are more or less … tabular. If you have a layout that doesn’t need to be especially flexible, and really looks a lot like a table, then I’d say make it a table. Tables are easy to understand, easy to write, reasonably fast, and they will always work, in every browser you can think of. Quick and dirty is usually bad. But not always bad.

As additional food for thought in regards to browser sniffing, I have read that Microsoft has sucummed to “defaulting” IE 8 to be standards compliant. Yes, that means that all versions of IE before it defaulted to Microsoft compliant. The issue now is that once IE 8 comes into the marketplace an estimated billion websites (including intranet and browser-based applications) will break. In my opinion this will be a much larger issue than Y2K ever was.

Good point, and holy crap. Y2K+8. I think I still have some bottled water left over from 2000.

37Signals just dropped support for IE6. I think they should preemptively drop support for IE8, too. As should we all.