Re: CSS3 selectors critique (WD-css3-selectors-20010126)

[ msg dbaron : comment for General Syntax module below... ]

Etan Wexler wrote:

>4. Selector syntax <http://www.w3.org/TR/css3-selectors/#selector-syntax>
>
>"A sequence of simple selectors is a chain of simple selectors that are 
>not separated by a combinator."
>
>This sequence was called "simple selector" in CSS2.  The shifting 
>terminology is confusing and unnecessary.
>
You are the first one ever to say so. Most people, and the WG itself, 
think it is seriously clarifying that section from css2 spec. From an 
implementor's point of view (I work on css parser in Mozilla/Netscape), 
the css2 spec was very confusing because absolutely everything was 
called a selector.

>"A simple selector is either a type selector, universal selector, 
>attribute selector, ID selector, content selector, pseudo-class."
>
>This is a redefinition of the CSS2 term "simple selector".  If the CSS3 
>selectors module instead used one of the terms "selector particle", 
>"selector atom", or "simple selector fragment", we could retain the CSS2 
>definition of "simple selector".  This, in turn, eliminates the ungainly 
>term "sequence of simple selectors".
>
Pseudo-elements are not considered to be simple selectors in css3. 
Simple selectors can be found an unlimited number of times in a 
selector. Not pseudo-elements.

>"Combinators are: whitespace, '>', '+' and '~'."
>
>The descendant combinator, noted here as whitespace, may be a series of 
>one or more comments with no whitespace.
>
No. I see what you mean :     FOO/*comment*/BAR. This is definitely not 
equivalent to FOO BAR but equivalent
to (there is no way to write it in CSS...) one single sequence of simple 
selectors containing two type element selectors. And therefore invalid.

>"The elements of the document tree represented by a selector are called 
>subjects of the selector."
>
>This can be taken to mean that for the selector "HTML BODY ADDRESS EM A", 
>a document may have subjects of element type 'HTML', subjects of element 
>type 'BODY', and so forth.  A better wording is, "The elements of the 
>document tree which match a selector are called subjects of the selector."
>
Definitely not. "Match" refers to CSS. Selectors specification deals 
with specs having nothing to do with CSS where they represent something 
else than a condition. Using "match" is then not desired.

>Change "rightmost" to "last".  This is a matter of 
>internationalization (internationalisation), of accessibility, and also of 
>plain good sense.  The CSS syntax is not tied to some visual presentation.
>
I could agree with that and will let WG decide about it.

>To be consistent with the previous item, change "represented" to "matched".
>
Again, no.

>7. Pseudo-elements <http://www.w3.org/TR/css3-selectors/#pseudo-elements>
>
>"For compatibility reasons with existing stylesheets, user agents must 
>also accept the one-colon previous notation. This compatibility is not 
>required for the new pseudo-elements introduced in CSS level 3."
>
>Can this be expressed in the formal grammar?
>
Extract from section 10.1 below. If you mean list in the formal grammar 
the pseudos for which single-colon notation is allowed, no.

   pseudoelement
      : [ ':' ]? ':' IDENT
      ;

>Why was this laxness introduced?  Is there a problem with mandating 
>acceptance of the single-colon notation?  Is there a problem with 
>mandating rejection of the single-colon notation?
>
(a) compatibility issues with legacy browsers (b) need to make the 
difference between pseudo-classes and pseudo-elements. The "::" notation 
is strongly recommended.

>9. Calculating a selector's specificity 
><http://www.w3.org/TR/css3-selectors/#specificity>
>
>The confusing explanation of specificity can be and should be avoided by 
>refusing to treat specificity as a single number.  There is no universal 
>numeric base for specificity, so a single-number specificity is 
>meaningless outside of a given cascade.  Specificity in CSS is an ordered 
>triplet, (a, b, c), and we should represent it as such.
>
>The confusion is infectious; read Rich in Style's interpretation, 
><http://www.richinstyle.com/bugs/mozilla.html#errors> item 22.
>
You are referring to a possible bug in an implementation to say the spec 
is wrong ?
Specificity is a triplet and should be sorted by lexicographic order of 
that triplet. Period. Everyone agrees on that.

