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
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:
- Opacity
- Text-shadow
- Image gamma correction
- Canvas
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:
- It cannot display framesets or iframes, you simply get a blank page or blank gap (or it may just crash).
- It cannot open popups.
- Fails acid 2, meaning it is Safari 1.3 equivalent, and not representative of current Safari releases.
- XMLHttpRequest does not work, so it cannot import XML (AJAX).
- All mouse clicks are read as being a left mouse button, even if you use middle or right.
- Mouse buttons are incorrectly reported to scripts (button 17527, instead of 0 or 1).
- It crashes when parsing dates.
- It crashes when setting window.status.
- It sometimes crashes when using CSS generated content.
- It has broken path handling after redirection from paths without trailing forward slashes.
- designMode rich text editing does not work.
- It cannot scroll to internal anchors.
- Several input types do not work, including password, select, and file.
- Button elements are not displayed correctly, and textareas cannot scroll (and their contents may disappear).
- JavaScript prompt dialogs do not work.
- Selecting text can make it disappear.
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.
- It has no preferences at all (several menu items do not work).
- It has no memory for toolbar or window setups - whenever you restart it reverts to its default state.
- It cannot load pages from the local computer.
- It doesn't remember scrolling position when going back.
- It cannot scroll if it does not have a scrollbar, so it is extremely difficult to see the result of the Acid 2 test.
- Scrollbars blink when the cursor blinks in a text input.
- There is no history of visited Web pages, so they must be typed by hand every time.
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.