The promise of Omni-potence
April 21, 2003
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
When Safari was first announced, we saw an interesting parallel announcement from the Omni Group. Safari’s rendering engine is the same KHTML component that drives Konqueror, the browser in the KDE Linux environment. It had good standards support to begin with, and Apple has added a bunch of improvements and fixes which it has given back to the project for use in other packages. More than that, Apple has bundled the KHTML rendering engine into a framework, WebCore, that other OS X developers can use.
The Omni Group indicated at the time that it was looking into replacing OmniWeb’s own highly broken rendering engine with WebCore. As far as we knew, it was still just considering it. But then ten days ago, it announced that it already has an alpha release – a “sneaky peek” in Omni’s nomenclature – using the WebCore component.
From open source to outsource
Before I get on to the results of my testing, let me state that I think this is an unambiguously good thing. As I discussed recently, implementing Web standards fully and correctly is hard, and it helps to have a standards maven on staff. All the browser makers that have succeeded in implementing standards reasonably well have such experts on their teams, helping develop the next generation of standards at the same time as ensuring their products conform to the current generation. The Omni Group doesn’t have such a person, and given the size of the company, it’s not likely that it was ever going to get one.
So if you can’t do it in-house, outsource. The WebCore component promises good standards support, and consistency with Safari would mean one less browser to test. The KHTML and Safari teams have created a good base to work from and they understand the standards.
Slips ’tween cup and lip
The first thing to note is that the WebCore component incorporates a build of KHTML in between the one in Beta 1 of Safari (v60) and the one in Beta 2, released just a few days after the first few sneaky peeks of OmniWeb. So OmniWeb includes a lot of the fixes for Safari Beta 1 bugs that have also been included as fixes in Beta 2 – in fact all of them, as far as I can tell. Most notable amongst these is the fix for dotted and dashed borders, which are drawn slightly off-center in Safari v60 (a good example of the problem can be seen on MacEdition’s Guide to CSS Support for Tables) and are subject to some other rendering errors.
On the other hand, there are some differences between the two browsers that
might reflect the way the rendering engine has been integrated with the
rest of the browser. Text layout and font selection are rather different,
with some glitches in
the presentation of boundaries between
and ordinary text. This apparently has something to do with sub-pixel
text glyph rendering, which doesn’t currently play nice with WebCore.
The preview of OmniWeb 4.5 I used in testing last week (sp4) also
doesn’t deal with alternative font families – if you
don’t have the first-named font installed, OmniWeb reverts to the
generic family, which for sans serif text is usually Arial or something
like it. Fortunately, this was fixed in “sneaky peek” 5, and so
by the time you read this, current builds will no longer have the problem.
In addition to the CSS-related fixes related to adoption of WebCore, it
also provides a number of non-CSS fixes – like the addition of
id attributes as targets – that were sorely
needed and greatly welcomed. You can see the differences in the recently
Guide to CSS2 Support in Mac-only Browsers.
In addition, the following non-CSS bugs are fixed:
- Default rendering of the
- White space in dynamically inserted table cell bug
Finally, OmniWeb 4.5 is not subject to the following hacks:
You decide, we’ll report
It was not so long ago that, for a brief time, OmniWeb was the most popular browser amongst OS X users reading MacEdition. People are clearly looking for alternatives to IE, but through 2001 and 2002, OmniWeb’s market share was gobbled up, first by IE, then Chimera/Camino and finally Safari, until by early this year, OmniWeb represented just a tiny rump of die-hards in MacEdition’s logs. Throughout the decline in OmniWeb’s share, there were arguments about the attraction of OmniWeb, what people saw in it, and what people were trading off in OmniWeb to get the speed and standards support of Camino or Safari. Originally, some thought OmniWeb’s attraction was just the pretty anti-aliased Cocoa text – and it’s true that much of the decline occurred after Silk and OS X 10.1.5 allowed Carbon applications like IE to display text that looked almost as nice (but not quite!). Meanwhile, others disagreed, pointing to the interface features OmniWeb also offers. Whatever the perceived reason for using OmniWeb, it seems that many people were willing to forgo it to get speed and standards compliance.
With Version 4.5, they won’t have to make that tradeoff. By using WebCore, the Omni Group can now provide the same speed and standards compliance as Safari. Here’s the test of whether it was the interface or the pretty text that people liked about OmniWeb all along. I’m not expecting OmniWeb to be Number One ever again – the pull of an Apple-branded browser is too great to think it could happen. Indeed, it’s hard to see it doing any better than fourth, after Camino and Internet Explorer – fifth place if Mozilla or Netscape retain their own audiences, on top of their Gecko-powered sibling Camino. But if the interface features of OmniWeb count for something, I’ll be expecting to see a sustained shift upwards in the usage of OmniWeb in our logs beyond the final release of Version 4.5.
All in all, this is a very good outcome, and much earlier than I expected. It’s one less browser to make me grumpy, and one more that I’d be happy for you to use.