>"selectors_group
>  : selector [ ',' S* selector ]*
>  ;"
>
>This does not permit whitespace between a selector and the comma that 
>follows it.  The whitespace might be specified in the 'selectors_group' 
>production or in the 'selector' production.
>
Good catch, thanks.

>"simple_selector_sequence
>  /* the universal selector is optional */
>  : [ type_selector | universal ]?
>        [ HASH | class | attrib | pseudoclass | negation ]+ |
>    type_selector | universal
>  ;"
>
>Is the universal selector optional in the grammar?  Is the universal 
>selector optional in the sense that its semantic is implied when one of [ 
>HASH | class | attrib | pseudoclass | negation ] is present?
>
See section 6.2.

>There is no definition of the 'negation' production.  It appears that the 
>'pseudoclass' production, through the 'functional_pseudo' production, is 
>attempting to encompass the work what would have belonged to the 
>'negation' production.
>
Absolutely. Negation pseudo is not the only one accepting arguments and 
I don't see it should be a special case.

>However, the lack of a 'negation' production prevents the 'negation_arg' 
>production from enforcing the prohibition on nested negation 
>pseudo-classes.  This prohibition is stated in a comment in the 
>'pseudoclass' production and in Section 6.6.7 "The negation pseudo-class".
>
Hmmmmmmm...... Issue brought to CSS WG.

>The prohibition on the use of a pseudo-element selector as an argument to 
>the negation pseudo-class is redundant.  The negation pseudo-class, by 
>its definition, takes a CSS3 simple selector as an argument.  A 
>pseudo-element selector is not a CSS3 simple selector and so must not be 
>used.
>
False argument, :not() is a pseudo-class and therefore a simple selector.

>10.2 Lexical scanner <http://www.w3.org/TR/css3-selectors/#lex>
>
>"{integer]               {return INTEGER;}"
>
>The closing square bracket should be a closing curly brace.
>
>'"^="                    (return PREFIXMATCH;)
>"$="                    (return SUFFIXMATCH;)
>"*="                    (return SUBSTRINGMATCH;)'
>
>The parentheses should be curly braces.
>
OH! Excellent catches !!!! Thanks.

>The 'expression' production is misnamed, introduces unnecessary token 
>types, breaks compatibility with CSS2, and possibly is wrong.
>
There is no compatibility required between the productions in css2 and 
Selectors grammar. Only the language compatibility matters.

>The sequence of an 'INTEGER' token without a minus sign followed by the 
>'IDENT' token "n" would occur only if a comment intervened.  Otherwise 
>(unless the general lexing has revolutionized since CSS2) the result will 
>be a single 'DIMENSION' token.
>
Yes, this is a good comment for the General Syntax module (mail directly 
Cc:ed to David Baron). Thanks.

>I suggest the following production.
>
>expression /* or 'positions' as the case may be */
>  :  unary_operator? INTEGER [ '*' 'n' [ unary_operator INTEGER ]? ]? | 'n'
>  ;
>
>I am wary of new token types and of grammars with alternatives or with 
>optional components.  Alternatives in CSS seem to be little more than 
>opportunities for misimplementation.  I favor cutting the 'odd' and 
>'even' arguments for this reason.  Perhaps we should further restrict 
>the production:
>
>expression /* or 'positions' as the case may be */
>  :  unary_operator? INTEGER '*' 'n' unary_operator INTEGER
>  ;
>
>Regarding the lexer as currently configured, why must the 'INTEGER' token 
>accept a sign?  To maintain compatibility with CSS2, 'INTEGER' must omit 
>the sign and relegate the sign to a separate token.
>
>How would the lexer ever return a 'SIGNED_INTEGER' token starting with "-" 
>or return an 'INTEGER' token?  The notation seems to show that 'NUMBER' 
>tokens would eliminate such possibilities.  If this is only my 
>misunderstanding of the Flex notation, an explanatory comment amidst the 
>Flex code would help.
>
You are right. In chronological order, we have worked on Selectors 
module a lot of time before the CSS3 General Syntax one. So this comment 
arrives right in time. Thanks.

Thanks again for your message.

</Daniel>, editor of the Selectors module

>

Received on Monday, 27 August 2001 22:44:05 UTC