QUOTE (Eärendil @ Sep 18 2008, 17:38)

It scores well on the Acid3 compliancy test - round about the high 70s mark. IE6 gets, well, 6, lol. IE7 isn't much better. FF gets low 70s.
I think development builds of Safari, Opera and Air have all achieved 100s in the last few months.
Chrome is just the webkit, so it should (should) render the same Acid test as Safari.
There are several interesting things I've learnt about Chrome.
One of them is the timeouts/intervals in JS. For anyone who doesn't know these are used to handle one off or repetitive tasks that can be called asynchronously (although JS being a single thread language, it doesn't run asynchronously). The format of the command is ..
setInterval( func, time ); or setInterval( func, time );
.. the time parameter is based on milliseconds, but with JS any timing is dependent on the machine it's running on. This tends to leave browsers putting a lower cap level on it, so you find that setting the time to 1-15 has no real difference (not that you would notice it as it's 100th of a second). Chrome however runs it's JS in a virtual machine allowing it to control the timing better. In fact the coders have even said they intend to set it correctly regardless of the actual machine it's running on.
None of that sounds particularly bad until you realise how often setInterval/Timeout are used as a hacky solution to a problem. In fact I've used it to deal with preloading scripts using JS because IE's onload even is buggered on the <script> tag. You will find a lot of sites that will fail in Chrome because they've used a js technique they didn't understand.
Chrome also doesn't respect mime types either I notice. Justin.tv had a problem with serving SWF (flash) objects, returning them direct without a proper mime type. No browser could view the file (IE, FF, Op) and would simply try and download the file. Chrome, however, played it meaning it doesn't actually check the mime type before parsing the file.