I've been working on a pet project lately, and, as most modern web designers are wont to do, I've been using XHTML and CSS to separate the content from the design. I used to be a loyal follower of the table-based design movement (e.g. this early attempt at a journal design uses 13 columns to get the black border effect while this web mail login page uses three nested tables to get desired effect). I even independently discovered the single pixel transparent GIF trick that's made David Siegel such a reviled figure (though it looks like he had a change of heart while I wasn't looking).

But now, having drunk the XHTML/CSS kool-aid, I've been doing my best to unlearn the old, wicked ways. While I appreciate the separation of markup from content, I sometimes have the impression that this new world isn't much better than the old one. For example, in the aforementioned pet project's front page, I wanted the login form to be vertically centered, and then have the logo image be right above it. The only way to do this is to give the form a specific height, and then use margins of half that dimension to place things above/below it. So far, so good. But what happens when the user bumps up the font sizes (e.g. so that the site can be shown on a projector)? The fixed sizes mean that the text starts to spill out of its section (or is clipped, depending on the overflow option) and generally speaking we have a mess. The remedy would be to specify the size of the box in ems, thus allowing it to scale with increasing font sizes. Unfortunately, the logo image's dimensions are still in pixels, and since CSS doesn't seem to provide a way to combine offsets of different units on a single object, we are stuck. Tables, with their valign property would have made the task easier, and based on a Google search on this topic, it seems that I'm not the only one pining for this feature (tough it is coming in CSS3 apparently). I'm not going to revert back to tables, the advantages of the current system are too great. But I wish the proponents of style-based design would acknowledge that there are some things that their supposedly all-conquering tool can't do.

What really irks me about this new world is the reliance on browser bugs to hide CSS from specific browsers. There are whole sites dedicated to this, and leading designers advocate their use. I shouldn't be so quick to pick on Zeldman, since I find this approach perfectly excusable when dealing with browsers that aren't likely to be updated soon, such as Netscape 4.x and IE 6. However, it has gotten to be slightly ridiculous. For example, when Safari first came out, designers were quick dive in and find corner cases where the KHTML CSS parser bogged down and skipped styles. However, the Safari rendering engine underwent intense development (and still is presumably), with the net result being that some of those hacks no longer work.

Has browser detection gone so out of style that we need to resort to this sort of kludge? I suppose that in this day and age, with user agent strings being spoofed by minority browsers, one cannot always take the user at his/her word, but chances are, if you're technically savvy enough to use such a browser, you'll realize what's going on and fix the problem. I like the approach that JavaScript took to this: test for features, not browser versions (e.g. look for the document.getElementById method to determine if a browser supports the W3C DOM, don't try to infer this from the user agent string). I don't know if such an approach would work for CSS, where browsers claim to support a feature but only do so in a half-assed manner. At the very least, I'd like to see broader support for reporting the rendering engine and its version in the user agent string (as Mozilla and Safari do), along with the necessary server-side (in the short term) and CSS/standards body (in the long term) support to make using such a feature as painless as possible for designers.

Update: It looks like this SXSW panel presentation (presented by such illustrious figures as Eric Meyer and Tantek Çelik) agrees on some level. It doesn't abhor the use of hacks altogether, but it does give some guidelines as to how they should be implemented so they can be "surgically removed eventually." I get the feeling that tips such as "avoid if possible: the problem of mystical 'voodoo' culture in code" show that CSS is become closer and closer to code in terms of maintainability/readability/etc. issues. The mentality that has differentiated good (C/C++/Java/favorite language here) coders from bad ones is going to be required for good designers, and further highlights the closeness between artists and programmers (video).