Google's browser: Google Chrome

Wanderer

Played with in under Vista, my MobileMe pages are not compatible!

I'll give it a few more months I think.

Posted: Monday, 8 September 2008 at 6:23PM

Max_B

@Dinoboff Yes i think updating webkit will help.
Tried webkit nightly on Win today and run into problem too. So I downloaded the Safari4 preview from developer connection (registering needed).
It's less ahead on webkit release but more than Safari3. I gets 100/100 on Acid 3.

I know most of window based devs don't care about Safari/webkit, but it has the best engine whatsoever, and web inspector match firebug natively.
Edit: Chrome gets a previous version of the inspector as for now.

Edit: Me too think that Chrome will get success on Windows because it already has a better overall performance than FF and as soon as they upgrade to recent webkit, it'll rock.

Dinoboff

Isn't Acid3 about JavaScript? Since Google Chrome has its own JavaScript engine (V8) it may not help that much.

Max_B

Well, you may be right. I'm not sure how webkit and V8 interact. I didn't digg into the docs of chrome.

Dinoboff

I am not sure either.

NickE

from the web standards project:

Acid3 is primarily testing specifications for “Web 2.0″ dynamic Web applications. Also there are some visual rendering tests, including webfonts. Here is the list of specifications tested:

• DOM2 Core
• DOM2 Events
• DOM2 HTML
• DOM2 Range
• DOM2 Style (getComputedStyle, …)
• DOM2 Traversal (NodeIterator, TreeWalker)
• DOM2 Views (defaultView)
• ECMAScript
• HTML4 (<object>, <iframe>, …)
• HTTP (Content-Type, 404, …)
• Media Queries
• Selectors :lang, :nth-child(), combinators, dynamic changes, …)
• XHTML 1.0
• CSS2 (@font-face)
• CSS2.1 (’inline-block’, ‘pre-wrap’, parsing…)
• CSS3 Color (rgba(), hsla(), …)
• CSS3 UI (’cursor’)
• data: URIs
• SVG (SVG Animation, SVG Fonts, …)

I would think the dom/(x)html/css/data related aspects are covered by webkit

Max_B

After all, I looked around. There are some infos floating:

http://www.osnews.com/comments/20260
http://waynepan.com/2008/09/02/v8-tracemonkey-squirrelfish-ie8-benchmarks/
http://ejohn.org/blog/javascript-performance-rundown/

I bet that while engines are different (squirrelfish vs. V8), both are accessing the same DOM data so my guess is that it will improve with recent webkit. Acid 3 is not only a speed test but a rendering test, computing and checking rendered dom elements

Edit: Sirnot posted before me and his post is the exact complement to mine

Stash

http://ejohn.org/blog/javascript-performance-rundown/ is very interesting reading indeed. Competition is great

squirrel

Let's not get too hung up on ACID3. Browser projects are starting to tout their ACID3 scores the same way GPU makers brag about their frames per second in tech demos. At best it's an interesting synthetic benchmark, at worst it can be actively gamed. The fact that Webkit and Gecko are both open source helps keep them honest but there's still a danger of prioritizing bugs based on how many ACID3 points they're worth. That's the wrong way to manage a browser project. The ACID test approach is brilliant in its simplicity, but it doesn't come close to covering the full spectrum of HTML compliance (or ECMA, or DOM, or CSS, etc). It was never intended for that. ACID3 compliance is great but only if it doesn't distract from developing a product that is also secure and efficient. Again, don't get me wrong, I like ACID3. It's just not a goal unto itself.

Max_B

@squirrel:
Agreed, totally. This was most as a way of comparing webkit releases used by Safari and Chrome.

And your remark can apply to speed tests used in the blog I listed. They are more tests of intrinsic core engine than test of DOM/js interaction we use everyday.

Stash

I agree and I disagree

You are, of course correct squirrel, but on the flip side, they can incite a degree of competition and result in more rapid improvements in general. I'm not disagreeing with what you're saying, but it can also have a positive effect so long as it isn't taken too far or as the only thing they are focusing on. I believe this is part of the reason that jQuery John has created a new benchmark, in order for it to be more representative of what is actually used in the real world - of course, I expect he's biased towards what jQuery uses in the real world, but even that can have a positive effect

NickE

the acid tests were originally concieved to highlight (potential, possibly obscure) bugs and quirks in parsing, rendering and simulation related to particular specifications; in reducing the browser's score to a single number it finds itself often used as a rough guideline for browser compatibility. there's nothing inherently wrong with striving for a high acid score, as long as it is achieved in the context of the full implementation of the related aspect. ie. as long as browser vendors do not fix only what is required to pass the acid tests, but use it as a imprecise roadmap of their specification compliance.

however using a test designed for comprehensiveness would probably give a better idea of degree of compliance. the only problem is that there dosn't seem to be any such test out there.