I’ve been on the standards train for two years or so. In that time, the neurons and mesons of my development habits have been so thoroughly remapped that I have a really hard time thinking in old-school table-based ways. The transition to web standards brings on a fundamental change in how one approaches design challenges. I’ve gone from thinking of web pages as grids upon which to force my pixels to thinking of them as nebulous chains of raw content to caress and finesse into flexible attractiveness. I no longer envision my designs in rigid rows and columns, I see meaningful elements that can be chunked and arranged a million different ways. To quote Klaatu, I’m impatient with stupidity. My people have learned to live without it. As such, being forced to roll back to HTML circa 1998 is a jarring experience.
The site I work on still carries some legacy code from its first version, launched in 2001. It was significantly redesigned a little over two years ago when I came on board, admittedly before I got into web standards. Much of the markup is antiquated and non-compliant, simply because we didn’t know any better. The layout for most of the site is controled by a central template file, wrapping a fairly complex table around each page via ASP includes. I’ve tinkered with a proof-of-concept overhaul of the site template, potentially converting us to a non-tabled CSS-based layout, but that conversion would ultimately require some minor tweaks to many dozens of documents. That cataclysm is simply not a cost-effective resource investment at this stage, so the standardization overhaul shall not come to pass for some time.
Our template contains a malformed/incomplete DOCTYPE, hurling modern browsers into quirks mode. Since quirks mode essentially makes modern browsers behave like Netscape 4, some CSS rules don’t inherit correctly, forcing font-family, font-size, and foreground colors to be re-declared for every element, id and class. As part of my quiet campaign for more standards compliance, I took it upon myself to switch to a correct HTML 4.01 DOCTYPE. I was thus able to cut the size of the style sheet in half by removing loads of redundant style declarations now that our pages were inheriting correctly. Hooray for standards.
But alas, we’ve unfortunately built in some dependencies on quirks mode. I was able to correct the majority of these in the style sheet, but a few basic layout oddities remained. Most especially, our pages are wrapped in a table that features the invalid attribute height="100%" in order to force the table to the full height of the display window, pushing the footer to the bottom and making our left-side navigation bar stretch. Switching the DOCTYPE to invoke compliance mode made pages with short content appear shorter than the window, with our footer floating above a sea of whitespace. While this is technically correct, it’s not aesthetically acceptable in our current design. I temporarily conceded defeat and went back to the broken DOCTYPE. (Sidenote: Contrary to popular belief, the height attribute for <table> has never been part of any official version of HTML, it’s non-standard markup invented by Netscape in the early 90s. It is rightfully ignored in compliance mode.)
But I couldn’t let it go. I decided to try using min-height to make sure the table was never less than 550 pixels high. Knowing that IE/Win doesn’t support min-height, I planned to use the underscore hack to feed an alternate height value to The Standards Bane. Imagine my surprise when IE behaved correctly and Mozilla didn’t. I was sure I had done something wrong. I combed each line, looking for a misplaced semicolon or misspelled property. By all logic my style rule should be working just fine. On a lark, I changed the table to a div and suddenly it all made sense.
It turns out that the min-height property in CSS does not apply to table elements, so sayeth the specs. As usual, Mozilla was behaving exactly as it should. My problem was that I was trying to treat a table like a div. I’m too enlightened for my own good.
The plain old height property does apply to tables. It can’t be 100%, since that won’t jive with the box model (it would need a containing element with an explicit height, and body { height: 100%; } doesn’t work). However, applying height: 550px; to the wrapper table effectively behaves as min-height does on other elements. If the content is longer, the table is forced to be longer to accomodate, just as it always has. If the content is shorter, the table remains 550 pixels high. Using a good old-fashioned valign="top" attribute on the containing <td> keeps our short content from dropping to the middle.
So tomorrow I’m switching back to a correct DOCTYPE. Our site still won’t come close to validation, what with all the other archaic noodle markup scattered around, but it’s a step closer.