OmniWeb – are we there yet?
June 17, 2002
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
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.
The sites OmniWeb rejects
- W3Future is obscured in OmniWeb (how ironic)
- Some of the ticket-buying links on DigitalHit are obscured
- Many multicolumn CSS layouts are broken in OmniWeb. I can’t read Slovakian, but if I could, I still would have problems reading AcidLog in OmniWeb.
- Misimplementation of
widthgloops glish’s right-hand column
- Oh, there’s bound to be more... post your favorites in the Feedback Farm below
There are still too many really silly design choices and poor
implementations in OmniWeb. Why, for instance, does
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
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.