Acid3 Race In Full Swing, Opera Overtakes Safari

enemi writes "Just a few days after Safari released version 3.1, Opera employee David Storey writes on his blog that they've overtaken Apple's browser in the Acid3 test. In the race to be the first to reach the reference rendering, Opera's software leads now with 98%, closely following by Safari with 96% and Firefox 3 beta 4 with 71%. He also noted the implemented features will not make a public appearance in the following weeks, because they are getting close to releasing Opera 9.5. That version has been under public testing since September and the new CSS3 color modes and font rendering features might further delay this. They will probably show the score in a preview build soon and wait for a post 9.5 stable build to release the new features to the public." Update: 03/26 21:21 GMT by Z : Opera is now at 100%, apparently, with Safari close behind at 98%. Update: 03/27 by J : Public build r31356 of WebKit (Safari's rendering engine) is at 100%.

Comments

Safari gets 96%?

[SaidinUnleashed]

My just-updated Safari (3.1) keels over at 77%.

What version is getting 96%?

Old News :)

[niXcamiC]

Newer builds pass with 100% http://my.opera.com/desktopteam/blog/2008/03/26/opera-and-the-acid3-test

Is anyone else concerned about the 'hacks' ?

[recoiledsnake]

The problem with races is that the teams do almost anything just to cross the finish line faster. The speed at which the browsers seem to be gaining acid3 compatibility is frankly worrying me. Any developer worth his salt knows that browsers are huge and complex applications and every change must be discussed, designed and implemented properly as to not impact something else and be modular, be properly commented and be clean and well written code.

Also, Acid3 is just about the corner cases, and might not reflect the full standard completely. So a browser can pass the test and still suck at implementing standards, though passing the test is good step. It's just that the high speed of the compatibility improvements for ACID3 in almost all the mainstream browsers screams of hackathon coding sessions to get those few points a day till 100 so that there can be a marketing and PR blitz rather than properly planned programming. I think there is a very good chance of the code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which features are being thrown into the code.

I think there is a very good chance of the new code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which 'features' are being thrown into the code just to make headlines. Being a programmer, I am sure that non-trivial portions of the code will have to be rewritten later. Haste makes waste.

Re:Is anyone else concerned about the 'hacks' ?

[Bogtha]

The problem with races is that the teams do almost anything just to cross the finish line faster.

Do you have any evidence for this?

Any developer worth his salt knows that browsers are huge and complex applications and every change must be discussed, designed and implemented properly as to not impact something else and be modular, be properly commented and be clean and well written code.

No, browsers aren't actually all that large (the rendering engines for the Opera desktop browser and the mobile browser are the same), and you don't have to painstakingly discuss absolutely everything. Nothing would ever get done.

It's true that rushing to meet one goal can cause regressions elsewhere; that is what regression tests are for. And I don't know about Opera, but Safari/Webkit has plenty of them.

I think there is a very good chance of the code containing hacks and workarounds and also tons of security loopholes because of the insane speed at which features are being thrown into the code.

So this is actually just wild-ass speculation and not something you have solid reasons to believe?

Yes, Safari and Opera are both moving fast. Extremely fast compared with Firefox and Internet Explorer. But that is because they are much smaller codebases. Gecko is huge and crufty. Changing one thing can have knock-on effects all over the place. Internet Explorer has three very different rendering engines attempting to remain compatible with years-old intranet applications.

One of the reasons Apple chose KHTML instead of Gecko for Safari was that it was much smaller and had a cleaner design. And that choice has paid off in spades, the turnaround on new features and functionality is extremely quick.

Opera have been focusing on the mobile market for a long time now, it's a core part of their business and a substantial portion of their revenue, so they've always kept the code small and manageable.

What you are seeing here are not crazy hacks, but the consequences of years of savvy architectural and management decisions. When you invest in clean design up-front, the cost of efforts like this is vastly reduced.

Re:Is anyone else concerned about the 'hacks' ?

[Drishmung]

Possible, but I suspect that, at least for Opera and Safari, this is not the case.

Opera have said that they get 100/100, but they are not yet claiming victory. They are fixing a brand new implementation, that will be released 'soon', when it is ready. I imagine that the release will involve a ton of regression testing and code quality analysis.

Likewise Safari has various standards that the code has to adhere to. Reading the Webkit blog entries so far I get the feeling that it has not been enough merely to pass a test; there has been extensive consideration the best way to fix the code.

Yes, it's a race, but not at any cost, and the goal is not to just pass Acid3, it's to deliver a better browser.

Thus far, I'm optimistic that Acid3 is improving the overall code quality of the participating browsers.

Re:Is anyone else concerned about the 'hacks' ?

[Bogtha]

165MB is a HUGE amount of source code for something that you claim has a 'much smaller and cleaner' design and is "not all that large".

Firstly, that tarball is a SVN working copy and includes such things as Bugzilla and other Webkit-related websites/web applications, testcases, etc. Deleting the Subversion directories alone drops the uncompressed size by a gig from ~1.4GB to ~400MB. Deleting most of the testcases drops that ~400MB to ~100MB. Deleting the websites drops that ~100MB to ~80MB. So you see the actual source code for Webkit only comprises about 5% of the archive, and there's a bunch of testcases and support tools I missed removing there.

Secondly, I didn't say that Safari is "not all that large". I said that browsers are not all that large. Download, for example, KDE, and see how small a part of it Konqueror is. You were characterising developing a browser as this monumental effort that required a special, painstakingly slow development approach. In reality, there are far larger codebases that are worked on at a much faster rate by many more people, with way less communication. Browsers really aren't anything special in this regard.

