W3C home > Mailing lists > Public > public-css-testsuite@w3.org > September 2009

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 29 Sep 2009 03:42:13 +0200
Message-ID: <4AC165F5.3010906@xn--mlform-iua.no>
To: public-css-testsuite@w3.org
  Hi, Elika, here are some comments to the CSS Namespaces test suite [1] 
that you announced [2].

1. Link to other CSS namespace tests

  The "Selectors Level 3" draft contains several tests relating to CSS 
namespaces [http://w3.org/Style/CSS/Test/CSS3/Selectors/current/]. I 
believe that the CSS Namespaces test suite homepage could benefit from 
also linking to the namespace related tests within Selectors Level 3 
test suite, so that the test suite users may see things in context.  It 
is also a bit unclear how these two test suites differs w.r.t. namespace 
testing ..., but in posting this letter, I make the assumption that the 
issues I bring up are most related to the CSS namespaces test suite.


2. Tests of the universal selector are lacking.

  The CSS namespaces test suite doesn't contain any tests with the 
universal selector - there is only type selectors tested (and of the 
type selectors, I don't know if any of them are combined with attribute 
selectors etc.). When I say "universal selector", I have especially in 
mind universal selectors that omits the "*" - for example '[class]' or 
'.class' instead of '*[class]' and '*.class'.

  UAs generally support omitted '*' just fine, except - it turns out - 
when used with namespaces: current release of Firefox and Opera will 
then not even accept the selector as _valid_. As a consequence the "bar" 
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.


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.


4. @namespace syntax erros

  The @namespace error handling test 
[http://w3.org/Style/CSS/Test/CSS3/Namespace/current/syntax-013] only 
tests for error /after/ "@namespace". I discovered that Webkit seemed to 
accept this:  "*@namespace". Hence I propose adding a test that makes 
sure UAs ignore such and similar rules.


5. The XMLNS namespace, is it necessary to declare it?

   (This is also a question/comment about the CSS Namespaces draft.)

  'Namespaces in XML' explains that the XMLNS namespace must never be 
declared [http://w3.org/TR/REC-xml-names/#ns-decl]. And it seems logical 
to me that the this rule could be valid for CSS namespaces as well - for 
the following reasons:

   * Not having this restriction allows authors to e.g. declare the 
class attribute as a namespace attribute – I have tested it, and it 
works ... Feature of bug? Example:

     @namespace class\=\" "http://www.w3.org/2000/xmlns/";
     *[class\=\"|cal]{color:red}

   * In XML and HTML, recognizing other namespaces is depending on the 
pre-knowledge of xmlns.
   * In RDFa documents one must (or at least may) use namespaced 
attribute selectors in order to select  elements where RDFa prefixes are 
defined.  (For example: *[xmlns|dc]{color:red}). Having to declare the 
xmlns namespace leads to a good deal of gymnastics, in my view.

   Implementations:

   - UAs differs on this: Firefox does not require the XMLNS namespace 
to be declared via @namespace. Whereas Webkit and Opera requires it. 
[Though, even if Webkit requires the XMLNS namespace to be declared in 
order to _select_ the element, it still doesn't consider the very 
selector invalid if the XMLNS namespaes has been left undeclared. This 
is a bug/inconsistency - see point 8 below ...]
   - The CSS namespaces draft does not say that it is unnecessary. But 
it also doesn't give any examples that shows that it is necessary.
   - The CSS namespaces test suite does not demo the xmlns namespace 
declaration - and it never declares it, either - it seems. (But then 
again, the current test suite for the most part avoids "real" 
namespaces, such as XML, SVG and the like.)

   To do: Add tests for the xmlns namespace. And add text to the draft 
saying whether it is - or isn't - necessary to declare the xmlns 
namespace. (It appears to me logical that any declared XML, XHTM or HTML 
namespace automatically triggers the XMLNS namespace declaration - 
perhaps even the XML namespace should then be auto triggered, see point 6.)


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

   In the test I present in point 8 below, it turns out that Firefox 
treats the XML namespace the same way as it treats the XMLNS namespace. 
Namely, it doesn't require that you @namespace declare it. (Webkit also 
doesn't require this, but this seems to be due to the bug I touched 
briefly above - see more below.)


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

   According to Selectors Level 3,  a type selector, a universal 
selector or an attribute selector with an undeclared namespace prefix, 
becomes an invalid selector. And thus, even if there are other, correct 
selectors in the same rule, the entire rule must be treated as invalid. 
Example:

    undeclaredNS|*, element{/*the entire rule gets ignored*/}

  However, the test suite does not contain any tests which checks 
whether UAs _do_ invalidate the entire style rule. And, as a matter of 
fact, I discovered that Webkit - which I at first thought had better CSS 
namespace support than Firefox and Opera - does not invalidate such 
rules ... Se my test pages - point 8.


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ålform.no/testing/css-namespaces-html
    http://målform.no/testing/css-namespaces-xhtml


9. text/html namespace tests!

  The CSS Namespaces test suite only - I believe - tests XML documents. 
However, HTML 5 will ("officially") introduce namespaces (in some 
form(s)) to text/html as well. The UAs I tested showed that the same 
@namespace declared prefixes are _technically valid_ as *selectors* in 
both TEXT/HTML and in XHTML. The fact that a namespace selector cannot 
select anything in a TEXT/HTML document (since you currently cannot 
declare namespace prefixes there) doesn't affect the validity of the 
selector itself. Thus, one may (and I think I've found use cases for 
it...) declare namespaces even when the CSS is used in text/html.

  And yet, despite this, neither the Selectors Level 3 test suite nor 
the CSS namespaces test suite, seem to have a single 'text/html' page 
which tests namespaces in this way. Thus, I propose that the test suites 
are updated with text/xhtml tests.


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.


11. I offer my own test page to the test suite.

[1] http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/
[2] http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0016
-- 
leif halvard silli
Received on Tuesday, 29 September 2009 01:42:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 September 2010 17:51:58 GMT