The right side of the road
April 8, 2002
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
A typical response of those less enamoured of Web standards is that what we call Web standards are only recommendations, and that the W3C isn’t a real standards body like the ISO. This is true, but you should still take its work seriously.
I’ve long noted that you can’t expect your page to look identical in all browsers at all times. The perceived Wintel monoculture has narrowed the view of what constitutes the Web audience.
People forget about WebTV and the other console-type browsers, except as an excuse to use font tags instead of CSS (erroneously, I might add – WebTV supports CSS typography). But they shouldn’t overlook them. Sure, the WAP revolution was so much blue sky and bad business models, but “non-standard” devices are still an issue. There are still too many versions of too many browsers on too many different platforms for even the largest Web shop to test for thoroughly. In any case, the largest Web development shops are the ones inside big portal sites, and whose sites are too big to test every nuance manually. Big shops need standards, just like they need consistent coding practices, source control tools and style guides.
So how can you decide how your page “should” look, given various other
constraints like screen size and resolution, without some sort of standard
or guideline? You expect that
color="#ff0000"> will give you something approximating
red on a color screen, so why isn’t it legitimate to have a margin or
border property that works properly? Standards give
you guidelines on what to expect, and on how to get the effect you want.
Standards give you something to hold onto, in a diverse world that that is
necessarily unforgiving of designers’ attempts to
enforce pixel-perfect layouts.
The benefit of standardisation is too important to wait for someone to decide on the optimal standard. “Good enough” is okay, provided we can agree on it. What matters is not which side of the road we drive on, but that we all choose the same side. We can even choose different sides in different contexts, provided those contexts are well understood and separated from each other. Now you know why only island nations like Britain, Australia, New Zealand and Japan drive on the left. But if an Australian like me finds herself driving a car in the US, I’d better start driving on the right, however unused to it I might be. (Similarly, I might have learned to spell “colour” in school, but I had better spell it “color” in CSS style rules.)
So it is with Web standards. Maybe they aren’t perfect. But they are better than the 1995 world of blink tags and “Best Viewed With...” banners. For instance, I happen to think that padding being in addition to width, instead of part of it, is annoying. I’m sure it has been designed very well, but sometimes my little brain doesn’t deal with it so well. It makes it harder to mix up units, say by having 2em of padding around the text of an item that takes up 50 percent of the width of the screen. Because padding is in addition to width, not part of it, this means you might risk creating a layout that’s wider than the screen. Instead you must define left and right margins for the elements immediately inside the DIV, which are part of that DIV’s width, rather than padding for the DIV itself. But I’d rather have the box model we have, than no box model at all.
The consequences of not following Web standards are less dire for general interoperability of the Internet than, say, TCP/IP being interoperable on all computers. So perhaps the recommendations of the W3C are less critical than the standards promulgated by the ISO or IETF, at least for now. Still, I wouldn’t be surprised if, in a few years’ time, the W3C recommendations settle down to something stable and become more like formalised standards. That means they could become a lot less ambiguous – but a lot more prescriptive. Don’t forget that there actually is an ISO standard HTML, and it’s at least as strict as the W3C recommendations. In particular, the ISO version mandates using heading tags in order – no H3 after an H1 without an intervening H2.
There are times when you simply can’t get the effect you want in a
buggy browser without using something proprietary. So if you absolutely,
positively have to have a
proprietary attribute in your
<body> tag to make
your page look right in Netscape 4, I’m not going to run crying
to Mommy. Still, you should be sure that
these are the sorts of non-standard things you are doing, not just sloppy
tag soup excuses for HTML that aren’t even well-formed. And that still
means knowing the standards, and understanding why you are going outside
them. It also means not crying if you are going outside the standards and
work as you expect. Don’t expect a particular response in different
browsers if there is no agreed-upon document specifying how they should behave
to, say, a
LAYER tag, or an IE behaviour, or a CSS property starting with
-moz, or a piece of markup that isn’t properly nested.
You aren’t bound by legislation to adhere to the W3C recommendations for HTML and CSS, although you may be bound by legislation to produce web content with other characteristics like accessibility. Nonetheless, Web authors everywhere are entitled to expect that when they do follow the W3C recommendations, browsers will do likewise. Currently that’s not happening, because of old browsers and new browsers produced by companies that seem to have little understanding of what the W3C is for.
So that’s why, when software companies’ spokesdroids say, “We support standards where it makes sense,” I get mad. They don’t really mean it. They aren’t talking about, say, not supporting Aural CSS in a visual browser, or visual formatting CSS in a screen-reading browser.
Rather, they are trying to wiggle out of support for all aspects of important Web standards on false grounds. Supporting parts of a standard and not others makes no sense and actually undermines the standards’ objective.
The benefit of standardisation rests on supporting an agreed-upon set of guidelines. That means whole standards, or at least whole modules of standards. Supporting different parts of the standard from those supported by other products makes even less sense. It’s strange, then, that very often, the companies seeking wiggle room on W3C recommendations have representatives on the committees that write these standards.
As I’ve said before, left hand, meet right hand.