CodeBitch : click here to go to MacEdition Homepage
 

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 promised 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 list:

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: backgrounds on heading or 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 CSS font-size keyword “small,” not “medium” (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 features, e.g. 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 some 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.

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 CSS, 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 SPAN or CODE.

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 margins and 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.

Got feedback? Give it to them!

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.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other columns by CodeBitch.

E-mail this story to a friend