Topic: ACID3 test released (Page 1 of 1)

The Web Standards Project just released the final version of the ACID3 test:
http://www.webstandards.org/press/releases/20080303/

Take your browser through the test:
http://acid3.acidtests.org/

My results:
ie7: who knows? It's not even readable...
saf3: 39
op8835: 46
ff2: 50
ff3b3: 59
op9816: 65
wk-r30628: 87

--
var Liorean = {
abode: "http://web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

OT: poi: Could you explain in a few sentences why is supporting standards so difficult anyway? Are they not written well enough, specific enough? Is it the number of features needed too great? What is it?

I hate to jump in here, but in the past the standards were well behind what the browser vendors were capable of offering, so they went ahead and added their own features.

Eventually the standards caught up and then went further, the problem was that the vendors had to support their customers and developers who would expect their sites to work still. The W3C made it clear they were heading in one direction and although they took some features and standards from the vendors they sometimes made their own and left the vendors behind, think IE and their 'broken' box model. It's really just their interpretation, before standards were set in place. Then because it would make such a grand impact on the layout of the majority of the websites out there, Microsoft were very slow to put in support for the real box model.

With the Acid 2 and Acid 3 test, the standards out there are finally fairly cutting edge, and it's the vendors who need to catch-up, however it's not always in their interest to add a new CSS feature is there's a browser feature that would be much more important to them from a business and competition point of view. So it's unsurprising to see no browsers pass the Acid3 test, but it's important to see how quickly they make efforts to pass it.

It's not really that hard to support web standards. WebKit proves that - with the smallest development team and the shortest time in development of the big four, they've gone from worst to best (hixie actually had trouble finding tests for ACID3 that would lower WebKit's score! That's not saying they have the best standards support, just that they have the least buggy one.)

There's several aspects of standards support however. Let me take an example: There's a HTTP feature I read about in bugzilla months ago, I can't really recall which feature, but Mozilla has supported it for ages. Then Apache went and actually implemented it correctly per spec on the server. Suddenly, Apache hosted sites which upgraded to the newest version started breaking... because nobody had actually implemented the server part of the specification correctly before, and now they encountered clients with correct implementations, so nobody knew the whole feature was broken, but only if both client and server was compliant at the same time!

Another example: If you implement ES3 per specification, there is no way to get from the Program production to the RegExpLiteral production. I guess they missed it Nobody noticed until the recent revival of the ES4 development, because nobody actually implemented the specification, everybody reverse engineered Netscapes JSRef and Microsofts JScript, including Netscape and Microsoft themselves.

A third example: The DOM1 was largely informed by the browser implementations. However, neither DOM1, nor the more Java oriented DOM2 and DOM3, interoperate well with JavaScript. One particular issue is that the interface hierarchy does not work with the prototypal inheritance scheme of JavaScript. For the interface objects to be exposed and their prototypes to be dynamic, browsers MUST have multiple inheritance on the prototype delegation level. None of the browsers today do (though they have patch-ups for that in some places), and when you scratch at the surface, the only implementation that actually can retain coherency in the face of this is that of IE, because IE doesn't actually pretend that the DOM objects work through the JavaScript prototypal inheritance scheme in the first place.

A fourth example: Internet Explorer implemented XML a bit too early. They implemented XML before the Namespaces spec, and Infoset, and Canonical XML. The result is that the XML engine that Trident is dependent upon is not capable of daeling with namespaces, and Microsoft didn't want to change to a later more compliant version of MSXML because XML was used loads of places in intranets, and several XML applications including their pseudo-XML Office-HTML would break if they changed to a Namespaces compatible implementation. There are in other words XML applications/markup languages that stop working in implementations that support Namespaces, simply because that's what Internet Explorer started out with!

--
var Liorean = {
abode: "http://web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

Note that for a lot of these specifications, the later you start implementing them, the less work it is. There's code in Mozilla that has had to be rewritten 3 or 4 times and now needs another rewrite because the CSS2.1 spec has kept changing in fairly fundamental ways.

So one reason not everything is supported is that in some cases the browsers support what the spec used to say a few weeks ago....

It's especiall true for features introduced by browser vendors and submitted for standardization.

I must say I'm surprised by how fast Acid 3 came to life. I haven't looked at it and don't know exactly what's tested but anyhow this is great to have another solid test suite for open standards now that all 4 major browsers pass Acid 2.

Hmm. slashdotted!

--
var Liorean = {
abode: "http://web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

quote:

---

liorean said:
Hmm. slashdotted!

---

just noticed as well ... congratulations to the person who pays our bills!

Can add some interesting data to this:

ie7 (with add-on): 12
ie7 (IEESC): 6
ie8b1 (no MSXML 3.0 SP9): 17
ie8b1 (MSXML 3.0 SP9): 17
ie8b1 (IEESC): 18 (!)
ie8b1 emulating ie7 (no MSXML 3.0 SP9): 14
ie8b1 emulating ie7 (MSXML 3.0 SP9): 14
wk-r30868: 90 (Apple's definitely going to be the first ones to succeed ACID3)

--
var Liorean = {
abode: "http://liorean.web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

quote:

---

wk-r30868: 90 (Apple's definitely going to be the first ones to succeed ACID3)

---

Acid3 : checked.

spam removed.

(Edited by Tyberius Prime on 04-18-2008 11:01)

For what its worth I got a score of 39/100 running Safari on an iPhone with 1.1.4 firmware. While very impressive, this is not terribly surprising since it is after all running pretty much the same Mac OS X and Safari (and webkit) code as on a Mac.

Safari 3.0 under Mac OS X 10.4.11 also gets the same 39/100 score (as previously reported for Mac OS X 10.5).

I also tried a Nokia N95 mobile phone but it completely failed to run the test. This was a surprise since it is supposed to use webkit (like Safari), it failed due to a lack of Javascript support.

A Palm TX running the Blazer browser seemed to get a bit further than the Nokia but also failed to score anything.

Finally, just for laughs I tried Internet Explorer 5.2.3 under Mac OS X 10.4.11 (the last ever version of IE for the Mac) and it also failed to run the test and scored nothing.

I would guess Safari 3 beta for Windows would be scoring the same as the Mac version, anyone tried it?

(Edited by Aiden Savannah on 05-21-2008 07:15)

Aiden: Both Opera and Apple have shown internal or nightly builds that have scores of 100. The most recent release of Safari3.1.1 (win) gets a score of 76 for me (with scores of 100 for nightly builds), the most recent volunteer tester build (build 10005, of the Kestrel fork which will become Opera 9.50) of Opera gets a score of 79.

Neither browser succeeds at being fast enough to finish the smoothness criteria however.

--
var Liorean = {
abode: "http://codingforums.com/",
profile: "http://codingforums.com/member.php?u=5798"};

Aiden, what's with the spammy links?