Coding to standards

Zeldman‘s article in the Digital Web Magazine, 99.9% of websites are obsolete has already generated a fair bit of discussion, but because I’m so self-important, I thought I’d pitch in my $0.02.

Yahoo’s front page is served millions of times per day. Each byte wasted on outdated HTML design hacks is multiplied by an astronomical number of page views, resulting in gigabytes of traffic that tax Yahoo’s servers and add Pentagon-like costs to its overhead.

The idea that inefficient code is expensive has never really crossed my mind before. I’ve never worked on a site where an extra tag would have any effect on the cost of the website. However, blow that up to Yahoo-scale hits, and I can see how it would. I have, for a long time, when writing Cold Fusion, minimized the output from it. I read, back in the days of Cold Fusion 2.0 that extra white-space created by Cold Fusion can add to processing time, so I quickly learned all the tricks to minimize the whitespace created by CFML.
Until I delved into CSS, I’d never realised how much extra space ‘traditional’ HTML took up. Writing the Oak Bay Soft Trends website, I wrote the first version in tables & spacers (or traditional layout). I’d already moved from using font tags, so that reduced some space used. However, when I decided to take the leap and generate a fully table-less layout, while my stylesheets grew by 20 or 30 lines, I probably lost 100 lines of code, along with at least 10 spacer images per page. Yes, the spacer was less than 1 Kb in size, but blown up and multiplied, it all adds up.

What do developers mean by “backward compatibility?” They mean using non-standard, proprietary (or deprecated) markup and code to ensure that every visitor has the same experience, whether they’re sporting Netscape Navigator 1.0 or IE6. Held up as a Holy Grail of professional development practice, “backward compatibility” sounds good in theory. But the cost is too high and the practice has always been based on a lie.

Another project I’ve been working on, Bookbuffet, has gone through some of this. Originally, this site was purely CSS-2, no tables or anything. However, it uses 3-columns that are divided by a 1-pixel border. It is, as far as I can tell, impossible to achieve this in CSS. In it is easy to do with tables. And so I made the call to use tables for the skeleton of the code, and use CSS for all positioning, formatting within the tables. Which seems like a decent compromise. It was all looking fine and dandy across the version 6 browsers on the PC (Mozilla included). In older PC browsers, it looked pretty horrible, but there was a big header up top telling people to upgrade, which is as intended. However, I’d yet to test it on a Mac. The mozillas and netscapes were fine. IE 4 Mac, however, was horrible. First, it passed the standards-compliant browser test, even though it isn’t. So I added some javascript to counter that. Then in IE 5, there was all sorts of goofy layout things. It seems to have some nesting issues, and it was compounded by my inability to add & subtract (for the ‘Ç’ hack for floating elements). So I fixed that. However, this seems to have done some serious damage to how the site displays in Opera. For now, I’ve made the command decision to ignore Opera, hoping that Opera 7, rewritten with better DOM support will make it better (as things that make the site display properly in Opera seem to break it in IE 5 Mac) (second aside – every other browser appears pretty consisten across platforms, except for IE PC vs IE Mac. Grrrrr).

But now, I’ve discovered that the client, and possibly a fair percentage of the target audience uses AOL. I don’t know what versions. What I do know is that the site appears to break in whichever version of AOL the client is looking at it in. I’ve heard horror stories about AOL’s browser, but not having an AOL account, I’ve currently no way of testing this myself. But if AOL’s browser doesn’t support these standards, and they can’t upgrade to a ‘normal’ browser (or can they? how AOL works is a mystery to me), I may be forced to write a ‘backwards compatible’ version of this site, just to satisfy the percentage of users (not to mention the client) that uses AOL. Which I really, really hope I don’t have to do.