Codebitch : Click to return to MacEdition homepage

Regression black and blues

November 19, 2001

Feedback Farm

Have something to say about this article? Let us know below and your post might be the Post of the Month! Please read our Official Rules and Sponsor List.


Want to dig even deeper? Post to the new MacEdition Forums (beta)!

To most of us, regression is something you do with a blanket and a teddy bear, and possibly a high-priced therapist. To those of a statistical bent, a regression is something you do to analyse the relationships between various data series. To computer programmers, a regression is a bug that wasn’t in an earlier version of your code, but gets introduced in a later version. In particular, regressions happen when you fix a bug but then it crops up again in a later build. This column is about one of those regressions. And sadly, it’s with a browser that’s often covered here for all the wrong reasons, Netscape.

One of the advantages of pursuing a standards-based, CSS-oriented design is that you get to identify bugs early. Web authors who perpetuate improperly nested tag-soup messes hit as many – if not more – bugs, but their coding practices make those bugs much harder to identify. Of course, it never feels like a good thing at the time, but here at MacEdition we’ve identified the border crashing bug in Netscape 4.0x, the bizarre gaps in OmniWeb’s background color support, the breaking-links-with-borders problem in Netscape 4.x, a problem with spans in centred paragraphs in Mac IE5 and some wacky things in iCab. None of these bugs have been greatly publicised elsewhere, or at the very least you read it here first. All this has happened because those browsers have choked on some feature of MacEdition’s design. And because we use standards-compliant HTML and CSS, we can be pretty confident that it’s their fault and not ours. Web authors who aren’t so careful about standards can never be sure that the glitches in their sites aren’t their own fault.

Now, I don’t actually have time to test MacEdition in every new version of every browser. Major versions, sure, but not every nightly build of Mozilla or pre-release beta of OmniWeb. Fortunately, we have an array of faithful readers who let me know if the latest version of Brand X browser is choking on MacEdition. So it wasn’t long before the reports of a bug in the newly released Netscape 6.2 started appearing in my In box.

At first I thought it was something I’d done wrong. Even though our HTML markup and CSS stylesheet validate, it’s always possible that you’ve done something innumerate like defining a layout that takes 110% of the page width, or created a stylesheet with mutually inconsistent instructions for styling the same part of the page. But it wasn’t me. It was Netscape. Between versions 6.1 and 6.2, a bug was introduced into Netscape that wasn’t there before.

The problem is this: In Netscape 6.2 (and Mozilla 0.9.4 and 0.9.5), the orange sidebar on MacEdition pages loses its background color when you scroll down. So you get black text on black. If you windowshade the window (on a Mac) or reload, the correct color will come back. You can see this in this simplified test page that I constructed; just make sure your browser window is small enough to make scrolling necessary, and then scroll.

The problem only occurs with row-spanned table cells; ordinary table cells are fine. So it probably won’t affect very many Web sites. Nonetheless, it needs attention, and naturally I have reported it into the Bugzilla system. On the other hand, our readers also report that the problem is fixed in the nightly builds already. That’s a comfort for now, but it still means that plenty of people will be using browsers with this bug in it for some time.

Call the doc!

The wacky thing is that I can fix this by using a short DOCTYPE declaration (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">) at the beginning of all our pages, or the Version 4.0 declaration (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "">). Using a short DOCTYPE, or no DOCTYPE at all, activates Netscape’s “quirks mode,” where the bug doesn’t seem to fire. You can see this for yourself by checking out the test page I mentioned earlier, and a page that is identical except for the DOCTYPE declaration. (You can also see the difference the two DOCTYPEs make to the way Netscape 6 renders the page.)

More information on DOCTYPE switching:

But we use the long version of the DOCTYPE, complete with URL (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">) because we want proper standards-compliant rendering in the browsers that do DOCTYPE switching. We author to the W3C standard box model and I want browsers that can support it to do so. If I change the DOCTYPE to the short version, not only will I activate quirks mode in Netscape 6 and its Mozilla sibling, but also IE5 for the Mac and IE6 for Windows. I don’t relish changing all the DOCTYPEs, anyway. There’s nothing quite like having a dial-up connection and being on the other side of the world from the server to make you reticent to re-upload the entire site. And it seems like a waste of energy to do this when it’s bound to be fixed in a later version, given what we know about the recent nightly builds.

At least I can turn off strict rendering in Netscape 6 without doing it in the versions of Internet Explorer that do DOCTYPE switching. The trick is to use a full DOCTYPE with URL, but specifying it as Version 4.0, not Version 4.01, like this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "">. In fact, that’s exactly what I’ve done in the test pages.

There are a few things I can and have done to make things a bit more palatable for users of Netscape 6.2 and related Mozilla builds. I’ve made sure that links in the sidebar will still have orange backgrounds, even though the surrounding space will sometimes be black. I can also wrap all the content in each paragraph in an otherwise unnecessary SPAN tag, since it seems inline tags with background-color styles work, even though block tags like paragraphs and headings are affected by this bug. These are trivial fixes relative to changing all the DOCTYPEs, because the stylesheet is just one file, and the include file containing the sidebar content is one other.

The whole episode has been rather disappointing. Netscape 6 has some of the best standards support in the business, and it’s finally getting fast enough and stable enough that people are actually using it. Then a regression like this one comes along. It’s enough to make me want to curl up with a blanket and a teddy bear...

— CodeBitch ( is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend

Talkback on this story!

Cannot connect to the database.
Please contact the administrator.