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

Daniel Glazman and I entered into discussion:

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

Respectfully, how do you know what most people think of this passage?  
Have you received much mail to that effect?  If so, I grudgingly defer 
to the masses.  If not, please consider my complaint.

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

CSS2 may have overloaded the term "selector", but its term "simple 
selector" had a clear definition that the CSS3 Selectors module is now 
changing.  I'm all for clarifying CSS2 (a CSS2.1 is still due us...) 
but why must clarification come at the expense of easily maintained 
continuity?

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

Ah, so all CSS3 sequences of simple selectors are CSS2 simple 
selectors, but not vice versa.

Even so, why change the meaning of "simple selector"?  If we use the 
term "selector particle", we then get "sequence of selector 
particles", no more cumbersome than the current "sequence of simple 
selectors".

>>"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 formal grammar for the Selectors module, as in CSS2, permits a 
combinator that consists of zero characters:

combinator
  : S* [ '+' | '>' | '~' | /* empty */ ] S*
  ;

The key is "/*empty*/".  If the prose saying "whitespace" is 
normative, change the grammar:

combinator
   : S* [ '+' | '>' | '~' | S ] S*
  ;

I find that CSS2 also suffers from a mismatch between its prose 
("whitespace") and its grammar ("/*empty*/").

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

Gee, I thought we were discussing 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.

I am having trouble understanding.  Can you offer an example where 
"represent" is better than "match"?

CSS2 section 5.2 states that "The elements of the document tree that 
match a selector are called subjects of the selector."  The Selectors 
module echos this in its abstract, stating that "To bind style 
properties to elements in the document, [CSS] uses selectors, which 
are patterns that match to elements."  There's that word "match" again.

>>"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?
>>
> ... If you mean list in the formal grammar 
> the pseudos for which single-colon notation is allowed, no.

That is what I meant.

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

Please tell me whether I understand: the laxness is present to 
provide compatibility, but authors are strongly encouraged to break 
that compatibility.  Regardless, I do not understand the necessity of 
the double-colon notation.   

> You are referring to a possible bug in an implementation to say the 
spec 
> is wrong ?

Heavens to Betsy, no!

> Specificity is a triplet and should be sorted by lexicographic order 
of 
> that triplet. Period. Everyone agrees on that.

You and I and probably everyone in the working group agree on that, 
but, apparently, some people with an otherwise sound knowledge of CSS 
have misunderstood specificity.  This confusion and the wording which 
caused it are the problems.

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

I had read section 6.2 and now have reread it.  I conclude that the 
universal selector is optional only in the sense that its semantic is 
implied when one of [ HASH | class | attrib | pseudoclass | negation ] 
is present.  The prose explains this and the grammar itself is clear.  
The comment in the grammar adds nothing useful and should perish.

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

Then let us amend the 'simple_selector_sequence' production to remove 
the reference to the nonexistent 'negation' production.

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

Changing the productions impairs the compatibility of the languages.

-- 
Etan Wexler

Received on Wednesday, 29 August 2001 22:49:28 UTC