It’s almost like a standards marketing campaign, and I feel the web is better for it. Exhaustive test suites will probably never make headlines, they don’t put out the same amount of pressure.

Honestly, the only browser I worry about hoop jumping is IE. I trust WebKit and Opera and Firefox to make something out of any initial hoop jumping they do. And AcidN can hold them to it. Microsoft, not so much.

I don’t really know many good ECMAScript or DOM tests.

IE7+Acid2 being treated differently than FF+Acid3? In the exact same post, you point out some weaknesses of the Acid3 test — maybe Acid2 was a more important test, and ignoring it was a more powerful statement? Maybe web developers felt that the quality of IE’s CSS support was behind the industry standard and that supporting Acid2 seemed like a goal clearly in line with the IE team’s promise to improve CSS support?

So let’s ask, why isn’t there a comprehensive browser testing suite that is as widely known as Acid2? Is there a suite yet, and it’s just not widely known? Then let’s work on promoting it. Is there no suite yet? Then let’s work on making one. But I’m tired of feeling like little league parents yelling from the stands.

Eric: good points you make; it would definitely have been better if the tests were all available as separate files with no JS whatsoever, and the existing test would serve simply as a shortcut / added feature.

Good feedback :-)

For browser vendors the javascript isn’t really needed as we can plug the tests into our automated test harnesses, but automating the tests on the site increases the visibility hugely - Not many people are willing to sit through clicking each test, but are willing to press a button and look at the results. Allowing both, with a note about js dependancies for the automated would probably be best.

Faruk: Konqueror was first to pass the test, shortly followed by Opera. Safari pssed recently, but I’ve no idea if that credit goes to the fine folks at KDE or if it is a different implementation done by the Apple guys. Gecko and whatever the new IE engine is called, have yet to pass.

When writing unit tests for back end code, I am sure glad there are ways to make a test harness so I can run multiple tests in a batch. What I am trying to say is do not be too afraid of automated tests. Acid3 serve a purpose. Now we need to raise awareness about the formal test suites as well. Anyone who wishes may help out adding info to my Wikipedia article in the making. On that page I reference to formal W3C selectors test suite, BTW.

It bothers me a that a CSS test would be that dependent on JavaScript– a user agent could potentially support one without the other (or be configured that way for a reason). Furthermore, it’s set up so that without JavaScript, I can’t run through the tests manually, nor even see them to check for accuracy. I’m also forced to analyze the JS itself to see if it could have any effect on the individual results or the reporting of those results. For example, does the way it puts things in sequence have any possibility whatsoever of spoiling one or more of the results? And what if the JS uses some feature that breaks in one browser under unusual but reasonable conditions?

In effect, it isn’t a CSS test suite; it’s a CSS and DOM test suite, even though it claims to be otherwise.

This is why I think absolutely minimal dependency is a virtue. If the CSS3.info selectors test were something I could go through manually, plus it offered the JS quick-summary function as an optional feature, I’d be a lot happier with it.

578 individual (but put in sequence via JS so that it’s not 578 pages) tests of CSS selectors, including the CSS3 ones. Sounds to me like that’s exactly the kind of thing you’re looking for, but I reckon you may not have seen it or you probably would’ve linked to it, no?

(btw, don’t know about the other browsers but Webkit passes it 100%)

Eric: You know, it’s weird, but that seems really familiar, like I’ve heard or read something like that before. Now if only I could remember… Oh yeah! It’s basically what the IE team said about not passing Acid2 when the IE7 betas came out, for which they were promptly excoriated.

It’s a good point. People always howl at the IE team but let the FF team get away with the exact same behaviour(s). Personally I’ve noticed a lot of hypocritical actions from the Firefox fan squad. They’re happy for a site to ignore other non-IE browsers so long as it works in FF; they’re happy for FF to ignore an acid test when they screamed about IE7; etc.

kimblim: I read it like this: WebKit and Opera shouldn’t be focusing on completing the Acid3 test, but instead do what Mozilla are doing: making a great browser.

My read on that is that Opera (not sure about WebKit) aren’t focussed on Acid3 to the exclusion of making a great browser. They’re actually doing a good enough job of their core business that they can also spend time on Acid3.

The Firefox project doesn’t appear to have that luxury. It looks like they have to ignore the test to make sure they get FF3 out as soon as possible. The honest truth is that Firefox 2 is in a bad way, with memory leaks and so on - the new version is far more stable and it’s important to get that out into the market.

Yes, it’s the same result, I just don’t think think Firefox project’s approach is based on a laudable decision - just necessity. The community didn’t cut IE any slack on those grounds so I see no reason FF should get a pass ;)

Frankly no browser team should really get beaten up over this sort of stuff so long as they’re genuinely working on improvements.