On the Soapbox

One of the things that I was looking forward to trying out was the use of CSS for layout. Prior to this, I've used CSS for formatting and tables for layout. It seemed to be the hip new thing to do, and that everyone was doing it, so this should be fun, right?

The Good

The upside to doing this is the divorce of layout from the actual HTML. It was really refreshing to see how clean the HTML code looks compared to the code that I had for my previous website. What I used to do with lots of nested tables I can do now with a few DIVs. It's easier to tweak and adjust my layouts, too. The nicest thing is that for a script-generated site like this, having lighter HTML also means that the script that is generating the page is also much cleaner and easier to look at. And as a bonus, the site is also somewhat usable when CSS is disabled (in Firefox, go to View > Page Style to see what it looks like with all the CSS off), so when I'm browsing using text browser like Lynx (which I sometimes do, actually), things work.

The Bad

And then there's Microsoft. Years ago, when the browser wars were raging between Netscape 4 and Internet Explorer, I was rooting for IE. This was before Gecko, of course. It was such a relief to have a browser that would render what you tell it to render instead of seemingly randomly deciding to made something either 10 pixels wider or narrower (which was what Netscape 4 was doing). I hated the web design process back then because I spent significantly more time tweaking the code to work around the various bugs in Netscape 4 than I spent working on the design itself, so I was not sorry to see Microsoft win the browser wars. But the times have changed, and ever since mid-2003, I've been using Firefox (or Firebird as it was called back then) as my default browser. So come time to do the layout, it was only natural for me to do all the preliminary work on my default browser, following the W3C specifications. That was a dumb thing to do, because as soon as I started to test the layout in IE, things got nasty, either because of spotty CSS implementation or because of the countless bugs in IE. I eventually ended up spending more time banging my head against the wall, cursing Microsoft, and working around the IE-related problems than I spent on the actual layout itself. Déjà vu with an ironic role reversal.

The Ugly

Whoever at the W3C who decided that it would be good a good idea to officially deprecate the use of tables in favor of CSS for layout should be shot. There are certainly many delightful benefits (as mentioned above), but there are severe shortcomings of using CSS for layout. The whole notion of floating the CSS boxes to do columns is really a hack. Just as tables were meant for tabular data and not for layout skeleton, CSS boxes were meant to format parts of a page and not to serve as a layout skeleton, and the liberal use of float to try to shoehorn it into the role of serving as a layout skeleton is just as unwieldy as the use of tables. It also doesn't help that IE is a bit bugged in respect to all this. The lack of stretchable dimensions (or at least the ability to define it with mathematical expressions without resorting to JavaScript) is annoying as well (no, the percentages don't count because you run into rounding problems with them and it doesn't help when sibling elements are fixed in size). Positioning is also a royal pain in the ass. You can either go with the flow, float the position, or take an absolute position in respect to the canvas. There's no way to take an absolute position in respect to something that is relatively positioned (like a parent element). This makes absolute positioning pretty much worthless unless you use it for the entire page (which is not only tedious and difficult to maintain in the long run, but also misses the point). In the end, I found that tables are MUCH easier to work with for layout. They may be ugly and bulky, but at least they are suitable. I do love the benefits of CSS layouts and would love to see the day when CSS layouts completely displace table layouts, but that will require enhancements to CSS to allow them to perform that role. It seems ridiculous that they would deprecate something without first ensuring that the replacement is suitable.

Oh, and another rant against the CSS box model: there are benefits to setting the width and height to the inner content width height. This is especially true if the size of child elements are known and thus it's easy to set the parent's width and height. But in layouts, dimensions are often constrained not by child elements, but by sibling and parent elements, which is why Microsoft's way of doing dimensions in IE5.5 and earlier made a lot of sense: the dimensions of an object representing the content dimensions plus the padding and border. For example, if you have a parent div that is 400 pixels wide, and you want to fit two boxes with a margin space of 20 pixels in between, setting the width was easy: (400-20)/2. But with the official CSS box model, you have to toss the border and padding into that equation, making it slightly inconvenient (especially if you are tweaking the border and padding to see what looks best). This is especially troublesome when working with percentages. A child that has any sort of border or padding can never use a dimension of 100% (making it impossible to get a child with a border and/or padding to match the size of the parent if the parent's size is unfixed). A sensible solution would be to introduce an alternate measure of dimension like outer-width and outer-height, which can be set in lieu of width and height. Another solution would be to accept mathematical expressions in CSS, such as width: 100% - 8px.