Hack: To or not to
Ever since Peter-Paul Koch put online his [quirksmode] web site, his opinions caused quote a stir in web design community. He openly opposes most of the techniques and guidelines many of us advise.
In the Keep it simple column at Digital Web, PPK published an article where he advised developers to avoid the use of hacks, since some new browser version might fix the bug used for hack but not fix the very behavior you are trying to hack.
In the latest article, PPK posted a list of CSS hacks that could be considered safe, since they apply to dead browsers (NN4, IE5/Mac), and dismissing anything else, since the “live” browsers are updated and can fall into a trap he explained in the original article.
I agree with the point about new browser versions and bug fixing. Yes, that can happen. And that’s all I agree with.
Reality bites
“I don’t want to use the hacks” attitude is a wonderful thing, when you are working for yourself. Clients are not (always) inclined to that. Clients mostly don’t have a clue about the technology used, and all that you hear from them is “I want this”, “I like this”. When you bust your mouth off to explain that that something is counter-productive and that they just does not need “to have that fancy rounded border since it will bloat the markup and it will make the site slower” you get slapped with “but this site has it and it’s quite quick”. Yes, on their ISDN or leased line, it is.
Another problem is when client reads somewhere that you should care about each user, and that each of them, no matter what they use, should have the same, nice site experience. Especially problematic in the 4.0-browser era, when user sees some dynamic effect and he wants it in all browsers.
So, in the old days, first problem was solved but adding more and more nested tables. Second problem was resolved by creating several versions of the same presentation, not to mention 3 versions of the script.
PPK’s site is full of very good examples of such scripts. In the heart of them is this:
if (document.getElementById) {
...
} else if (document.all) {
...
} else if (document.layers) {
...
}
For years, we were forced to cope with this. Not because we liked it, because we had to. In order to stay in business, you had to deliver. And with 60% IE4, 35% NN4 and 5% for others (figures changed during the time) you had to deliver for all of them.
And yes, that script above is hack.
What’s the difference?
This is where I’m puzzled with PPK’s stance towards CSS hacks. In the essence, CSS hacks are doing the same thing object switching does. It allows us to support all (ok, most) competing browsers. If you are against the hacks, why then promote them in one area and forbid them in another?
Next browser version can fix the bug you used as hack, and you will have to redo the style? Oh, really? Is it so much of a problem to change few style sheet files?
Even if the project in question is finished and delivered long time ago, it is linked from your portfolio section (you don’t do web sites you are ashamed of, right?). If it’s broken, you should go and fix it - otherwise your portfolio will work against you. I will always fix such things, always for free. My references will still be valid, and the client will be more than happy and is likely to give me another job or recommend me to someone else. It happened to me several times in the past.
And who can be sure that DOM hacks will be valid in the future? Take Opera 6 for example. It supports document.getElementById and few other basic DOM stuff, but has no clue about almost everything else in the DOM. And Opera has signed major deals with manufacturers of wireless devices. Development of particular device can span years, and some decisions made few years ago will affect the product which goes to market today.
How can you tell that your script will work in future? By checking for each DOM property you use? Not likely, since such script will be bloated and slow.
This kind of reasoning always has two sides, and can be defended and attacked in the same time. You use what you need and can. By urging designers not to use hacks, PPK is forcing them to develop sites using deprecated, wrong methods.
Why?
Consider simple example: creating horizontal menu (or tabs) using float:left for LI elements.
CSS2-compliant browsers are good with width:auto. IE5/Mac needs fixed width. IE5/Win needs fixed width as well, but it’s a different width because of wrong box model. Opera 6 will make the list 3 screens long if you don’t specify width. If you do specify width, then you have to worry about line breaks for menu items with more than word. Etc, etc.
It’s hell. But it’s manageable hell, and you can fix it in the future, in an hour or two.
And you have excellent, semantically marked pages that will work even on Netscape 2 or Pocket PC 2002 (which has very basic HTML support). Even if the case comes up when some browser passes all the hacks and fails with wanted display/behavior, you can use server or client-side detection to not load the particular style.
By not using hacks, you will find your self in the position to use tables to make that menu. Yuck.
Web designer’s job is not easy. But today is immensely easier than few years back. Browser market is largely dominated by browsers that more or less conform to CSS/DOM standards. That gives as liberty to forget about DOM switching (well, not entirely, but we are getting closer). Gives us liberty to produce pages with unbloated markup and style them so that they reflect what client wants. And all that consumes 2 or 3 times less bandwidth.
And CSS hacks allow us to do what we always did. Deliver the same user experience to 95-99% of users.
Keep it good. Keep yourself in business.