- From: Arron Eicholz <Arron.Eicholz@microsoft.com>
- Date: Tue, 10 Mar 2009 13:59:10 -0700
- To: Sylvain Galineau <sylvaing@microsoft.com>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
> Sylvain Galineau wrote:
> > Anne Van Kesteren wrote:
> > You would fail a bunch of other tests if that was the case. The goal
> is
> > having a correct implementation of CSS, of course.
>
>
> We're not talking about other tests, we're talking about this one. My
> deficient implementation would pass David's proposal even though it is
> not dropping a rule that must be dropped, which is what the testcase is
> supposed to be verifying.
>
To be clear this test is not testing error handling about the rule being thrown out. It is testing matching of an invalid attribute with an invalid attribute selector. The only way to test that is to have invalid markup because you have to try and match. Error handling is handled by Chapter 4 cases. There are a couple of cases in Chapter 4 that test for rules being thrown out.
> > It's not really about being well-formed, it's about the test not
> making
> > that much sense given what CSS parsing already requires.
>
>
> If it's not about being well-formed, why are we having this thread ? :)
> Given these rules :
>
> p { color: green; }
> p, [1badAttr] { color: red; }
>
> The only way to ensure the entire second rule is dropped is to test
> both selectors in the group vs. testing one and assuming the other goes
> away with it because, well, if the UA can drop one then of course it's
> dropping the other also because duh, that's what the spec says it
> should do...
>
> Verifying the entire rule is dropped will require invalid markup
> though. If the latter is not an issue then let's fix this test as
> proposed and move on.
>
> Fwiw, I do agree with David that the current version only verifies that
> the element is not selected vs. verifying the rule has been dropped.
> His proposal does address this but is, imo, incomplete as long as it
> does not attempt to also select that invalid attribute.
>
Changing the case to have the above rules would make the case ambiguous. Hypothetically, if the text is red is it red because the 'p' matched or the [1badAttr] matched? You would still have to create a case(s) to verify which one matched. With this simple case you know which one matched or didn't match. Adding more rules to this case just complicates the case.
Sylvain did point out one issue with this case. What if you don't support attribute selectors at all? With the case as it is today the case would pass. This type of case should be handled by attribute-selector-001 and by the time you get to this case you should already know if you support attribute selectors. So testing that here would just complicate the case more than it needs to be.
I think we have gotten away from the real issue. The issue is how do we handle this and other cases that absolutely have to contain invalid markup? There will be a handful, there has to be to test all invalid scenarios.
Received on Tuesday, 10 March 2009 20:59:55 UTC