Thirdly, it's not just my claim about the relative sizes of the codebases. Check out the announcements (1 and 2) explaining the reasons for going with KHTML:

Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance

Weighing in at less than one tenth the size of another open source renderer, Konqueror helps Safari stay lean and responsive.

Do you think Webkit is ten times the size it was then? Or do you think Gecko is ten times smaller than it was then?

Instead of fixing the rendering of the 'Ahem' font, it seems to turn off font smoothing just to make it look like the reference rendering(note that it does it only for the web font). What about such bugs for other fonts?

Ahem isn't a real font. It's a dummy font that only has four glyphs and weird sizing. Its glyphs need to have very specific dimensions in order for the test to be accurate. Turning off font smoothing for this font in particular is enforcing those very specific font metrics. Yes, it looks like a hack, but that's far from the whole truth. In the real world, users that change their font sizes would also cause "failures" like this; the specific font metrics of the Ahem font are assumed by the test for accurate results. At worst, you could say it's a hack to set up the necessary conditions for the Acid3 test to run. These font metrics aren't part of the Acid3 test, they are a prerequisite for accurate results.

Bug 17086 is the bug you should be looking at for background. The question is whether or not antialiasing/font smoothing should have an effect on font metrics or if it should be clipped. It may turn out that the Acid3 test is updated to make this a non-issue.

What about such bugs for other fonts? Brushed under the carpet called Acid3 compliance.

Here you go misrepresenting your guesses as actual fact again. If you don't know the details, don't make accusations like that. Should antialiasing/font smoothing increase the size of text slightly or is that a bug? That's a difficult question to ans

That's good, but don't get too carried away

[whitehatlurker]

Okay, I'm an Opera fanboi. (Well, it's my preferred browser, anyway.) Take that for what ever it may mean to you.

However, this falls into the "Firefox does Acid 2" category. Until this is done with the release version of the browser, it's a nice thing, but not really available to the average web user. (Cue the witticisms from the "hyuck, hyuck - well Opera users aren't average - either of them" crowd.)

This is a good thing. Opera has been a company which has been dedicated to (among other things like speed, security and innovations in the interface) support for web standards. This is just another step in that direction.

Kudos to the desktop crew for this accomplishment.

Re:too late

[hkmwbz]

Yeah, Opera can do it, but isn't going to release the capability

RTFA. They will, shortly.

In my book Opera is losing the race.

How so? Opera is ahead of Firefox. Heck Firefox hasn't even passed Acid2 yet!

I'll probably burn in karma-land for this

[93 Escort Wagon]

If this were news about IE, I'd care. If it were news about Firefox, I'd care. Since I'm a Mac user, if it were news about Safari I'd probably care, at least a little (although I use Firefox). But Opera? I don't even test my stuff against that browser - it's just never been particularly relevant.

Now, I realize that Opera zealotry is as fervent as the worst Mac fans, and loses nothing to the Nikon/Canon camps; but really - the installed base is tiny. When I look at my site stats, Opera doesn't even show up (and even Netscape 4.x still has a tiny sliver of the pie). So I'm not sure even the "competition is good for everyone" argument particularly applies here.

Re:The Next Milestone

[Anonymous Coward]

OK, how does the consumer win, exactly?

It's neat that there's actually competition between browsers for compliance, but the Acid tests seem to be picking just a few features. They're not comprehensive -- they're not even testing the more common or useful features.

Sure, it's great that you've got Opera and Firefox and Microsoft in a contest that involves fixing, for example, UTF-16 support, but if I had to pick the 100 top browser standards and compatibility issues in the world today, UTF-16 support would not make the list. It might not make the top 1000.

And Acid2, for all its emphasis on CSS, hasn't fixed CSS -- it's still wildly different everywhere, even if you only consider Acid2-passing browsers. I can pick 3 different browsers that pass Acid2 (Opera 9.26 and Firefox 3b4 and Safari 2.0), and my HTML pages don't look or act quite the same in any of them.

I guess maybe it was "really tremendously awful" before, and now it's only "pretty bad". That's neat, but how hard is it really to write a more authoritative test suite? I'm a bit disappointed by the AcidN tests.

My test suite would look like this:

The CSS test suite will start a web server on localhost:5533. It will then call your browser, as "browser_name --render --width=W --height=H --format=PNG URL -", which is expected to render the url 'URL' to a PNG bitmap, size W by H pixels, to stdout, and then exit. This is then compared to the reference rendering, and a 'pass' or 'fail' is recorded. This is done for *each* CSS feature. Not only is a single score (% of correctly supported features) reported, but also the list of actual passes/failures.

Similar tests for JS/DOM/HTML/etc. could exist. We would get not only a comprehensive test of the browser, but we'd get lists of exactly what each browser supports (and pictures of how it bones it) -- *far* more useful than simply "73/100 on Acid3", which doesn't tell me anything about whether my browser can render my webpage, or what to do if it doesn't.

Re:*tap* *tap* ... Is this thing on?

[Blakey Rat]

Apples to oranges, coward.

You're talking about bugs that cause your application to crash or destructively malfunction in some way. ACID tests bugs that might cause the menu to be 3 pixels further left than you want it. And the funny part is that as long as all browsers have difference, you'll STILL need to test on all browsers (for JS issues alone if nothing else), so you'll notice the ACID-type bugs long before putting the site live.

Sorry, I think these ACID tests are near-useless.