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

[Leif Halvard Silli-4]

  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

[Øyvind Stenhaug]

On Tue, 29 Sep 2009 03:42:13 +0200, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:

>   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{}

These "foo" constructs don't seem to be allowed by the Selectors grammar  
(<http://www.w3.org/TR/css3-selectors/#w3cselgrammar>).

--
Øyvind Stenhaug
Core Norway, Opera Software ASA

[Anne van Kesteren-2]

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.

> 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.


> 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.

That makes sense.


> 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.


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

Yes.

> 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.

We should add this, agreed.


> 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

It would be nice if they could be made more in the style of the current  
test suite. In addition, the errors pointed out need to be fixed.


> 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.


> 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.


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

Cool, can you make them more like the existing tests?


> [1] http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/
> [2] http://lists.w3.org/Archives/Public/public-css-testsuite/2009Feb/0016


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

[Leif Halvard Silli-4]

Øyvind Stenhaug On 09-09-29 12.04:

> On Tue, 29 Sep 2009 03:42:13 +0200, Leif Halvard Silli  
> <xn--mlform-iua@målform.no> wrote:
>
>>   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{}
>
> These "foo" constructs don't seem to be allowed by the Selectors grammar  
> (<http://www.w3.org/TR/css3-selectors/#w3cselgrammar>).

   In pointing to that grammar, do you then refer to the following
3 lines - or do you also refer to something more than that in that
grammar? The 3 lines:

     universal
       : [ namespace_prefix ]? '*'
       ;

   If this is all you refer to, then please note that the
[namespace_prefix] is a 0 or 1 option. And that there are no
special rules defined here w.r.t. whether there is - or isn't - a
namespace prefix. Thus, if these 3 lines are all that you refer
to, and if your reading of the rule is correct, then we would also
have to conclude that the following example, which is based on an
example from the Universal selector section - and which the draft
  directly says is _legal_ [see below], actually is illegal:

   [hreflang|=en]{color:lime}

   And thus, if this is the case - if the grammar says that this
rule is wrong, then the grammar is not in tune with the prose of
the draft - or with common implementations either.


Let me go through what the prose says:

   The prose says
[http://w3.org/TR/css3-selectors/#universal-selector]:

     "If the universal selector is not the only component of
      a sequence of simple selectors, the * may be omitted."

     Examples:

     *[hreflang|=en] and [hreflang|=en] are equivalent,
     [ snip ]

   The logical conclusion to this is that [hreflang|=en] is - in
fact - a universal selector. Because, according to CSS 2.1, every
simple selector is either a universal selector or type selector
[http://w3.org/TR/CSS21/selector.html#selector-syntax].

   The next section of CSS3 selectors talks about universal
selectors and namespaces
[http://w3.org/TR/css3-selectors/#univnmsp]. All of the examples
in that section types the "*" directly - but we cannot conclude
from that, that the "*" _has_ to be typed directly.

   Here are the example section in full:

     ns|* all elements in namespace ns
      *|* all elements
       |* all elements without a namespace
        * if no default namespace has been specified, this
          is equivalent to *|*. Otherwise it is equivalent
          to ns|* where ns is the default namespace.

   Here it is said that "*" is equivalent to "*|*". The logical
conclusion is "*|*" and "*" are equivalent also when the universal
selector is omitted.

   Thus it is logical that *|*[hreflang|=en] and *|[hreflang|=en]
are equivalent with *[hreflang|=en]' and [hreflang|=en] - see the
first example that I quoted.

   Further below, the draft speaks about attribute selectors,
including namespaces and attribute selectors
[http://w3.org/TR/css3-selectors/#attrnmsp].  Here the draft *does
not* discuss *|[attr]. Instead it discusses [ns|attr]. This, if
you ask me, confirms that a lone [attr] is a legal, universal
selector also when it is written as *|[attr].

   The Selectors Level 3 draft could need an update that makes
clear that it is permitted to write *|[attr] (or that directly
forbids it, if that should become the solution - I hope not, and
see no reason to do it - on the contrary [more on that later, if
need be ...]).

   All this confirms that it is correct to warn against omitting
the "*", as I believe Selectors Level 3 does. But it also points
to a language problem: When the draft speaks about attribute
selectors, then it does - in one way - actually speak about
universal and/or type selectors. Perhaps the draft should say
that, whenever an attribute selector is not attached to a type
selector or to the "*", then it represents - in fact - a universal
selector.
--
leif halvard silli

[Anne van Kesteren-2]

On Tue, 29 Sep 2009 15:11:39 +0200, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:
>    In pointing to that grammar, do you then refer to the following 3  
> lines - or do you also refer to something more than that in that  
> grammar? The 3 lines:
>
>      universal
>        : [ namespace_prefix ]? '*'
>        ;

The point of these lines is that the namespace_prefix is tied to the *. If  
you omit the * you cannot use the namespace_prefix.

>    If this is all you refer to, then please note that the  
> [namespace_prefix] is a 0 or 1 option. And that there are no special  
> rules defined here w.r.t. whether there is - or isn't - a namespace  
> prefix. Thus, if these 3 lines are all that you refer to, and if your  
> reading of the rule is correct, then we would also have to conclude that  
> the following example, which is based on an example from the Universal  
> selector section - and which the draft   directly says is _legal_ [see  
> below], actually is illegal:
>
>    [hreflang|=en]{color:lime}
>
>    And thus, if this is the case - if the grammar says that this rule is  
> wrong, then the grammar is not in tune with the prose of the draft - or  
> with common implementations either.

The grammar does allow this and the prose does too. See the  
simple_selector_sequence production.

> Let me go through what the prose says:
>
>    The prose says [http://w3.org/TR/css3-selectors/#universal-selector]:
>
>      "If the universal selector is not the only component of
>       a sequence of simple selectors, the * may be omitted."
>
>      Examples:
>
>      *[hreflang|=en] and [hreflang|=en] are equivalent,
>      [ snip ]
>
>    The logical conclusion to this is that [hreflang|=en] is - in fact -  
> a universal selector. Because, according to CSS 2.1, every simple  
> selector is either a universal selector or type selector  
> [http://w3.org/TR/CSS21/selector.html#selector-syntax].

Please read it all: "The universal selector, written as an asterisk (*  
U+002A), represents the qualified name of any element type." It is not  
needed for the non-namespace cases.

>    The next section of CSS3 selectors talks about universal selectors  
> and namespaces [http://w3.org/TR/css3-selectors/#univnmsp]. All of the  
> examples in that section types the "*" directly - but we cannot conclude  
> from that, that the "*" _has_ to be typed directly.
>
>    Here are the example section in full:
>
>      ns|* all elements in namespace ns
>       *|* all elements
>        |* all elements without a namespace
>         * if no default namespace has been specified, this
>           is equivalent to *|*. Otherwise it is equivalent
>           to ns|* where ns is the default namespace.
>
>    Here it is said that "*" is equivalent to "*|*". The logical  
> conclusion is "*|*" and "*" are equivalent also when the universal  
> selector is omitted.

No, that is reading between the lines. (And contrary to the grammar.) Your  
further examples seem all along the same lines of not reading the  
specification literally and trying to infer things that are not there.



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

[Anne van Kesteren-2]

On Tue, 29 Sep 2009 15:11:39 +0200, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:
> [...]

Also, this is the wrong list for asking Selectors to be clarified.  
www-style@... is much more suited.


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

[Leif Halvard Silli-4]

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 "å" (å) 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

[Anne van Kesteren-2]

On Tue, 29 Sep 2009 16:03:06 +0200, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:
> 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.

It is not an error per the grammar or the prose of Selectors. Such rules  
need to be rejected.


>>  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?

Ah, I thought you meant something else. I suppose we could add that, yes.


>>> 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?

Sure, if you contribute one.


>>> 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?

Sure.


> I can assure you that I wrote an "å" (å) 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.

Yeah, it seems to be my email client. Annoying.

>>> 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 ...

Since the requirements of namespaces in the HTML DOM are changing between  
HTML4 and HTML5 and user agents are somewhere in middle collectively it  
seems unwise to test this until the new approach is fully done. The new  
approach happens to be named HTML5.


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

[Leif Halvard Silli-4]

Anne van Kesteren On 09-09-29 15.24:

> On Tue, 29 Sep 2009 15:11:39 +0200, Leif Halvard Silli :
>>    In pointing to that grammar, do you then refer to the following 3  
>> lines - or do you also refer to something more than that in that  
>> grammar? The 3 lines:
>>
>>      universal
>>        : [ namespace_prefix ]? '*'
>>        ;
>
> The point of these lines is that the namespace_prefix is tied to the *. If  
> you omit the * you cannot use the namespace_prefix.

My view is not interesting. I was just testing UA.

In Webkit the above is simply interpreted to say that we cannot do
this:  ns|{}.  Webkit did not interpret it as saying that one
cannot do this:  ns|[attr]{}.

   [...]

Regarding omitting the '*':

> The grammar does allow this and the prose does too. See the  

> simple_selector_sequence production.


simple_selector_sequence
   : [ type_selector | universal ]
     [ HASH | class | attrib | pseudo | negation ]*
   | [ HASH | class | attrib | pseudo | negation ]+
   ;

If the "*" at the end of line 3 there pertain to both line 2 and 3
(right?), then I agree that the grammar cover this. Thanks!

But then, I would also say that it is silly that CSS 3 has
copy-pasted this sentence from CSS 21:

"If the universal selector is not the only component of a sequence
of simple selectors, the * may be omitted."

(The only difference being that 'simple selector' has been
replaced by 'a sequence of simple selectors'.)

Rather than saying that "the * may be omitted", it should say that
the 'universal selector' may be dropped. (Or else it could just as
well have said that the type selector could have been dropped - as
the grammar in fact show you can - of course it may then select
other elements.)

This focus on the character '*' makes it seem as if there is a
shorthand for the universal selector - namely to drop it.

My point is: The reason one may, in some cases, drop the '*' is
because one may be certain that the selector sequence will still
select the very same thing - you get the same result. Despite that
in dropping it, it becomes another kind of selector sequence.

>> Let me go through what the prose says:
>>
>>    The prose says [http://w3.org/TR/css3-selectors/#universal-selector]:
>>
>>      "If the universal selector is not the only component of
>>       a sequence of simple selectors, the * may be omitted."
>>
>>      Examples:
>>
>>      *[hreflang|=en] and [hreflang|=en] are equivalent,
>>      [ snip ]
>>
>>    The logical conclusion to this is that [hreflang|=en] is - in fact -  
>> a universal selector. Because, according to CSS 2.1, every simple  
>> selector is either a universal selector or type selector  
>> [http://w3.org/TR/CSS21/selector.html#selector-syntax].
>
> Please read it all: "The universal selector, written as an asterisk (*  
> U+002A), represents the qualified name of any element type." It is not  
> needed for the non-namespace cases.

What do you mean by 'non-namespace cases'? *|*{} is also a
non-namespace case.

>>    The next section of CSS3 selectors talks about universal selectors  
>> and namespaces [http://w3.org/TR/css3-selectors/#univnmsp]. All of the  
>> examples in that section types the "*" directly - but we cannot conclude  
>> from that, that the "*" _has_ to be typed directly.
>>
>>    Here are the example section in full:
>>
>>      ns|* all elements in namespace ns
>>       *|* all elements
>>        |* all elements without a namespace
>>         * if no default namespace has been specified, this
>>           is equivalent to *|*. Otherwise it is equivalent
>>           to ns|* where ns is the default namespace.
>>
>>    Here it is said that "*" is equivalent to "*|*". The logical  
>> conclusion is "*|*" and "*" are equivalent also when the universal  
>> selector is omitted.
>
> No, that is reading between the lines. (And contrary to the grammar.) Your  
> further examples seem all along the same lines of not reading the  
> specification literally and trying to infer things that are not there.

It is not reading between the line, it is reading while being
inspired by CSS21. In CSS21 every 'simple selector' - or as CSS3
puts it, every 'simple selector sequence', is said to be either a
type selector or a universal selector:

"A simple selector is either a type selector or universal selector
followed immediately by zero or more attribute selectors, ID
selectors, or pseudo-classes, in any order."

http://www.w3.org/TR/CSS21/selector#selector-syntax

It follows, from CSS21, that even if you omit the *, you are still
dealing with either a type selector or a universal selector.
--
leif halvard silli

[Leif Halvard Silli-4]

Anne van Kesteren On 09-09-29 15.26:

> On Tue, 29 Sep 2009 15:11:39 +0200, Leif Halvard Silli  
> <xn--mlform-iua@målform.no> wrote:
>> [...]
>
> Also, this is the wrong list for asking Selectors to be clarified.  
> www-style@... is much more suited.


Good point.
--
lh

[Boris Zbarsky]

On 9/29/09 11:57 AM, Leif Halvard Silli wrote:
> It is not reading between the line, it is reading while being inspired
> by CSS21. In CSS21 every 'simple selector' - or as CSS3 puts it, every
> 'simple selector sequence', is said to be either a type selector or a
> universal selector:

I'm not following this.  Why are we using definitions and concepts from
one specification to "interpret" another specification, which uses quite
different definitions and concepts?

-Boris

[Anne van Kesteren-2]

On Tue, 29 Sep 2009 17:57:22 +0200, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:
> Anne van Kesteren On 09-09-29 15.24:
>>  The point of these lines is that the namespace_prefix is tied to the  
>> *. If  you omit the * you cannot use the namespace_prefix.
>
> My view is not interesting. I was just testing UA.
>
> In Webkit the above is simply interpreted to say that we cannot do  
> this:  ns|{}.  Webkit did not interpret it as saying that one cannot do  
> this:  ns|[attr]{}.

Bug in WebKit.


> [...]
>
> Rather than saying that "the * may be omitted", it should say that the  
> 'universal selector' may be dropped. (Or else it could just as well have  
> said that the type selector could have been dropped - as the grammar in  
> fact show you can - of course it may then select other elements.)
>
> This focus on the character '*' makes it seem as if there is a shorthand  
> for the universal selector - namely to drop it.

The specification could be clearer I suppose.


> What do you mean by 'non-namespace cases'? *|*{} is also a non-namespace  
> case.

I mean non-vertical bar cases then. The Selectors specification agrees  
with how put it, but if you want to view things in a rather different way  
I suppose non-vertical bar cases work.


>> No, that is reading between the lines. (And contrary to the grammar.)  
>> Your  further examples seem all along the same lines of not reading  
>> the  specification literally and trying to infer things that are not  
>> there.
>
> It is not reading between the line, it is reading while being inspired  
> by CSS21.

That is called reading between the lines.


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

[Leif Halvard Silli-4]

Anne van Kesteren On 09-09-29 16.18:

> On Tue, 29 Sep 2009 16:03:06 +0200, Leif Halvard Silli :
>> 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.
>
> It is not an error per the grammar or the prose of Selectors. Such rules  
> need to be rejected.


See the other "subthread".

>>>  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?
>
> Ah, I thought you meant something else. I suppose we could add that, yes.


I guess I changed my goal during the discussion ...

>>>> 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?
>
> Sure, if you contribute one.


Fine.

>>>> 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?
>
> Sure.


Fine.

>>>> 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 ...
>
> Since the requirements of namespaces in the HTML DOM are changing between  
> HTML4 and HTML5 and user agents are somewhere in middle collectively it  
> seems unwise to test this until the new approach is fully done. The new  
> approach happens to be named HTML5.

For tests which only seek to see whether selector sequences are
considered valid by the UA - independently of the host language, I
cannot see that HTML 5 matters.

However, I agree that testing whether a "namespaced selector
sequence" actually matches anything inside a text/html document,
should not start, yet.
--
leif halvard silli

[Leif Halvard Silli-4]

Boris Zbarsky On 09-09-29 18.02:

> On 9/29/09 11:57 AM, Leif Halvard Silli wrote:
>> It is not reading between the line, it is reading while being inspired
>> by CSS21. In CSS21 every 'simple selector' - or as CSS3 puts it, every
>> 'simple selector sequence', is said to be either a type selector or a
>> universal selector:
>
> I'm not following this.  Why are we using definitions and concepts from
> one specification to "interpret" another specification, which uses quite
> different definitions and concepts?


Because this sentence in CSS 3 Selectors,

   "If the universal selector is not the only component of a
sequence of simple selectors, the * may be omitted"

which is lifted directly out of CSS 2.1, offer us too little
friction against thinking along the lines defined in CSS 2.1.

The test suite of CSS Selectors Level 3 consequently uses the
wording "omitted universal selector".[1][2][3] It doesn't simply
say "omitted *", as the draft does. Do you agree that CSS
Selectors Level 3 should say the same thing?

Here is a text proposal:

   "If the universal selector is not the only component of a
sequence of simple selectors and if it also is without the
namespace component, then the universal selector may be omitted."

[1] http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/xhtml/
[2] http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/
[3] http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/xml/
--
leif halvard silli

[Leif Halvard Silli-4]

Anne van Kesteren On 09-09-29 18.07:

> On Tue, 29 Sep 2009 17:57:22 +0200, Leif Halvard Silli  
>> Anne van Kesteren On 09-09-29 15.24:



>> This focus on the character '*' makes it seem as if there is a shorthand  
>> for the universal selector - namely to drop it.
>
> The specification could be clearer I suppose.


1+

[...]

>>> No, that is reading between the lines. (And contrary to the grammar.)  
>>> Your  further examples seem all along the same lines of not reading  
>>> the  specification literally and trying to infer things that are not  
>>> there.
>> It is not reading between the line, it is reading while being inspired  
>> by CSS21.
>
> That is called reading between the lines.


It is called something else. But the interesting thing is whether
the draft is literal enough or if it "could be clearer".
--
leif halvard silli

[Boris Zbarsky]

On 9/29/09 1:58 PM, Leif Halvard Silli wrote:
> Here is a text proposal:
>
> "If the universal selector is not the only component of a sequence of
> simple selectors and if it also is without the namespace component, then
> the universal selector may be omitted."

This sounds fine to me, though not strictly necessary.  The "universal
selector" is not '*' in Selectors but "an optional namespace component
followed by '*'".  Which means that while you can omit the whole thing,
you can't just omit the '*' and include the namespace component,
Webkit's behavior to the contrary notwithstanding.

-Boris

[Leif Halvard Silli-4]

Boris Zbarsky On 09-09-30 00.32:

> On 9/29/09 1:58 PM, Leif Halvard Silli wrote:
>> Here is a text proposal:
>>
>> "If the universal selector is not the only component of a sequence of
>> simple selectors and if it also is without the namespace component, then
>> the universal selector may be omitted."
>
> This sounds fine to me, though not strictly necessary.  The "universal
> selector" is not '*' in Selectors but "an optional namespace component
> followed by '*'".

And that is why I said "and if it [the universal selector] is
without the namespace component". The draft: "an optional
namespace component is now allowed in element type selectors, the
universal selector and attribute selectors".[*] Given the selector
sequence 'dc|*[attr]', then dropping the universal selector (dc|*)
would be risky. What is the not strictly necessary that I said?

>  Which means that while you can omit the whole thing,
> you can't just omit the '*' and include the namespace component,
> Webkit's behavior to the contrary notwithstanding.


   What seems strictly necessary is to better the CSS 3 Selectors
text which, by quoting CSS21, is focusing on the "*" character:

"If the universal selector is not the only component of a sequence
of simple selectors, the * may be omitted."

  That appears tautological and only means you can't drop the '*'
here: *{}. With a kind reading, it also means that you can't drop
the second '*' here: *|*{}. If you do not have enough baggage,
then it means that you can drop the second "*" here: *|*{}. If you
have too much CSS 21 baggage then it means that you can drop the
second '*' here: *|*[attr].

   Now, you formulated the question: when can we drop the
universal selector? However, perhaps the question that CSS 3
Selectors tries to answer in that sentence is when we can drop the
'*'? (Which is when dropping is guaranteed to not affect the
selection.) If so, then the text could be reformulated e.g. like this:

"When the * character is the only component of the universal
selector, except when the universal selector is the only simple
selector in the sequence, then the universal selector may be
omitted from the simple selectors sequence.

[*] The draft speaks of the namespace component as an optional
component of the simple selectors components: a component of a
component. http://www.w3.org/TR/css3-selectors/#changesFromCSS2
--
leif halvard silli