Getting serious about Web standards
February 26, 2001
I care about Web standards. I’ve criticised Web authors for generating cruddy, non-compliant Web pages. I’ve argued that if we are to take standards seriously we must design so that all browsers can see our information, and accept that this means the pages won’t look the same in all browsers, and I’ve slammed browsers both well-known and lesser known for their lack of standards compliance. I’ve shown that lack of standards is slowing down the progress of the Web, making it a stodgier, higher-cost medium than it should be.
So I hope you can forgive the sense of déjà-vu I experienced when I first read the Web Standards Project’s Browser Update campaign page.
The funny thing is, the Web Standards Project and I came to the same conclusions about the need for standards for very different reasons. I agree with a lot of what Zeldman and the Web Standards Project are about, but our histories are very different. Without giving away too much about my true identity, I can tell you that I am not Jeffrey Zeldman. For a start, I’m female and Australian. He’s male and American. Zeldman is a professional Web designer with paying clients. I am an intranet manager in a large, conservative government organisation that doesn’t want to pay anything for this new-fangled Web thing.
We have both concluded that it’s time to seriously move to using the standards, because of the astonishing loss of efficiency incurred by continuing with the HTML hackwork of nested tables, font tags, and other crud people have to put up with. He’s done it because doing multiple versions of sites and adding one-cell tables everywhere is a pain. I’ve done it because Web technologies are meant to enhance productivity. Building multiple sites is much less productive than pre-Internet information production and dissemination. If a technology doesn’t enhance productivity, it has no right to exist in an organisation.
MacEdition already does and has always done most of the things advocated by the Web Standards Project in their latest campaign. Our HTML validates. We use a tables-based layout (I’ve explained why before), but we use CSS for all formatting except table dimensions and the color charts from my previous column. The stylesheet validates, too. We test in multiple browsers, but we don’t beat ourselves up if the look is a bit different.
I certainly want users of Netscape 4 to upgrade. Buggy, broken CSS support is worse than none at all. With IE 5 already here, OmniWeb and iCab coming on strong (without CSS yet, but promised for the final), the early alphas of Opera looking very promising, and even Netscape 6 improving in its second release, it really is time for Netscape 4 to die.
That said, I won’t be joining the browser update campaign specifically. Non-CSS browsers like AvantGo will always need to exist. As the people behind the campaign subsequently clarified, they don’t really mean that users of older browsers should be excluded from sites altogether. But no browser sniffer code is going to understand these nuances, and their conditional code relies on CSS, with no way to assess compliance with other standards like XML and HTML 4.0.
It’s also not really feasible for many sites to be completely hard-core. It’s relatively straightforward to write compliant HTML, get rid of FONT tags, and use CSS at least for typography and colors. Getting the rest right, however, is beyond the experience of many people: even Zeldman and the A List Apart crew needed the help of two CSS experts to make that site do what it should in CSS. Not everyone has access to such experts, or time to work all this stuff out for themselves. (Of course, we find the time to create multiple versions of sites for different browsers, and seem to think this is justified.)
I’m not going to call on you to upgrade browsers other than Netscape 4. If a non-CSS browser like Lynx or iCab or Netscape 3 serves your needs, I am not going to tell you to use something different. But neither am I going to hobble sites because of the lack of CSS support in those browsers. So things will look different to users of those browsers. If you can live with that, so can I.
— CodeBitch (email@example.com) is the grumpy cow who does the HTML production for MacEdition.