Re: [CSSWG] Release Candidate for CSS Namespaces Test Suite

Anne van Kesteren On 09-09-29 14.50:

> I'll look into this in more detail at some later point, but some thoughts  
> below for now.
> 
> On Tue, 29 Sep 2009 03:42:13 +0200, Leif Halvard Silli  
> <xn--mlform-iua@målform.no> wrote:
>> selector of the following rules gets ignored (since Firefox/Opera think  
>> the preceding selector is invalid):
>>
>>   *|[foo], bar{} *|.foo, bar{} *|#foo, bar{} *|:first-child, bar{}
>>
>>   Webkit and Chrome do not have the same error.
> 
> It's not an error.


I just argued, in a reply to Øyvind, that it is. It would be nice 
to know exactly why it is not an error - if it isn't one.

>> 3. Class selector tests are missing
>>    CSS 2.1 says [http://w3.org/TR/CSS21/selector#class-html]:
>>
>>   "UAs may apply selectors using the period (.) notation in XML  
>> documents if the UA has namespace specific knowledge that allows it to  
>> determine which attribute is the "class" attribute for the respective  
>> namespace."
>>
>>   With the advent of SVG in HTML 5, I suppose test cases for .class  
>> selectors would be welcome.
> 
> This has nothing to do with the @namespace construct.


If you want *.class{} to select an element inside a SVG file - or 
section, then it is useful to have a test that shows that

    svgNamespaceLinkedPrefix|*.class{}

works, no?

>> 5. The XMLNS namespace, is it necessary to declare it?
> 
> Yes. There's nothing in the CSS namespaces draft that suggests it is  
> special. CSS namespaces are independent of XML namespaces.


Ok. Do you then agree that tests that catches the error which 
Firefox is currently having, is needed?

>> 6. The XML namespace, is it necessary to declare it via @namespace?
> 
> Yes.


Same note as above: do you agree that tests that catches the 
Firefox error is needed?

>> 7. Testing whether UAs invalidate the entire rule if it contains  
>> undeclared prefixes

    [snip]

> We should add this, agreed.


Good

>> 8. My own tests: Selector validity test
>>
>>   I have created an XHTML page – and a text/html "representation" of the  
>> same page – that solely and only tests what namespace selectors UAs  
>> consider as valid - the test are the basis for most of what I've said in  
>> this e-mail:
>>
>>     http://m%E5lform.no/testing/css-namespaces-html
>>     http://m%E5lform.no/testing/css-namespaces-xhtml
> 
> You mean
> 
>    http://m%C3%A5lform.no/testing/css-namespaces-html
>    http://m%C3%A5lform.no/testing/css-namespaces-xhtml


I can assure you that I wrote an "å" (&aring;) and not "%C3%A5" 
nor "%E5".  It is the user agent's and the OS's task to convert it 
into punycode after you have clicked the URL. I've experienced 
trouble with this myself, though. Based on that experience, 
chances are that either your mail client or your OS might be 
helping you too much, too little or not enough ...

Anyone: you can use 'malform.no' instead.

 
> It would be nice if they could be made more in the style of the current  
> test suite. 


OK, I could probably do that. (Though it also has some advantages 
to see everything in one page.)

> In addition, the errors pointed out need to be fixed.


So far there were only one direct claim about errors. I'd be happy 
to fix that one, once it is clear that it is an error.

>> 9. text/html namespace tests!
> 
> Since HTML5 is far away and it is not strictly needed I'd rather avoid  
> testing this for now and assume it will work down the road given that the  
> DOM model is identical.


Well, I would argue the opposite - and I would not mix HTML 5 into 
the issue at all (even if I perhaps did ...):

   * In order to prove that CSS @namespace is completely unrelated 
to the namespaces of the host language, it would be useful to have 
tests for text/html. Text/html is here today.
   * Also, I guess one may already link the same CSS file to both 
XHTML and HTML - and SVG etc - files. So it is already relevant.

It is also very simple: The two tests pages I made are identical 
(except for one line of info in the start) - they are just served 
differently.  I guess you don't say no thanks, if I offer them ...

>> 10. Positive tests.
>>
>>   I also suggest that the test suite is updated with more "positive"  
>> tests that are related to actual and common use cases, such SVG, XML,  
>> RDFa etc. The suite is currently dominated by many edge cases now, I  
>> think. Had the tests been more geared towards testing the W3 registered  
>> namespaces, then I believe that, for instance, the XMLNS namespace issue  
>> and the XML namespace issue that I describe in point 6 and 7 above,  
>> would have been discovered.
> 
> They are not considered issues. (Though the inconsistencies in  
> implementations are.) Feel free to contribute "positive" tests.


I'll see what I can do - as time passes on ...

>> 11. I offer my own test page to the test suite.
> 
> Cool, can you make them more like the existing tests?

As I said, I will try to.
-- 
leif halvard silli

Received on Tuesday, 29 September 2009 14:03:52 UTC