[Big Mac]

Color me highly impressed. OmniWeb 5 is this close to getting me to switch to it. I never thought it would correctly render a particularly troublesome page because Safari chokes on it. I thought that since they both use WebCore they would have the same incompatibilities. How wrong I was. OmniWeb also loaded a complex credit card page much more efficiently (in processor utilization) and about as quickly as Safari and Firefox. On the gloomy side I did see some Flash issues, but I have yet to do more than cursory test with it. If OmniWeb continues to impress me like this, I may well switch.

[Tyler McAdams]

I've bought omniweb a long time ago... it's a great browser.

What was the website?

[Big Mac]

It is an internal administration page for a web host that I have been with for years but must now abandon because of their utter idiocy. Long story. Btw, forgot to mention that I purchased OmniWeb at MWSF 2003 partly out of sympathy for OmniGroup after the announcement of Safari. I always liked OmniGroup - the company is a class act - but got little use out of OmniWeb. Now I have to seriously reconsider my choice of browsers.

[Big Mac]

I don't seem to be experiencing the problem with Flash I reported earlier, and I am also delighted to know that OmniWeb's resize redraw actually performs well. I think I may well be switching. Kudos, OmniGroup!

[cpac]

Originally posted by Big Mac:
I don't seem to be experiencing the problem with Flash I reported earlier, and I am also delighted to know that OmniWeb's resize redraw actually performs well. I think I may well be switching. Kudos, OmniGroup!

Just wait 'til you get used to workspaces, shortcuts, and per-site preferences...

Welcome to OW!

[Big Mac]

Thank you, cpac. I think OmniWeb truly is ready for prime time. Unfortunately, it doesn't run that well on my iBook with its 466MHz G3 and 12" screen, and if I switch on my G5 I won't get to maintain bookmark compatibility.

Here's another Good Thing about OmniWeb: it is the least vulnerable of the Mac browsers I have installed to the international character URL spoof that was reported recently.

[cpac]

Originally posted by Big Mac:
if I switch on my G5 I won't get to maintain bookmark compatibility.

If you sync your Safari bookmarks between the two, you can maintain bookmark compatibility.

OW reads (not imports, reads) Safari bookmarks - so you could just use Safari on the iBook, sync those with Safari on the G5, but use OW on the G5.

[Big Mac]

It does? GREAT! I thought I had to import them and go with a proprietary OW file format. I do choose Import Bookmarks though, right? It seems like if it is only reading Safari's file that option should be named differently. Thank you for the info, cpac.

[cpac]

Originally posted by Big Mac:
It does? GREAT! I thought I had to import them and go with a proprietary OW file format. I do choose Import Bookmarks though, right? It seems like if it is only reading Safari's file that option should be named differently. Thank you for the info, cpac.

I may have over-spoken.

When you "import" Safari bookmarks, they show up as a "collection" in the left hand side of OW's bookmark window (just like favorites or shared bookmarks, etc.).

You can view them easily that way, and any changes you make in Safari will show up when you next launch OW

The only thing that doesn't work (at least as far as I can tell) is modifying Safari's bookmarks using OW.

makes sense?

[Big Mac]

Sounds good to me. I continue to be impressed by OmniWeb. I'll purchase that upgrade key now.

[Tyler McAdams]

Things that interest me are:

What is the rendering engine?

Have there been any security holes?

I would gladly pay for a browser that has good programmers patching holes left and right. After all no browser is w/o holes.

[electric monk]

Rendering Engines
Safari and Omniweb use a varient of KHTML known as WebCore.
Konqueror uses KHTML (but can switch to Gecko).
Opera for WIndows and Mac uses Presto.
Mozilla/Firefox/Camino use Gecko as does Netscape which should have the ability to switch to Trident in the future.
IE 6 for Windows uses Trident.
IE 5 for Mac uses Tasman.

Those are the main rendering engines.
Quickly:
Trident sucks. Limited support for modern web standards but many sites are designed to only operate on it.
Tasman isn't bad, but is outdated.
Gecko is probably the best at loading pages (excluding Trident) but has a fairly large footprint.
KHTML/WebCore is lean and fast, but cannot load as many pages as Gecko although they generally differ on which pages they choke on.
Presto is actually pretty good.

The odd fact that Internet Explorer uses different rendering engines on different platforms explains the fact that IE 6 chokes on PNG images while IE 5 (Mac) handles them well.


Don't know about security holes but emailing the OmniGroup should get you an answer in a few days. They seem like pretty good guys from when I've talked to them.


These articles probably answers any other questions you may have;
http://daringfireball.net/2004/08/omniweb_5
http://daringfireball.net/2004/02/omniweb_5_public_beta

Please note that Omniweb is currently at v5.1 which uses the same version of WebCore that Safari does.

[workerbee]

