This Cab needs training wheels

October 7, 2002

Don’t get me wrong; I couldn’t do without iCab. I use it extensively when I’m marking up MacEdition, as an instant and visual check for silly hand-coding errors. It’s faster than sticking every page through a validator, which is overkill in any case. I also appreciate its other nifty features, like the download manager. I wouldn’t use iCab for my regular surfing, but I wouldn’t dream of doing CTAN downloads with anything else.

So when I think of iCab’s quirky standards support, I’m disappointed at a level that feels deeply personal. It was the first (and still the only) browser to give an angry frown when it came across non-compliant HTML and a smile when you got it right. That’s no gimmick, it’s a sign of a browser that was serious about standards.

iCab was one of the first browsers to actually do something with the frequently implemented but largely ignored META elements in Web documents’ head sections. iCab has amongst the best support for HTML 4.0 specific elements out there. It was the first browser I know of to treat the ABBR and ACRONYM elements seriously, and in this respect it continues to shine relative to just about every other browser. I’m even willing to bet that Mozilla’s default dotted underline on these elements is modeled on iCab’s example. Certainly, I used the iCab and Mozilla formatting as the inspiration for the class I’ve defined in MacEdition’s own stylesheet to indicate when we’ve spelt out acronyms in the title attribute, to be viewed as a tooltip in modern browsers.

But, oh, the CSS and DOM support. What is up with that? To be fair, iCab’s publishers have been upfront about what is supported and what is not, and the DHTML/DOM support is not too bad now, as described by Peter-Paul Koch’s useful site. Whenever I submit a bug report, I get a reply, and it’s usually that they know about the bug. On both counts this is more than I can say for OmniGroup. For a small company, iCab has done well, and hasn’t underestimated just how difficult it can be to implement robust standards support. Compare this with the attitude of OmniGroup, who originally thought that they would have full CSS support ready to drop into beta 5 of version 4.0, back in January 2001. When this turned out to be too difficult, they started promising better standards support for version 4.1. Now, eighteen months later, it’s version 5.0 that’s going to be super-duper wonderful, when it comes out. At least the makers of iCab didn’t underestimate the task and promise more than they could reasonably deliver.

What saddens me about iCab is that, after a promising first stab in Preview version 2.5, so little has been done on the CSS front. Since then, each time a new version has come out, I have dutifully downloaded it and gone through the rigmarole of testing it in all the relevant suites. And each time, I’ve found very little difference. Version 2.8 did fix a strange rendering bug that affected a both MacEdition and Jeffrey Zeldman’s site, whereby squares of text – even portions of individual letters – would disappear from view. I never did work out what caused that problem, but it is no longer a problem, because older versions of iCab expire. The latest release, version 2.8.2, fixes some strange problems on Mac OS X 10.2 (Jaguar), but again, doesn’t seem to touch the basic rendering.

There’s a lot that iCab gets right on the CSS front. For example, it implements background-position correctly, so although floats and positioning don’t work, the basic concept behind Eric Meyer’s renowned Complex Spiral design works just fine. Still, many problems with iCab’s CSS support remain – problems I’d like to see fixed before I start calling this a browser with good standards support. These include the incomplete implementation of CSS1 standards like float and clear – on which many CSS-oriented layouts are based. There are some incorrect implementations of things like margins on block elements, for example. I am so sick of seeing the MacEdition layout with all that extra whitespace between text in the sidebar, but on the other hand I recognize that the world won’t end because of a bit of extra whitespace. There are also some odd bugs, like the way redundant font selectors (the kind we’re used to putting in to be nice to Netscape 4) mess up backgrounds of elements with a short amount of text, such as headings. Other font glitches include a strange treatment of Lucida Sans on OS X that was affecting MacEdition’s own layout, at least on my system; this could be a Mac OS X problem, but as yet the problem doesn’t have a complete diagnosis. (Fortunately, the fix is very simple.)

In addition to iCab’s problems with CSS, I’m hearing reports from MacEdition staff that it sometimes eats the contents of forms on Web pages. Obviously, it’s not the sort of browser to use if you are the kind of person that contributes to one of the many discussion boards or other communities on the Web.

Given all this, one could be tempted to write off iCab, to say, “Mac users have a choice of IE, three Mozilla-based browsers, OmniWeb and Opera (of which more in a future column) – who cares what browser #7 is like?”.This is perhaps too harsh; I think iCab is an important alternative browser that fills niches none of the other are yet trying for. Its small resource requirements make it one of the few browsers that could support standards properly and persuade users of older machines to upgrade from Netscape 3 or 4. The kiosk functionality is also useful for important niches within the population of Web users, including libraries and other public spaces.

Many Web authors will find that iCab isn’t a big part of their audience, and will probably rationalize to themselves that pixel-perfect layouts aren’t essential in what is likely to be very much a minority browser on most sites. Mac-oriented Web sites will probably have to pay a bit more attention to iCab’s foibles. Fortunately iCab doesn’t actually destroy content or crash when it encounters CSS that it can’t handle. This is an improvement on certain other browsers, old and new.

The current state of iCab is such that it doesn’t fully support basic Web standards such as XML, CSS1 and DOM1, although against that, its HTML4 support is very good. I hardly think that this is going to hold back the necessary adoption of these standards by Web authors; IE for Windows, Netscape 4 and author ignorance and laziness are much more responsible. That said, one important reason browser developers ought to implement good standards support in their products is that Web authors shouldn’t have to immerse themselves in the bugs and glitches of 57 different browser varieties. Nor should Web authors have to hire some high-paid professional who has immersed themselves thus, just to do standard publishing tasks. Web authors should be able to have confidence that if they author to standards, their content will work in a wide range of browsers, including ones they have never heard of.

iCab’s authors need help and support to get it right. At MacEdition, we’ve tried hard to find bugs and report them in a constructive way, and we’ve been maintaining a guide to iCab and OmniWeb’s CSS support for the best part of this year. I encourage like-minded Web authors to do the same – find the bugs, isolate them, and report them. If we’re going to have seven widely used browsers on this platform, they had better all be good.

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

E-mail this story to a friend