Using the Safari engine on Windows


Skip navigation.

Site search

Site navigation

Article obsolete

Safari has now been released for Windows, and it has addressed all of the issues mentioned in this article. It uses ported parts of the Mac system to produce the same response to CSS and effects like font smoothing, and as a result is a very accurate representation of Safari on Mac. (Note that image gamma correction will still be different though.) Use Safari. Do not use Swift.


Swift is currently in Alpha release, and it would be premature to start using it now. However, it is the first KHTML/WebKit based browser available for normal users (not including use of Cygwin for KHTML, or Nokia emulators for the Series 60 WebKit browser), and several people were jumping at the chance to see how Safari (or perhaps Konqueror) would render their pages.

Not that I wish to trample on your excitement, but I must advise against using Swift for any testing at all, for the moment at least.

A browser is made from two distinctive parts; the rendering engine, and the chrome. The rendering engine is the part that displays the Web page. The chrome provides the UI toolbars, the back and forward control, the address bar, the preferences, the window management, etc. In the case of Swift, the rendering engine is ported to Windows as part of the WebKit project, and is not yet ready for alpha status. The very limited and problematic chrome is the part called Swift, and is in alpha status. It is not related to the WebKit project, and is produced entirely separately.

Is it like Safari?

There are some serious limitations that make it impossible to use Swift to see how Safari would render a page:

It cannot use Mac fonts or Mac font handling. It has to use Windows fonts. This may not seem like much but it makes a big difference. The font smoothing is different, but more importantly, sizes are different. You may use relative font units, such as 'em', but different fonts break the bounds of the em square in different ways, so precision em widths will be different. Anything that relies on them cannot be trusted.

Safari also uses the operating system for many other things. These include things like:

Currently, none of these work in Swift. And even if they begin to work, they will never work the same way, since they cannot hook into the Mac operating system, because it is not there. They will have to be rewritten separately, and will have their own bugs, and their own behaviours.

It is even further from Konqueror, since Safari began as a port of Konqueror, but they now follow separate development paths.

What limitations does it have with Web pages

Although the porting achievement is impressive, it is by no means complete. As well as the points listed above, it has the following limitations with Web pages, that the real Safari does not have:

As you can see, this means that most pages will suffer from at least one major problem. It simply cannot be used for testing how a page will look in Safari or other WebKit/KHTML browsers. (It also cannot be used as a browser either, since it cannot render a large part of the Web.)

I should also add that I hardly tested Swift for any time at all. These are what I found within about an hour of testing. Obviously there are many, many more problems that are just waiting to screw up your impressions of how Safari would work on your page. Do not use Swift. Use Safari, OmniWeb, or Shiira on a Mac (or slowly in PearPC) if you want to test those browsers. Use Konqueror on Linux/UNIX possibly in VMWare or on liveCD (or if you must, on Windows via Cygwin - although that will suffer from some of the same platform limitations as Swift) if you want to test that.

Do not test Swift and think it is representative in any way of those browsers.

What is wrong with the chrome

The chrome obviously still needs a lot of work, but it is currently so non-functional, it makes testing uncomfortably annoying. The chrome is about as basic as it could be. Just enough to display a page, but hardly even enough to test that.

Speed tests

In case you were wondering if I was going to add details of Swift into my browser speed comparisons, the answer for now is "no". It feels about the same as Safari 2 in terms of speed, but it is not capable of running several of the tests due to crashes, and inability to display framed or popup pages. The engine is incomplete (compared with its Mac counterpart), and not ready for testing yet.

In addition, it currently has absolutely no features, and most of the UI does not work. It is hardly surprising if that makes it faster, because it doesn't have to do anything or remember anything, or even work correctly. But that means that once it becomes a proper browser, it will almost certainly be slower.

Add to that the fact that right now it relies on me having to install that giant bloatware .NET 2 (just to use a simple UI; that is ridiculous) which would affect performance, and I try to keep the OS performance as static as possible to keep the tests fair. I assume I will have to add this at some point, but I will probably install it, test, then uninstall it. (Before any of you email me, I am aware of the other ways to run it without using .NET, but for now I will not use any of them either.)

It would be unfair to Swift, and to the other browsers, to test it right now in this clearly unfinished state. It would not be even remotely representative of how its performance will be when it is finished (and hopefully by then there will be a proper chrome for Windows WebKit instead of this Swift .NET nonsense, so it can become a browser in its own right, and not just a testbed). So I will not test it.

This site was created by Mark "Tarquin" Wilton-Jones.
Don't click this link unless you want to be banned from our site.