Originally posted by Big Mac:
I don't seem to be experiencing the problem with Flash I reported earlier

As much as I love OW 5.1, Flash support is a weak point IMHO. On pages that work without a problem on Safari, in OW Flash forms sometimes don't show the text cursor, buttons show up only after a reload (http://www.elsner-flake.com/welcome.html) or not at all (navigation bar on http://www.camper.com/web/en/home.asp).

The one other thing that bugs me is OWs startup time and the time OW takes to show a menu after a restart. I know it does a lot more than Safari, but the difference in nimbleness still seems a bit excessive to me.

Apart from that, I only ever open other browsers to check for rendering.

[Rickster]

This hasn't been explained here in awhile, and Omni doesn't seem to talk to the public much anymore, so I guess I'll have a go at it:

WebCore encapsulates KHTML and is responsible mostly for interpreting HTML/CSS and determining how, on a general scale, it should be presented onscreen. It also does a large part of coordinating resource tasks (e.g. making sure images, style sheets).
And, in conjunction with JavaScriptCore (which is built around KJS and PCRE), it manages the DOM and works as the "brains" behind most types of webpage interactivity.

WebCore doesn't do networking -- other software components handle feeding it data to be interpreted or downloading resources it says need to be displayed. (And thus, those components are also responsible for dealing with such issues as caching recently-used data, HTTP protocol support, and using proxy servers when appropriate.)

WebCore also doesn't do much rendering to the screen itself. Remember when newspapers and the like were laid out by putting together separately printed articles, columns, and pictures on a big pasteboard to make a master plate? It's sort of like that -- WebCore expects other software components to turn text data into visible typography within the layout it specifies, to decode image files and composite them into the view, and to manage the complicated view-embedding and event management issues required to support media plugins like QuickTime, Flash, and Java.

In Safari, a high-level framework called WebKit handles all the frontend tasks (text rendering, media management) and coordinates the use of basic Cocoa classes to handle the backend stuff (the NSURL family of Foundation classes for networking, NSImage for decoding and displaying images, etc.). WebKit also allows other software developers to embed a complete "web browser view" in their applications -- it's used in this capacity by mail clients, RSS readers, the Help Viewer, and even Keynote.

WebKit is not open source; while it provides several APIs to customize its behavior, one can only customize it it ways the designers of said APIs foresaw and allowed for. The complete source code for WebCore is available from http://developer.apple.com.

So, OmniWeb 4.5 and newer use a customized version of the open-source WebCore code in conjunction with their own frontend and backend software. The networking backend is the same massively multithreaded architecture used in previous versions of OmniWeb, and other components (including those for image decode/display) build on this architecture. (This is why OmniWeb sometimes outperforms Safari on dual-processor machines.) Plugin and Java support also mostly uses the same architecture as previous versions. For text rendering and other frontend tasks, Omni had to build new components.

In replacing WebKit's frontend roles, Omni had to use the same APIs and tools available to all third-party developers. This is why there are some other discrepancies between Safari and OmniWeb: WebKit uses a number of "private" (that is, safely usable only by Apple) APIs for text rendering and other tasks, so Omni often had to sacrifice flexibility for speed or speed for compatibility in ways Safari does not. Omni also found a few bugs not exposed by WebKit's use of WebCore. (And fixed them, and shared the source. Incorporating those fixes into official WebCore releases is up to Apple and the KHTML maintainers.)

In short, OmniWeb and Safari (or other WebKit-based apps) share only a part of their "web browsing engine". Since they have divergent codebases in other parts, differences in web compatibility (in both directions) can occasionally show up.

[Big Mac]

Thank you for the informative reply, Rickster. Can anyone tell me, is there any way to import the rest of Safari's bookmark collections into OmniWeb? As far as I can see, the import function only imports the contents of Safari's bookmarks menu. Due to Safari's lag in drawing its Bookmarks menu when it is loaded down with a lot of bookmarks, I have gotten into the habit of storing only a fraction of them in the menu.

[Tyler McAdams]

I sounds like Omniweb is at the forefront of development on the Mac. As far as smp is concerned, at least. I still wish there was a mac browser that would take into consideration CSS elements such as custom scrollbar colors and whatnot.

[Millennium]

Originally posted by Tyler McAdams:
I sounds like Omniweb is at the forefront of development on the Mac. As far as smp is concerned, at least. I still wish ther was a mac browser that would take into consideration CSS elements such as custom scrollbar colors and whatnot.

Custom scrollbar colors are nonstandard. KHTML -the engine on which WebCore is based- supports them anyway, but it is unlikely that this support will be ported to OSX, because there would be no way to use them with the native widgets that cause more than a few people to prefer it over Gecko. Frankly I don't think that's a good reason to prefer one engine over another, but enough people do that I doubt Apple will take that route.