Netscape 6 PR3: Swings and Roundabouts

9 October 2000

After what seemed like months of blissful inactivity, the folks at Netscape have released two public releases of Netscape 6 in a relatively short period. After critiquing Preview Release 2 in my last column, I owe them the courtesy of giving Release 3 a fair examination. This is my initial reaction after a few days of use; perhaps there are other issues that will arise later, but the standards support will still be the same.

Preview Release 3 is a lot better. Loading and rendering pages seemed as fast or maybe even faster than Internet Explorer or iCab, at least in initial usage. If it didn’t consistently fall over on some web sites I visit all the time (including web-based discussion boards used by MacEdition staff to organise our work), I could perhaps use it full-time and not go nuts, despite the inordinate RAM requirements. I could not say the same for either of the earlier Preview Releases.

In a nutshell, PR3 is what PR2 should have been, and is more evidence that PR2 was rushed out before it was ready.

I still think that Netscape as a software publisher should die: three years of inactivity is inexcusable in the Internet age. I still think that Netscape 6, as it currently stands, is not enough to make users of IE 5 for Mac switch. But it’s now good enough that, as a web designer, I would prefer it if all users of Netscape 4.0x switched to it. The standards support is a lot better than any 4.x version of Netscape, but especially the 4.0x series, which has the most entertaining crashes. If people upgraded, they will realise just what they’ve been missing out on all this time.

Win some, lose some

In my column on Preview Release 2, I identified some bugs in the CSS support that Netscape had claimed was “complete”. How does Preview Release 3 fare?

Class names starting with numerals

This is the most glaring example of non-compliance, because it’s something version 4.x gets right. This bug is still not fixed even though they’ve known about this issue for a year.

Problems with floated elements

Definitely better, but now the text in the DIV has small overruns onto the floating elements, which shouldn’t happen.[screenshot]

Image resizing

This has been fixed.

Underlining doesn’t continue under images

This has not been fixed.

Width of replaced elements

Images resize if they are scaled as a percentage of the page body, but not as a percentage of a containing table, so this is only a partial fix.

So of the five glitches I have identified, one has been fixed, and one has been largely fixed. The browser renders the box “acid test” okay, and the W3C float sample page I mentioned in my earlier column doesn’t crash the browser any more.

Unfortunately, new glitches have been added.

Support for :first-letter pseudo class

Netscape 6 PR3 displays this formatting correctly but then loses it when you are scrolling, clicking or even just breathing on the screen. Here are two screen shots to show what happens to one page [one, two]. The formatting usually comes back with a reload, but it’s all very odd. The same problem occurs on this page.

Top padding on inline elements

Top padding on an inline element with a background color overlaps other text. This is probably not strictly against the standard, but it’s ugly. Strangely, bottom padding does not have the same unsightly effect.

Pseudo-class for :hover has stopped working (Bug 55297 and Bug 55067)

One of the parts of CSS1 that users of Netscape 4.x have been missing out on is the ability to make hyperlinks change formatting when you hover the mouse over them – for example, changing color or adding an underline. Lots of sites do it. We do it on MacEdition. People like it.

Regression therapy

The pseudo-class :hover worked in PR1 and PR2, but broke in PR3. According to one of the Mozilla developers posting in the Bugzilla system:

1) this is a regression of functionality that worked earlier 2) IE for Windows and Mac both support this, and there’s already a significant amount of content out on the web that uses this as a result 3) the content community is watching this one *extremely* closely and will be furious if we break even basic :hover in RTM when it was working in previous Mozilla builds – this is some of the highest-profile CSS standards compliance there is 4) we demo the use of this functionality in our standard marketing demos for Netscape 6.

There are also problems with visited style on links in some circumstances.

Again, this is a “regression” bug, something they had working before and then broke later. This is the danger of rewriting everything. You get something working, only to screw it up again. Every little bug fix and patch that was written for earlier versions has gone out the window. The developers now have to make the same mistakes and fix them all over again. And people wonder why we’ll be lucky to see the final release this year, four years after CSS1 was made final!

Even now, there are dozens of bugs in Mozilla and its close cousin Netscape 6 that relate just to CSS1 support.

Yes, Netscape 6 PR3 is almost there, but its CSS standards support can’t be called complete, or even much better than PR2.

So should Netscape die? Maybe not now, unless they keep wasting development resources on building frills into version 4. How many point releases of Netscape 4.x have there been this year? Why aren’t they moving resources into chasing down the last bugs and issues with Netscape 6? Why haven’t they withdrawn Netscape 4 from the market?

Meanwhile, IE, iCab and even AvantGo continue to gain market share at Netscape’s expense. How the mighty have fallen.

— CodeBitch (codebitch@macedition.com) is the currently very grumpy cow who does the HTML production for MacEdition.

E-mail this story to a friend