OmniWeb – are we there yet?

June 17, 2002

For those of you who are keeping count, OmniWeb 4.1 is now at Beta 7. It was released on May 24, just 18 days after Beta 6 hit the servers. There are also “sneaky peek” builds if you are really keen. Between OmniWeb, Mozilla and the new Chimera Navigator derivative of Mozilla, it’s getting hard to keep up. Just as well I bought a cable modem recently.

Despite the frenetic activity levels, I’m feeling unsatisfied. I want the final versions, but I also want them to wait until they’ve got it right. Maybe the final versions of OmniWeb and Chimera are just around the corner, but it’s equally likely that we will go through a number of “nearly there” releases.

For a standards-oriented Web author, the final release of Mozilla or Chimera will be of interest only if they attract significant market share, and thus make it worthwhile to push the standards envelope a little, for example by using CSS2 properties or DOM methods. Both browsers use the Gecko rendering engine, and thus both have arguably the best standards support out there, especially regarding CSS2.

OmniWeb is a different story. The final release of 4.1 will hopefully be a significant event for all Web authors with a substantial percentage of Mac users in their audience. I know a lot of people think that I dislike OmniWeb or that it makes me cry. This simply isn’t so. I’m glad to see that Mac OS X users have, if anything, more viable browser choices than their Windows or Linux counterparts. However, I’ve been bitten by OmniWeb’s standards-compliance gaps more than once, and I call bad design decisions and support shortcomings as I see them. I think that poor standards compliance in Mac browsers is bad news for support of Mac users by Web authors, and not just those using CSS extensively. If all Mac browsers supported standards, then it wouldn’t matter how narrow-minded Web authors were in their attitudes to non-Windows users. They could just support standards and it would work for Mac users without extra effort.

By contrast, OmniWeb’s standards compliance is still “not there yet”. While each build seems to fix a few things, I’ve noticed that new builds also introduce new bugs and strange decisions by the developers. Almost nobody else is tracking its CSS compliance, it seems, so it’s just as well that here at MacEdition, we’ve been compiling and updating the Guide to CSS Support in Mac-only Browsers for some months now. The guide is the only one out there that Web developers can refer to and have some sense of what things will work in OmniWeb.

This message is crucial: the few of you still using a 4.0x version of OmniWeb should rush out right now and download a recent 4.1 preview. Not only did the 4.1 betas greatly improve on the 4.0 releases, but versions after beta 2 are much, much better than the first beta. If you do that, and OmniGroup fix up the remaining bugs and support gaps, I’ll be much happier, and I promise to stop grumping so much about this browser. It also means that I can start classifying OmniWeb as “standards-compliant”, which I didn’t do in my last published analysis of browser usage in December.

So when is the final version going to be released? When will the rotten CSS and HTML4 support of Version 4.0x finally be banished from our server logs? I don’t know, but I do know there is still work to do. I would rather that they get it right than put out something half-assed and barely ready. Although its support of positioning and floats is getting much better, there are still plenty of real-life sites that are completely destroyed in OmniWeb, even beta 7 of version 4.1.

There are still too many really silly design choices and poor implementations in OmniWeb. Why, for instance, does padding-left, padding-top and so on work only if a background color has been defined on the element, but the shorthand padding property works regardless of the background? Why does OmniWeb allow negative padding even when the spec explicitly says that this isn’t permitted? Do the OmniWeb developers even read specs? The bugs in this browser aren’t even consistent emulations of the bugs in other browsers, and the padding problems are unique to OmniWeb. Float and some absolute positioning styles are broken, as is the box model. And that’s just the CSS problems – in a previous column, I mentioned the lack of support for id attributes as link targets. IFRAME is also not supported at present. And between beta 6 and sneaky peek 87, and they managed to foul up their table rendering code enough to make MacSlash.com unsightly; fortunately it was fixed in time for beta 7.

None of these thing are particularly obscure; I only list bugs in the MacEdition Guides if I can isolate them in simple test pages. My guess is that OmniWeb’s problems stem from a failure of the development team to read specs, and to understand how browsers should operate. Maybe it’s my number-crunching background, but I see the application of stylesheets in the same terms as language, or mathematics. You have a finite number of HTML elements, a finite number of CSS properties, each with a relatively limited number of possible values, but the space of possible combinations is much larger than any organization can reasonably test explicitly. It’s a combinatorial system, just like a language.

Let me elaborate on what I mean by that. Although there are only a few thousand words commonly used in English, people can still utter a sentence unlike one that’s ever been uttered before. And while languages can have lots of irregular verbs and other exceptions, computers are less forgiving of ambiguity than humans, and require fewer exceptions. You can’t just implement a property for some elements, or in limited contexts, because that’s the only place you’ve seen that style used in your surfing travels. Sooner or later someone is going to want to put a border on cite elements that are within paragraphs that are direct children of divs with class “interesting”, or whatever it might be, and everything will come asunder. It has to work like a combinatorial rule system, or the development engineers will be running around fixing bugs for the rest of their born days.

I worry for OmniGroup. It has a coterie of avid fans, but let’s be honest, a lot of that is due to the way it renders text, and that’s built into the OS, not a specific feature of OmniWeb. Chimera Navigator already offers the same text rendering technology, and you’d have to be mad to think that Microsoft wasn’t working on the exact same thing for IE, even if you hadn’t read the recent Naked Mole Rat Report on that very subject. Add to this the fact that OS X 10.1.5 now allows Carbon applications to use this Quartz text rendering technology, which that you can use right now with the freeware Silk add-in that enables Quartz for all Carbon applications, and OmniWeb is losing a key distinctive feature. How is OmniWeb going to hold its market share in the face of a range of browsers that offer as much, if not more, on the interface, and are more standards compliant to boot? If IE gets a text rendering engine as pretty as OmniWeb’s, will OmniWeb be able to attract existing Mac users as they switch from OS 9? Somehow I doubt it, not with the zero price tag applying to Chimera, IE or Mozilla.

— 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