Well, I've been using Safari Windows for a few weeks now, and I though it's time for a report. This report is only about the Windows version, because I can't install the Mac one. Why not? Because I don't have the right OS X version.
I wish Apple would stop tying Safari Mac releases to new OS upgrades; it makes running the latest and greatest Safari version too expensive. Currently I'm using 1.3.2 on my Mac; and I've decided to wait for Leopard before upgrading my Mac, which means this site won't feature bug reports for Safari 2 or 3 Mac in the near future.
More in general, I wish the Apple fanboys would admit that Apple is doing exactly the same thing Microsoft used to do back in the nineties and early 2000's and was rightly flamed for. This whole tying business is a nasty stain on Apple's browser policy.
In any case, the lack of Safari 2 and 3Mac reports on this site is Apple's fault; not mine.
Nonetheless, the release of Safari Windows is supposed to help people like me. People who don't own a Mac (or an iPhone) should be able to test their web pages in Safari, and therefore Apple released Safari for Windows. That's pretty simple, isn't it?
Unfortunately it isn't. As a browser tester of long standing I feel obliged to point out the obvious: in a little while we'll have three Safari versions that we have to test our pages in: Windows, Mac, and iPhone. That doesn't make things simpler, it complicates it quite a bit.
Now I do not doubt for an instant that Apple is going to go through major trouble to make sure that the three Safari versions are as similar as possible. Unfortunately, similar does not mean the same, because in the end programmers are humans, too, and humans make mistakes.
No doubt in a year or so we'll find discrepancies in some areas. If we're fortunate these discrepancies are truly minor and can be safely ignored, but with even a little less luck we'll have a few incompatibilities that require people to test their sites in Safari Windows, Safari Mac and Safari iPhone.
I will follow Safari's (lack of) discrepancies with interest.
In any case it is moving forward. I already gave a list of newly supported CSS; and on the DOM side of Apple is making progress, too. I haven't yet run official tests, but I did note that
cellIndex are finally supported properly. (The last one is especially important.)
According to Steve Jobs Safari is the fastest browser on Windows. Now he isn't very clear on the exact definition of "fastest", and as Apple CEO he'll have a rather hard time avoiding charges of prejudice in any case.
During @media 2007 Europe it was very fashionable to complain about Safari's lack of speed (to be fair: we were talking about 2, not 3). The consensus seemed to be that Safari may be pretty quick in loading web pages, but it can be agonizingly slow in closing down web pages, especially those that have plugin content. Jobs didn't mention these problems in his keynote.
Then I went through my DOM vs. innerHTML and style vs. className benchmarks in Safari Windows, and the test results are pretty awesome. So awesome, in fact, that I started to suspect there's something wrong.
Fortunately, for once I didn't have to do the dirty work myself. Mark "Tarquin" Wilton-Jones did some extensive testing and found the cause:
Safari does not update the date objects correctly. It appears to pause the date object while iframe src changing, page loading, and parsing is taking place, so the next request for a date object produces one with the same time as the one in the parent page. Even when forcing it not to cache the page, this still happens (and yes, I tested many times since I did not believe it myself). The page load itself could be seen to take about half of a second when timed with a stopwatch. Clearly, Safari has a bug with date objects here.
(And yes, this is the actual sequence of events: first I started to doubt Safari's reported benchmark results, and only a few hours later I read Mark's article.)
It gets worse, though. During his keynote, Jobs showed IE7 and Safari Windows running side by side, and noted the speed with which the browsers downloaded and displayed a few key test pages. Guess whih browser was fastest? Hint: it wasn't the one from the giant Apple competitor.
Obviously, any such speed test must use the load event: show load time when the page has been loaded completely. Unfortunately the load event in Safari is different from the same event in other browsers. Mark explains:
Safari does not fire onload at the same time as other browsers. With most browsers, they will wait until the page is loaded, all images and stylesheets and scripts have run, and the page has been displayed before they fire onload. Safari does not.
In Safari, it seems onload fires before the page has been displayed, before layout has been calculated, before any costly reflows have taken place. It fires before images have completed decoding (this can also happen in rare cases in Opera, but Safari seems to do it everywhere), meaning that a substantial part of the load time is not included. So basically, onload is not trustworthy in Safari for checking page loading times.
So Jobs' speed testing is unreliable. It compares Safari's load event to IE's, and the two are different. From a propaganda point of view Jobs said and showed the right thing, but from a technical point of view it's completely worthless.
The "fastest browser on any platform" claim is based on faulty implementations of the Date object and the load event, and is therefore untrustworthy.
Until these problems are solved we cannot really compare Safari's speed to other browsers' speed; and we must perforce conclude that Apple's test results are (let's keep this nice) too flattering.
(Kudos to Mark for testing this stuff. If the world had had to wait for me, these facts wouldn't have been uncovered for at least another year.)
Finally I'd like to note two relatively minor, but still annoying, problems with the Windows version.
No doubt these two problems will be fixed eventually.
If you like this blog, why not donate a little bit of money to help me pay my bills?
Comments are closed.