Over the weekend I read an article on digg about a way to speed up Safari by removing an initial page loading delay. It reminded me about an article Dave Hyatt – one of the developers of Safari - wrote about the FOUC problem last September. In this article he explains why browsers sometimes need to delay the rendering of the page because of the interaction between the loading of external css stylesheets and scripts accessing the not yet completely loaded DOM. Today Dave responds to the article on digg. The funniest thing I’ve read in a while.

Some of the initial reactions of the digg crowd:

wow..this really did work for me..i mean..the only useful otion (there is a handful of diff options) i used was turning off the delay to open pages. AND IT WORKED! my safari does seem a bit quicker..

Yep, page loading delay is absurd to say the least, that shoud be disabled by default.

Ya, this software saved Safari for me, I was using firefox for a while on my mac, but I found this little hack and started using Safari again simply becuase the pages load so damn fast now. It is definately a noticable difference.

Made a HUGE difference for me! Safari is usable now!

And the reaction of Dave Hyatt:

This just goes to prove how inaccurate people’s powers of perception are when it comes to measuring the performance of browsers. I say this because the preference in question is dead and does absolutely nothing in Safari 1.3 and Safari 2.0.

Never underestimate the power of the placebo effect :)

During my work on the CSS selector test for CSS3.info I discovered a number of bugs in the selector implementations of all popular browsers. So I filed a number of bug reports with additional information on how to fix these bugs. It's now five months later and time for a little update.

Konqueror

Konqueror only contained a single bug that resulted in 6 buggy selectors: attribute values should be treated case-sensitive in some cases and case-insensitive in other cases. I've worked together with the developers of Konqueror to come up with a definitive list of how each attribute should be treated. The solution was too late for the release of Konqueror 3.5.5, but it did make the next one. I want to congratulate the developers because this makes it the first browser to pass all of the tests and its developers can rightfully claim that Konqueror 3.5.6 fully supports all of the CSS selectors.

Firefox

Firefox suffered from a number of different bugs, including a variant of the same bug that plagued Konqueror. It did contain a list of how attributes should be treated, but it was simply not complete. I personally wrote a patch that updated the list to the same as Konqueror. The patch was accepted and has made it in Gran Paradiso, the test version of the next generation engine for Firefox 3.

Unfortunately this is the only bug that was fixed in its CSS selector support. Firefox still suffers from a number of other problems. It incorrectly considers text nodes as a child during the evaluation of :first-child, :last-child and :only-child. Additionally the rendered view is not updated every time a selector matches or does not match anymore. For example, during the building of the DOM, each element is at one time the last child of its parent – at least until the next child is processed. After the DOM is build, the :last-child selector should only match the then-current last child. And Firefox does this correctly, but it forgets to update the rendered view, so to the user (and also our CSS selector test) it still looks like every element matches the selector. When you force Firefox to re-render the page – for example by hovering over a link with a :hover selector - it will show you the correct rendered view.

Safari

Webkit – the engine on which Safari is build has made a number of changes to their CSS selector support. First of all, they now properly support the :lang() selector, and started work on some other CSS selector bugs. Unfortunately they decided to stop working on those bugs and temporarily drop support for these CSS 3 selectors.

Even though I'd rather see full support for all selectors, I do agree with their reasoning that it is better to drop support than ship a browser with buggy support. Mac OS X 10.5 and Safari 3 are coming this spring and shipping a stable browser is very important. So I was not surprised that the WebKit developers announced that they were temporarily changing their focus on stability instead of on new features. CSS 3 selector support seems to be a victim of this change in focus, but I have full confidence that they will continue working on this after the release of Safari 3.

The last couple of days have been busy for me. I've spend most of my weekend on tweaking and adding test cases for the CSS Selector compatibility tester. The test comprises of 513 different test cases for each of the 43 selectors. These selectors range from the simplest CSS 1 selectors to the latest CSS 3 selectors.

Before I reveal the results I must explain first that if a browser passes a test, it is not a guarantee that the browser is 100% compatible with the specification. There may be edge cases that are not covered by these test cases. I will continue to add more test cases in the future and I will also look into the ability to perform more dynamic tests. In a later version of the CSS Selector test it would also become possible to test if the browser correctly updates the selectors if the DOM is changed by Javascript.

Also I must note that even a single failed test case will result in a failure for a particular selector. This will skew the results a bit. For example: if you look the number of selectors that pass, Firefox may seem close to Konqueror, but in reality Firefox has not implemented 7 selectors at all, while Konqueror has implemented all, but fails 5 selectors because of a single bug.

The results

As you can see there is currently not a single browser that fully supports the tested CSS selectors. Only Konqueror comes close, it only fails the last 5 selectors because of a bug. It should be no surprise that Internet Explorer 6 performs the worst in this test. It even fails one of the most basic CSS 1 selector: the class selector.

Internet Explorer 7, Opera and Safari seem to contain a couple of bugs in their CSS selector implementations. All three could score a lot better if they would solve these bugs. Firefox is the only browser in which I could not detect any bug in their implementations.

An overview of the bugs in the various browsers

Internet Explorer 7

Opera 9

Konqueror 3.5.4

Safari

Want to test for yourself?

Well, you can head over to css3.info and test for yourself. Joost de Valk just opened up the test to the public.

I’ve been playing a bit with the new Safari for Windows and found a way to activate the debug menu that Mac OS X web developers were already used to.

You can enable the debug menu by editing the Preferences.plist file which you can find in the C:\Documents and Settings\Your Username\Application Data\Apple Computer\Safari directory. It’s just an XML file. Use your favorite text editor to open it.

Then add the following key at the bottom, just before the final </dict> and </plist> elements:

<key>IncludeDebugMenu</key>
<true/>

Then restart Safari and you're done!

I was going to write an article about the WebKit platform on Windows. About how the development of Swift has stalled and that the developer decided to move to the Mozilla Gecko engine while WebKit becomes more stable.... I was going to write about Apollo Adobe AIR and how you could use the build-in WebKit engine to easily build your own WebKit based browser in less than 30 lines of code. I was going to write about that Adobe already did the hard part and build a very basic browser called Scout...

I guess I can start all over. Steve Jobs just announced that Apple will bring Safari to the Windows platform. A public beta is available for download now.

The importance of a Windows browser based on WebKit – the rendering engine used by Safari - should be apparent for every web developer. If you wanted to make sure your site works on Safari and if you don’t own a Mac you had to rely on friends or one of those screenshot services. Alternatively you could use Swift or Scout for testing the basic functionality and rendering of the WebKit engine.

Testing for Safari has just become a whole lot easier and cheaper. You do not need to own a Mac any more to test how Safari renders your site. Nor do you have to work with some buggy or limited substitute. You can now test your sites in the real thing – Safari for Windows.

Some screenshots:

• Installer – Welcome
• Apple.com
• Searching with Google or Yahoo... hmm... still some text rendering problems
• Rakaz.nl
• RSS and Atom feeds... hmm no titles?
• Tabs, including dragging and dropping them from one window to another!
• Preferences – General
• Preferences – Appearance
• Preferences – Bookmarks
• Preferences – Tabs
• Preferences – RSS
• Preferences – Autofill
• Preferences – Security
• Preferences – Advanced
• Private browsing
• Embedded Youtube player... Flash apparently works...
• Crash... Oops