The minor browsers grow up
May 7, 2001
The browser wars are back. It’s like 1996 all over again, with three minor browsers already winning users in their pre-release forms. All three of them talk the talk on Web standards, but do they live up to their promises? And if they don’t, can they do it in time for their final releases?
OmniWeb: “Best browser” – for users – but still a CSS bugbear
OmniWeb has its adherents amongst users, and with the release of the final version of Mac OS X, its usage is set to rise. In MacEdition’s latest stats, it rocketed to about 6% of pageviews, not that far below the beta of IE 5.1 that came with OS X. Before the release of the final version of Mac OS X, OmniWeb never got above one percent of pageviews.
I’ve previously complained about OmniWeb’s CSS handling. Previously, it
only supported background colors for the
BODY of a page. That made
MacEdition unreadable, and I wasn’t happy. OmniGroup
was very responsive and
to fix it. On the
other hand, I’m not convinced that they really get it. On April 4,
OmniGroup’s Ken Case posted the following to their
Mac OS X-talk e-mail
The problem is [sic] adopting the Gecko engine is that they seem to have different goals than we do: they apparently want to render standards-compliant web pages, we want to render all web pages. OmniWeb today does a much better job of rendering Netscape 4.x-targetted HTML (i.e., most of the existing web) than Gecko does.
Rendering crappy HTML in a readable way is very different from rendering syntactically correct, valid HTML and CSS in an unreadable way. If OmniGroup want to do the former, I can live with it, as long as they support standards enough to avoid doing the latter. Web designers shouldn’t be punished for using W3C standards.
Things are certainly better in the final candidate releases currently being
used. OmniWeb now also supports CSS
background colors on table cells, so you can read MacEdition again without needing
bionic eyes. Unfortunately, even this basic
CSS styling is not fully supported across
the range of tags:
DIV tags are currently not supported, so the
MacEdition look you get is similar to the incorrect behaviour under
Netscape 4, not the correct behaviour of IE 4+, Netscape 6 or Opera.
Remember, people – Netscape 4-type CSS
support is not something to aspire to.
The danger in OmniWeb is that it is such a good browser from general users’ perspectives. Its users rave about the toolbars, spell checking and other features. Although Mac OS X will largely appeal to professional users rather than home users, not all of these are Web authors. Certainly, not all pro users are Web authors who care about standards – will they pressure OmniGroup enough to do something about this? Until these issues are fixed, Web authors who do care about standards are going to have nightmares as the market share of OmniWeb rises.
Mainstream sites are going to ignore OmniWeb, while Mac-oriented sites are in for a rough ride. As a minor browser on the minority platform, the standard resources will probably not pay much attention to it. So the bugs and workarounds are less likely to get documented and designers are more likely to just design conservatively instead of making the effort to design using 1996-era standards and avoid glitches in this browser. This is a pity, because right now there are a lot of sites that look completely messed up in OmniWeb. Until OmniGroup get it together, it looks like the burden of dealing with this browser’s glitches is going to fall on authors of Mac-oriented sites. Question is, who is going to carry that burden? I know I can’t do it alone. I haven’t even begun to touch on its support for CSS2, XHTML, ECMAScript or the DOM.
Opera: Is the fat lady singing for Netscape?
Opera for the Mac has been promised for almost as long as Netscape 6.0 was. Finally, we have our hands on the technology preview, and we are very impressed. Yes, it has taken a long time – largely because the Opera people had to replace their original Mac development contractors – but even the initial Opera Technology Preview is a better candidate than Netscape 6.01 for replacing Netscape 4.x.
Tony Leggett has already discussed Technology Preview 1 from a user’s perspective. But what does it mean from a Web author’s perspective? The addition of Opera gives Mac users three browsers that are close enough to standards compliance, and two that are stable enough to use. It has some glitches, sure enough, but its CSS1 rendering is largely correct and certainly better than IE5 for Windows or Netscape 4 (not that Netscape 4 is hard to beat). In general, it seems that the glitches it has are the same as those in the Windows version, so Web authors and developers can refer to existing resources on compatibility, like Eric Meyer’s Master List and the CSS2 test suites from David Baron and Peter-Paul Koch.
The one glaring error, which has been mentioned elsewhere, is the way
Opera/Mac handles font sizes. For instance, it maps normal text to the
font-size keyword “
small,” not “
(IE makes the same mistake). It
displays font sizes smaller than it should, especially for fonts defined in
terms of pixels. There also seems to be a problem with inline styles (the
style="" attribute) and the compact
font” method of defining multiple font
font: bold small-caps italic 1em/2 Georgia,
Baskerville, 'New Baskerville', Palatino, serif;. Defining all the
individual styles separately works fine, as does the compact notation in an
embedded or linked stylesheet. You can see
examples of these problems in this font-styling test page I constructed.
Opera promises exceptional scope for customisation using user stylesheets, but
for now many of these preferences are buggy or don’t work at all.
For the record, here are the CSS1 glitches (other than font sizing) that I have detected in Opera using the W3C’s test suite. Except for the first one, they are all pretty minor.
- Section 5.2.7: Text in the table is bigger than text not in a table.
- Section 5.3.5:
background-attachment:fixed: This was buggy in Preview 1 but it has been fixed in Preview 2.
- Section 5.4.3: Underline doesn’t continue under the graphic; the same bug Netscape 6.0 has.
- Section 5.4.5: Special characters not uppercased/lowercased but instead appear as they do in the source.
- Section 5.6.3: Disc and circle are the same for list items
There are also some glitches with the box model, as Owen Briggs has found with my help. Most Web sites look as they should in Opera, other than the font-size issue. (About the only one I’ve noticed a problem with is Rudeparrot.com.) Opera’s support for CSS2 isn’t as comprehensive as its CSS1 support, but it gets a lot of things right.
There are significant limitations in its support of HTML entities. Curly quotes are rendered as straight, and Greek letters aren’t rendered at all: something IE 5, iCab and Netscape 6 all support. Other than this, I would describe Opera as being a browser that, even at this early stage, is close enough to standards-compliant that Web authors can move forward with Web standards, confident that Opera users will benefit.
iCab: Speedy usability champ, but some problems with its style
I’ve always had a soft spot for iCab. Its smiley face is an excellent check against accidental markup mistakes, even though it isn’t formally a validator. I use both Opera and iCab for my personal browsing. I love the fact that it only takes up a few megabytes of RAM, unlike behemoths such as Netscape 6 or its Mozilla sibling.
iCab has always been great from an accessibility perspective. It supports
things like titles on
ACRONYMS and every other nook and cranny of HTML 4.
Its preferences dialog is a joy. Its ECMAScript support isn’t finished but
it’s getting better with every release. It has an interface for dealing
with all those meta tags that people put in. And its graphics filtering is
even more sophisticated than Opera’s.
Pre-release Version 2.5 adds partial support for
and it’s not bad for
a partial first attempt – better than Netscape 4 ever was. Its developers
have been honest about its limitations, and for the most part these issues
are easily written around. Certain properties just aren’t implemented, and
box-type properties like margins, borders and padding aren’t properly
implemented for inline elements like
However, there are also problems that aren’t mentioned in the release
notes, and I’m concerned that these problems suggest deeper issues with
iCab’s CSS rendering engine.
For a start, there are problems with its
support for the box model.
The mistakes are
similar to those seen in IE5/Windows: widths aren’t calculated
consistently, and text sometimes juts out past the right edge of
backgrounds. Paragraphs and headings have excess vertical margins and
padding that you can’t get rid of even if you specify things like
margin:0px;. Worse, they are added onto
padding that you specify, instead of being replaced by them. While
backgrounds and margins on inline elements aren’t really supported, they
fail in different ways depending on whether the element is inside a table
or not. List items
seem to be treated as inline elements rather than block elements. Bold and
italic styles don’t always inherit properly either, at least if the
sidebar on MacEdition pages is any guide.
When asked to comment on the known issues, the iCab people responded:
Thanks for your feedback. We know about most problems, and they will be addressed in the next versions of iCab. The biggest problem is to combine all those workarounds for bad and invalid HTML code (which are neccessary to be able to display most web pages) and the box model of CSS. This is sometimes very difficult or even impossible so it will need some time to find a good solution.
This is the cost of the bad markup out there. Dealing with all that bad nesting and proprietary stuff slows down browser development. If you want a choice of browsers, start writing correct HTML.
Wishing and hoping and waiting
I’m mindful that these three browsers are all pre-release versions; even so, at nearly 15 percent of MacEdition’s pageviews combined, I have to care. I’m watching how they are going, and I’m quietly hopeful that they’ll all be right by final release. And if you are one of those 15 percent of our viewers, I hope that you are being noisy in pursuit of the same goal.