(Dis)graceful degradation: Don’t support bad (beta) browsers
22 January 2001
No Web designer can check his or her sites in every existing browser. It’s hard enough to ensure that things work in the major browsers – let alone all existing minor browsers – without worrying about browsers that didn’t exist when you first built your site. That’s why Web designers want standards. They don’t want to have to hunt down every bug themselves, and they don’t want to have to check 57 varieties of compatibility checkers, CSS bug lists and test suite results. A Web without some reasonable set of standards is an inefficient morass of high-cost development and design conservatism.
Indeed, if you author to the W3C standards now, you have some protection. We heard the screams of pain when Netscape 6 came out. The sites that tend to break in new browsers are the ones that are using malformed HTML, unbalanced tags and proprietary junk, or that are a mess of crazy JavaScripts. Sites authored to standards, such as MacEdition, looked fine in Netscape 6 without having to do any work to accommodate it. Sites using klunky proprietary code simply broke.
If you stick to the standards, things won’t look identical in all browsers. How could they? Things will never look the same in PDA browsers like AvantGo as they do in Netscape or Internet Explorer, let alone text browsers like Lynx. But the site will work acceptably. Readers will be able to see all the information. The site will degrade gracefully.
That’s the theory.
Incidentally, the difference between Netscape 4.0x and 4.5 and higher is one of the reasons the support chart approach is never going to be a complete solution, because they only list major point releases. They cannot feasibly narrow down exactly which point releases are the problem or exactly what causes crashes. It’s too big a task, which demonstrates that the mess of incompatible implementations of Web technologies we have today is unsustainable.
Of course, some old browsers will choke even on valid code.
Netscape 4.0x crashes on
DIVs with CSS border styles in combination with certain other
tags, and chokes rather badly on the ACRONYM tag.
Once you have worked around these bugs, however, you can rest in
the knowledge that newer or obscure browsers won’t rise up
and bite you and your site.
Again, that’s the theory.
Because sometimes, new browsers break all the rules. Despite the trends towards standards support in minor browsers like iCab and Opera, or new browsers like Netscape 6 and IE 5/Mac, sometimes a new browser comes out that can only be described as a backward step. OmniWeb 4 beta is one such browser.
Full CSS support is promised for
the final version. That’s good, but the partial support
in the current beta is worse than useless. Other browsers’
idea of partial support is not supporting certain CSS attributes
(like margin) on certain kinds of tags (like BODY).
OmniWeb takes this limitation to extremes: it supports
background-color on BODY but not on any other tag, or
so it seems from the testing we have done. This is a problem for
MacEdition, where the backgrounds of the table cells are set using
class attributes and CSS. So OmniWeb 4.0 beta users are seeing this
article as black text on a dark teal-green background, with links
that are the same dark teal-green. Not good! We won’t be the
only site affected by this: most sites that use CSS for anything
more than link colors use the class attribute, eg for links inside
sidebars. Every site that has a black background and then a white
region with black text defined using CSS is going to be completely
unreadable. Blech.
Yes, it’s only a beta. That’s good news because, being a beta, it will expire and stop working one day. If OmniGroup fixes the problems for the final version, this problem will cease to be an issue when the beta expires.
And that is why, as Web builders, we should not make any efforts to get around this bug. OmniGroup has put out a beta with a half-assed, partial implementation of CSS that is worse than no CSS at all. At least with non CSS-aware browsers like the iCab pre-release or Lynx, readers can see all the information presented, and just miss out on a few colors.
Yes, some users of this beta software will find some sites a bit unsightly. Too bad; it’s a beta. If you are a Mac OS X user who wants a non-MS browser, try iCab or contribute to the Fizilla project.
Update: 23 Jan 2001
OmniGroup has responded in constructive terms to this article. It turns out that they agree with me.
Don’t support bad browsers. I’m not going to redesign the sites I manage in order to accommodate these bugs. Neither should you. Web designers have enough to deal with from three-year-old browsers still in use, without having to put up with new bugs from developers who should have known better. They would have known better if they had driven their “best browser out there” through something obvious like the W3C CSS1 test suite. However, it seems they haven’t done this; it fails just about every test, and most of the tests we constructed while I was writing this column. Their release notes say that the current beta doesn’t support relative positioning, but no word about the extreme limitations of the other aspects of CSS support.
This is one more example of the reason why so many Web designers won’t use stylesheets. More’s the pity. Not only does it mean you can design sites in a more sophisticated way, you can re-design them a lot faster. So if I decided that I wanted MacEdition to look like a Mondrian painting, I could change a few numbers in one file (and the logo), and it would be done.
Try doing that with FONT tags. OmniGroup, get your act together soon,please!