Re: attribute-value-selector-004.xht not well formed

On Tue, 10 Mar 2009 23:44:57 -0000, Sylvain Galineau  
<sylvaing@microsoft.com> wrote:
>> The testcase is however not about testing whether the cascade is done
>> correctly. You seem to conflate the two. (At least as far as your
>> deficient implementation is concerned.)
>
> You're absolutely right but it cuts both ways: if this test case should  
> not be about testing the cascade then why should it be about testing  
> error handling ?

Because not matching [1badattr] is dealt with at the error handling level  
and nowhere else.


>> I don't see why it requires invalid markup or any additional markup
>> other than <p> really. [1badattr] will be dropped regardless of what the
>> markup specifies.
>
> We're not verifying whether p is selected or not. We're verifying that  
> [1badAttr] does not select anything. It's not about checking whether the  
> rule is dropped or why. This is a Chapter 5 test, not Chapter 4.  
> Regardless, testing p alone is still not sufficient in order to assert  
> the *entire* proposed rule was dropped since it groups two selectors.  
> Both of them should be checked and I don't see how that could be done  
> without an invalid attribute in the markup. But as Arron reminded me,  
> that is not relevant here since we're not testing CSS parsing and error  
> handling here. Only selection.

That [1badattr] does not select anything follows from parsing, not  
selection. I.e. you would be able to select a 1badattr attribute if you  
use CSS escapes.


>> I don't see how that changes the scenario. The mere presence of
>> attributes does not influence the parsing of CSS.
>
> Nobody said they did. But nobody said this test was about validating CSS  
> parsing either. The test case wants to show that [1badAttr] does not  
> select anything. No more, no less.
>
> You want to do it by selecting a p element in a way that causes  
> [1badAttr] to be ignored if and only if the UA implements CSS error  
> handling correctly. But we do not need such a dependency since error  
> handling is tested elsewhere. There is no need to add assumptions about  
> proper error handling, or even correct support of selector grouping e.g.  
> my deficient code might toss the rule because it thinks "p,[1badAttr]"  
> is the IDENT and believes the comma to be the problem. This testcase  
> simply intends to verify that [1badAttr] is not applied and nothing  
> else. (The 'nothing else' may be key in order to understand Arron's  
> intent, I think).
>
> These test cases make as few assumptions as possible wrt the number of  
> features a UA needs to implement correctly in order to pass them. The  
> fewer the assumptions, the lower the odds of false positives on any  
> given test (imo).

I don't see it. You're still testing CSS parsing as far as I can tell, but  
you're just less upfront about it. If this was really about selection  
tests only I think you should not include rules that are thrown out due to  
syntax errors. Those can be moved to the syntax section.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 11 March 2009 09:08:14 UTC