You seem to have totally missed the point. The SAT is an American standard. The person asking the question is from the UK. Despite Tony Blair's efforts, the UK is still not part of the USA.
Exactly why do you think that a person from the UK would know the content of American tests, and how many prep classes for American tests do you think that there are in the UK?
PNG is nice, but thanks to Microsoft, and it's own not supporting animation, it just doesn't work for some things yet.
The only shortcoming in Internet Explorer's PNG implementation has been the lack of support for the alpha channel. Complete transparency has worked for years. Given that the GIF format only supports complete transparency, it's unreasonable to blame Microsoft for PNG being unsuitable - even considering Internet Explorer's bugs, PNG is as capable as GIF in this regard, while usually being smaller.
For the past seven or eight years, the only meaningful downside to PNG is if you want animation, and a bug in early versions of Safari relating to gamma correction.
Richard Nixon was forced to resign over his antics. When Bush does pretty much the same thing, half the country are apologetics because he claims to be Christian and conservative, and the other half moan about it but don't actually do anything.
Also, compare the anti-war opinions expressed during Vietnam and during the current war with Iraq. Pretty similar, I think. Now compare the actions resulting from the anti-war opinions. Somehow, almost all the outrage is being channelled away into apathy, where before it was acted upon.
Security researchers generally want things secure.
Disclosing vulnerabilities at the least convenient time for Microsoft accomplishes this - in the long run - by discouraging Microsoft from continuing their inane scheduling. If every security researcher published straight after Patch Tuesday, Microsoft would have no option but to give it up.
And why have two proprietary display values, and not support the ones that are supposed to be there?
Because inline-block isn't supposed to be there. Not yet. The inline-block property was a proprietary Internet Explorer property. It has been added to CSS 2.1, but that specification is not yet finished - it's a working draft. So far, no finished W3C specification includes inline-block, it's still a non-standard Microsoft extension.
But either way, the test is not terribly relevant; ACID is a test of invalid CSS, to see how the browser handles broken code.
Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine:
Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.
There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?
It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.
Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?
It depends on how you look at it. The obvious, sensible interpretation is that when the customer buys from AllOfMP3, AllOfMP3 make the copy and the customer imports it. Clearly that would be legal according to the law you cite. A twisted interpretation, which I'm sure the BPI would consider using, is that the customer makes the copy through the act of purchasing, despite not actually ever coming into contact with the original. Since it would be the customer making the copy and not merely importing it, the law you cite wouldn't apply.
The NY Times says, "The poll found that 53 percent of Americans approved of Mr. Bush's authorizing eavesdropping without prior court approval 'in order to reduce the threat of terrorism.'"
Yes, but the NY Times doesn't say that they approved of Mr. Bush's authorising eavesdropping with no court approval at all. The 53% includes the Americans that believe retroactive warrants are acceptable but warrantless spying is not.
When did "eavesdropping" become the politically correct euphemism for spying, anyway?
Very funny:). Of course, writing testcases isn't just a case of generating the document to test. At the bare minimum, you also have to have a human read the specifications and determine what the correct output for each particular testcase is. And unless you want to have a human verify each testcase manually for every build, they also need to create a computer-readable representation of the correct output that can be automatically compared with what the rendering engine actually outputs.
It's just a case of "When our guys do it, it's OK, but if your guys do it it's not" syndrome.
It's an inevitable consequence of a populace that understands football better than politics. The idea that the parties are supposed to work together to support society is not a familiar concept. They think it's about two teams, one of which must be the winning side and one of which must be the losing side. They've picked a side, not realising that politics is not a zero-sum game.
There's ~90 element types defined by HTML 4.01. Most of those element types have multiple attributes. There's ~100 properties defined by CSS 2.1. Of those properties, most of them take multiple property values. Of those property values, many take different units. And don't forget the order in which the rulesets are listed matters, as does the multiple ways of associating style rules with elements. And don't forget that elements can interact with one another in multiple ways, as can boxes.
To carry out the procedure you describe, taking into account all the different interactions between multiple element types, multiple attributes, multiple properties with multiple values of multiple lengths would involve writing millions of testcases. Are you volunteering?
Sure any analysis you do is going to be somewhat biased, but they should still do analysis.
Who's saying they don't? All he's saying is that you can't boil an analysis like that down into a simple, objective number.
How can Microsoft get away with saying there isn't an official test suite that exhaustively tests whether you comply with the standard or not?
Because it's true.
They need to create this test suite if they plan on implementing the spec.
Nobody else has. That's because it's impossible to do so. Test suites only detect non-compliance, they don't prove compliance. It's possible to say that an implementation passes all the tests in a particular test suite, but that merely proves compliance to the test suite. Because the set of all possible web pages is infinite, an exhaustive test suite is impossible. You can only do your best by writing lots and lots of testcases that you feel are representative of the bugs that you might encounter.
Even if Microsoft did produce this test suite, it would still just be their own test suite, not an official one, so what he said would still be true (and people would probably accuse them of rigging the tests).
Why should an entire development team at the world's biggest software company be held to lower standards than a single college student?
They aren't, you are being ridiculous. Sure, a college student might be expected to generate test cases, but as a development aid, not exhaustive testcases that prove compliance, and not for projects anywhere near as big as a full-featured web browser.
He says Acid2 is a great set of things to be testing, [but] some of the features on that list weren't going to go to the top of our list. When you implement a spec, you're expected to implement the entire spec.
Actually, that depends on the spec. Some parts of CSS are optional. Even so, I'm not arguing that their current implementation is acceptable. Neither is he. If you noticed, he said some of the features weren't at the top of the list, not that they weren't on the list at all. Not everything can go at the top of the list. That's inherent to the entire concept of a list. You do know what a list is don't you?
Once again, if a college student provided a line like that to a professor, the response would be "enjoy your D, I'll see you again next quarter".
How about you leave the silly college analogies behind? Professional software development doesn't work like a college project. College projects have up-front requirements and a finish date. Professional software development is an ongoing project with multiple releases.
HTML/CSS might be a large spec, but MS has no excuse to not implement it in full
Why are you telling me this? I'm not making excuses for them, I'm explaining how a test suite that people are demanding is not possible and that no other browser developers are held to the same standard. Come back when any browser implements HTML or CSS in full and you might have a point. But pick any browser and I'll be able to show you parts of HTML or CSS that they don't implement.
However, it is important to note that all XML parsers MUST report well-formedness violations.
XML parsers must report well-formedness violations to the application. Spec. There's no requirement that the end-user see any error message as far as I know, that's up to the application.
Validating parsers MUST at least offer validity violation messages as a user option.
Yep, but there's no requirement that parsers be validating parsers, you can write a non-validating parser and still conform to the spec:).
Sure, it's a test of strict compliance with certain aspects of the W3C CSS specs. Speaking as a guy responsible for a web site, though, I care far more about whether IE7 supports everyday, often-useful aspects of W3C specs. Here are some examples that I do care about, all of which have directly affected my work on the site in recent weeks
Er, all three of the things you have listed are tested for in the Acid2 test. Have you actually read it, or did you decide it was about "bragging rights" based on hearsay? It seems specifically geared towards testing exactly what you are concerned with.
I'd love for someone to drive through the proposed CSS3 border-radius property and friends, so we could drop all the image-based hacks once and for all.
On the other hand, do you know how many of the Acid2 non-compliance things are relevant to me? None
Wrong. You yourself state that you'd like to use border-radius, which is part of CSS 3. CSS 2 user-agents will think that is invalid CSS, and it's the "non-compliance things" that you claim don't matter which ensure that CSS 2 user-agents handle code such as this in a regular, predictable way.
Forwards-compatibility with future CSS specifications is a major practical reason why error handling needs to be defined and tested. Would you really want older browsers blowing up whenever you used something in a CSS specification published after they were developed?
if a page is invalid, you shouldn't rely on standards compliant browsers to make things right.
You should if the standards in question explicitly require the browsers to do so.
As you are a web author, I assume you've written a CSS 2 stylesheet? Are you aware that most CSS 2 stylesheets are invalid CSS 1 stylesheets? And that it's the error handling defined in the CSS 1 specification that defines how your invalid code is handled in older browsers?
Do you plan on ever writing a CSS 3 stylesheet? Because if you do so, you'll be relying on the error handling defined by the CSS 2 specifications and implemented in current browsers. Wouldn't it be nice if you could do that safe in the knowledge that the browsers are going to behave in a certain way when faced with your invalid CSS 2 code?
That is the problem that the Acid2 test is trying to solve by including invalid code. Having invalid code handled correctly is an important part of ensuring forwards compatibility, because what appears to be invalid code to today's implementations could be perfectly reasonable code according to tomorrow's implementations.
If - as is implied - he's the ONLY person at Microsoft who gives a damn about standards
I don't think that's implied, just that he was the primary advocate within Microsoft. For example from The CSS saga, co-written by the inventor of CSS:
Had it not been for the browsers, CSS would have remained a lofty proposal of only academic interest. The first commercial browser to support CSS was Microsoft's Internet Explorer 3 which was released in August 1996. At that point, the CSS1 specification had not yet become a W3C Recommendation and discussions within the HTML ERB were to result in changes that Microsoft developers, led by Chris Wilson, could not foresee. IE3 reliably supports most of the
Chris Wilson was certainly important in the development of CSS.
But to turn around and say "hey, we ARE standards-compliant
Except he's not saying that.
If he lacks the time to even establish which parts of the specs are implemented
He's made extensive postings on the Internet Explorer development weblog and his own weblog discussing precisely this. He knows what's implemented and what isn't.
He should also stop and bear in mind that since he himself states he does not know the actual level of compliance
He didn't say that. He said that there isn't an easy way to come up with an objective figure. If you read the weblogs he posts to, it's quite clear he knows what's going on and is discussing the level of compliance publically. But saying "Oh, we're at 52% this week" makes no sense, and he was right to say so. The only way to have an intelligent discussion about the level of compliance is to talk about specifics - which is what he has been doing.
For that matter, the lack of knowledge on compliance would suggest that the browser is improperly tested.
You're drawing all of these dubious conclusions from faulty premises. You've assumed that he's this clueless PHB who doesn't know what's going on, when all he's saying is that it's stupid to assign a number to Internet Explorer's level of compliance. As far as I'm aware, there haven't been any other browser developers giving specific percentages to their compliance level - do you consider all of them to be bumbling idiots too?
If the test suite points out zero particular things that are broken, then the implementation is compliant.
Nonsense. I've just invented BogthaML. The specification requires implementations to produce a flying 3D world when they see <flying-three-dee-world-baby/> and a blank page when they see <html></html>. So far, I've only written the <html></html> testcase. By your logic, Firefox is a compliant BogthaML user-agent because it passes all the testcases.
Do you see the problem with that logic now?
If there are 5 out of 1000 things that are broken, it is almost compliant.
But what if those five things are really important? I've just implemented a second testcase for BogthaML that includes <flying-three-dee-world-baby/>. Unfortunately, it appears there's a bug in Firefox that prevents it from being rendered. Luckily, it still passes the other testcase, so the brainy Firefox developers have already done 50% of the work necessary to produce a compliant BogthaML user-agent. Right?
Yes, I'm using deliberately contrived examples. But the principle is a sound one. Testcases are not equal in importance, nor are they provided in numbers representative of their importance. These two facts mean that providing a percentage number simply based on how many testcases are passed isn't going to give you a useful number.
The XML standard got it right. If it isn't valid XML, the browser must reject it.
Actually, this isn't true. The XML specification only requires that parsers throw fatal errors when a document isn't well-formed. And it doesn't require browsers to reject these documents, only that they stop parsing. Browsers are free to do whatever they like with invalid but well-formed documents, and they are free to show everything up to the point of the error for malformed documents.
If you wrote C code like the Acid test, you wouldn't expect it to compile.
You would if the C standard explicitly required compilers to do so.
The fact is, it doesn't make much sense to compare CSS to C. One is an imperative programming language, the other is a declarative style language. You can't miss out bits of a C program and still have it work right, but CSS is designed around the idea that you can do just that.
I don't want to include a CSS 3 property in my stylesheet only to have every CSS 2 browser simply throw everything away, I want them to apply the CSS 2 properties they do understand and ignore the bits they don't. Fortunately, this is exactly what the CSS specifications require, which is why the Acid2 test includes invalid code - it's testing this part of the specification.
If the question is boolean, then the test pointed to by grandparent definitely can give an objective answer.
It can definitely prove that something is non-compliant. But it cannot definitely prove that something is compliant. A hell of a lot of bugs only manifest themselves in unusual circumstances. Unless you have prior knowledge of these bugs, you'd have to be very lucky to coincidentally trigger them with a simple test case.
It can give you a consistent answer on the number of passed and failed tests. That number may be biased for a given single run, but it can give a consistent answer, so it can be used to test relative compliance.
No, it can't. Suppose there are a hundred testcases for selectors and five testcases for a particular float configuration in wide use on the web. By adding support for more selectors, a Microsoft engineer might pass twenty more testcases, but introduce a regression causing them to fail the five really important float testcases. By your standards, this would be more compliant, even though it would be considered a disaster in terms of compliance.
It doesn't make sense to judge compliance by the number of testcases passed. There isn't a good way of assigning a particular number to how compliant an implementation is. But the real question is why should there be? Does anybody really gain anything by saying that Internet Explorer is 53% compliant instead of 52% compliant? Or does it make more sense to talk about particular bugs and particular features that are supported? I can see how the former might be of use if all you want is a number to criticise Microsoft with, but as a web developer, I can tell you that having a percentage just isn't useful in any way if you are genuinely concerned with practical matters and not political ones.
If MS really were focusing on those tests, even if he really believed that taking number passed over number failed was such a great injustice, they would have those numbers printed in 120 point font and hung on the wall of the developer area.
Do any other browser developers provide a running count of how many CSS testcases they pass and how many they fail?
Either he doesn't know they exist, or he doesn't feel they are important, or he feels the results would leave the audience nonplussed.
Or he thinks the same as I do; that such numbers are unimportant and misleading.
Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine:
Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.
There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?
It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.
Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?
Slashdot Mirror
You seem to have totally missed the point. The SAT is an American standard. The person asking the question is from the UK. Despite Tony Blair's efforts, the UK is still not part of the USA.
Exactly why do you think that a person from the UK would know the content of American tests, and how many prep classes for American tests do you think that there are in the UK?
The only shortcoming in Internet Explorer's PNG implementation has been the lack of support for the alpha channel. Complete transparency has worked for years. Given that the GIF format only supports complete transparency, it's unreasonable to blame Microsoft for PNG being unsuitable - even considering Internet Explorer's bugs, PNG is as capable as GIF in this regard, while usually being smaller.
For the past seven or eight years, the only meaningful downside to PNG is if you want animation, and a bug in early versions of Safari relating to gamma correction.
Richard Nixon was forced to resign over his antics. When Bush does pretty much the same thing, half the country are apologetics because he claims to be Christian and conservative, and the other half moan about it but don't actually do anything.
Also, compare the anti-war opinions expressed during Vietnam and during the current war with Iraq. Pretty similar, I think. Now compare the actions resulting from the anti-war opinions. Somehow, almost all the outrage is being channelled away into apathy, where before it was acted upon.
Disclosing vulnerabilities at the least convenient time for Microsoft accomplishes this - in the long run - by discouraging Microsoft from continuing their inane scheduling. If every security researcher published straight after Patch Tuesday, Microsoft would have no option but to give it up.
Because inline-block isn't supposed to be there. Not yet. The inline-block property was a proprietary Internet Explorer property. It has been added to CSS 2.1, but that specification is not yet finished - it's a working draft. So far, no finished W3C specification includes inline-block, it's still a non-standard Microsoft extension.
Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine:
It depends on how you look at it. The obvious, sensible interpretation is that when the customer buys from AllOfMP3, AllOfMP3 make the copy and the customer imports it. Clearly that would be legal according to the law you cite. A twisted interpretation, which I'm sure the BPI would consider using, is that the customer makes the copy through the act of purchasing, despite not actually ever coming into contact with the original. Since it would be the customer making the copy and not merely importing it, the law you cite wouldn't apply.
How long until Jodie Foster gets banned?
Stallman wants nothing to do with open source, he's concerned with Free Software.
Yes, but the NY Times doesn't say that they approved of Mr. Bush's authorising eavesdropping with no court approval at all. The 53% includes the Americans that believe retroactive warrants are acceptable but warrantless spying is not.
When did "eavesdropping" become the politically correct euphemism for spying, anyway?
Very funny :). Of course, writing testcases isn't just a case of generating the document to test. At the bare minimum, you also have to have a human read the specifications and determine what the correct output for each particular testcase is. And unless you want to have a human verify each testcase manually for every build, they also need to create a computer-readable representation of the correct output that can be automatically compared with what the rendering engine actually outputs.
It's an inevitable consequence of a populace that understands football better than politics. The idea that the parties are supposed to work together to support society is not a familiar concept. They think it's about two teams, one of which must be the winning side and one of which must be the losing side. They've picked a side, not realising that politics is not a zero-sum game.
There's ~90 element types defined by HTML 4.01. Most of those element types have multiple attributes. There's ~100 properties defined by CSS 2.1. Of those properties, most of them take multiple property values. Of those property values, many take different units. And don't forget the order in which the rulesets are listed matters, as does the multiple ways of associating style rules with elements. And don't forget that elements can interact with one another in multiple ways, as can boxes.
To carry out the procedure you describe, taking into account all the different interactions between multiple element types, multiple attributes, multiple properties with multiple values of multiple lengths would involve writing millions of testcases. Are you volunteering?
Who's saying they don't? All he's saying is that you can't boil an analysis like that down into a simple, objective number.
Because it's true.
Nobody else has. That's because it's impossible to do so. Test suites only detect non-compliance, they don't prove compliance. It's possible to say that an implementation passes all the tests in a particular test suite, but that merely proves compliance to the test suite. Because the set of all possible web pages is infinite, an exhaustive test suite is impossible. You can only do your best by writing lots and lots of testcases that you feel are representative of the bugs that you might encounter.
Even if Microsoft did produce this test suite, it would still just be their own test suite, not an official one, so what he said would still be true (and people would probably accuse them of rigging the tests).
They aren't, you are being ridiculous. Sure, a college student might be expected to generate test cases, but as a development aid, not exhaustive testcases that prove compliance, and not for projects anywhere near as big as a full-featured web browser.
Actually, that depends on the spec. Some parts of CSS are optional. Even so, I'm not arguing that their current implementation is acceptable. Neither is he. If you noticed, he said some of the features weren't at the top of the list, not that they weren't on the list at all. Not everything can go at the top of the list. That's inherent to the entire concept of a list. You do know what a list is don't you?
How about you leave the silly college analogies behind? Professional software development doesn't work like a college project. College projects have up-front requirements and a finish date. Professional software development is an ongoing project with multiple releases.
Why are you telling me this? I'm not making excuses for them, I'm explaining how a test suite that people are demanding is not possible and that no other browser developers are held to the same standard. Come back when any browser implements HTML or CSS in full and you might have a point. But pick any browser and I'll be able to show you parts of HTML or CSS that they don't implement.
XML parsers must report well-formedness violations to the application. Spec. There's no requirement that the end-user see any error message as far as I know, that's up to the application.
Yep, but there's no requirement that parsers be validating parsers, you can write a non-validating parser and still conform to the spec :).
No, they added :hover on any element to Internet Explorer 7. It's version 6 and below that require <a> elements.
Er, all three of the things you have listed are tested for in the Acid2 test. Have you actually read it, or did you decide it was about "bragging rights" based on hearsay? It seems specifically geared towards testing exactly what you are concerned with.
Wrong. You yourself state that you'd like to use border-radius, which is part of CSS 3. CSS 2 user-agents will think that is invalid CSS, and it's the "non-compliance things" that you claim don't matter which ensure that CSS 2 user-agents handle code such as this in a regular, predictable way.
Forwards-compatibility with future CSS specifications is a major practical reason why error handling needs to be defined and tested. Would you really want older browsers blowing up whenever you used something in a CSS specification published after they were developed?
You should if the standards in question explicitly require the browsers to do so.
As you are a web author, I assume you've written a CSS 2 stylesheet? Are you aware that most CSS 2 stylesheets are invalid CSS 1 stylesheets? And that it's the error handling defined in the CSS 1 specification that defines how your invalid code is handled in older browsers?
Do you plan on ever writing a CSS 3 stylesheet? Because if you do so, you'll be relying on the error handling defined by the CSS 2 specifications and implemented in current browsers. Wouldn't it be nice if you could do that safe in the knowledge that the browsers are going to behave in a certain way when faced with your invalid CSS 2 code?
That is the problem that the Acid2 test is trying to solve by including invalid code. Having invalid code handled correctly is an important part of ensuring forwards compatibility, because what appears to be invalid code to today's implementations could be perfectly reasonable code according to tomorrow's implementations.
If you're talking about child selectors, then yes they do.
I don't think that's implied, just that he was the primary advocate within Microsoft. For example from The CSS saga, co-written by the inventor of CSS:
Chris Wilson was certainly important in the development of CSS.
Except he's not saying that.
He's made extensive postings on the Internet Explorer development weblog and his own weblog discussing precisely this. He knows what's implemented and what isn't.
He didn't say that. He said that there isn't an easy way to come up with an objective figure. If you read the weblogs he posts to, it's quite clear he knows what's going on and is discussing the level of compliance publically. But saying "Oh, we're at 52% this week" makes no sense, and he was right to say so. The only way to have an intelligent discussion about the level of compliance is to talk about specifics - which is what he has been doing.
You're drawing all of these dubious conclusions from faulty premises. You've assumed that he's this clueless PHB who doesn't know what's going on, when all he's saying is that it's stupid to assign a number to Internet Explorer's level of compliance. As far as I'm aware, there haven't been any other browser developers giving specific percentages to their compliance level - do you consider all of them to be bumbling idiots too?
Nonsense. I've just invented BogthaML. The specification requires implementations to produce a flying 3D world when they see <flying-three-dee-world-baby/> and a blank page when they see <html></html>. So far, I've only written the <html></html> testcase. By your logic, Firefox is a compliant BogthaML user-agent because it passes all the testcases.
Do you see the problem with that logic now?
But what if those five things are really important? I've just implemented a second testcase for BogthaML that includes <flying-three-dee-world-baby/>. Unfortunately, it appears there's a bug in Firefox that prevents it from being rendered. Luckily, it still passes the other testcase, so the brainy Firefox developers have already done 50% of the work necessary to produce a compliant BogthaML user-agent. Right?
Yes, I'm using deliberately contrived examples. But the principle is a sound one. Testcases are not equal in importance, nor are they provided in numbers representative of their importance. These two facts mean that providing a percentage number simply based on how many testcases are passed isn't going to give you a useful number.
Actually, this isn't true. The XML specification only requires that parsers throw fatal errors when a document isn't well-formed. And it doesn't require browsers to reject these documents, only that they stop parsing. Browsers are free to do whatever they like with invalid but well-formed documents, and they are free to show everything up to the point of the error for malformed documents.
You would if the C standard explicitly required compilers to do so.
The fact is, it doesn't make much sense to compare CSS to C. One is an imperative programming language, the other is a declarative style language. You can't miss out bits of a C program and still have it work right, but CSS is designed around the idea that you can do just that.
I don't want to include a CSS 3 property in my stylesheet only to have every CSS 2 browser simply throw everything away, I want them to apply the CSS 2 properties they do understand and ignore the bits they don't. Fortunately, this is exactly what the CSS specifications require, which is why the Acid2 test includes invalid code - it's testing this part of the specification.
It can definitely prove that something is non-compliant. But it cannot definitely prove that something is compliant. A hell of a lot of bugs only manifest themselves in unusual circumstances. Unless you have prior knowledge of these bugs, you'd have to be very lucky to coincidentally trigger them with a simple test case.
No, it can't. Suppose there are a hundred testcases for selectors and five testcases for a particular float configuration in wide use on the web. By adding support for more selectors, a Microsoft engineer might pass twenty more testcases, but introduce a regression causing them to fail the five really important float testcases. By your standards, this would be more compliant, even though it would be considered a disaster in terms of compliance.
It doesn't make sense to judge compliance by the number of testcases passed. There isn't a good way of assigning a particular number to how compliant an implementation is. But the real question is why should there be? Does anybody really gain anything by saying that Internet Explorer is 53% compliant instead of 52% compliant? Or does it make more sense to talk about particular bugs and particular features that are supported? I can see how the former might be of use if all you want is a number to criticise Microsoft with, but as a web developer, I can tell you that having a percentage just isn't useful in any way if you are genuinely concerned with practical matters and not political ones.
Do any other browser developers provide a running count of how many CSS testcases they pass and how many they fail?
Or he thinks the same as I do; that such numbers are unimportant and misleading.
Please do not spread this myth. It is simply not true. If you had actually read the Acid2 technical guide instead of relying on Slashdot hearsay, you would know this. From a previous comment of mine: