[selectors] some inconsistent concepts and descriptions

[wargrey]

https://drafts.csswg.org/selectors/#syntax
https://drafts.csswg.org/selectors/#simple
https://drafts.csswg.org/selectors/#grammar

• Are pseudo elements simple elements?

Pseudo-elements do not exist independently in the tree: they are always bound to another element on the page, called their originating element.
Syntactically, a pseudo-element immediately follows the compound selector representing its originating element. If this compound selector is omitted, it is assumed to be the universal selector *.

Only the grammar defines pseudo elements are simple elements, this is okay syntactically. Also, is it only one pseudo element that can be attached to the originating element? If it is not, do they share the same originating element(rather than, say, the 2nd one is the originating element of the 3rd one)?

• Pseudo classes must follow the elemental selector if present.

This change is not mentioned in the grammar section.

[SelenIT]

I agree that order of the simple selectors in the compound selector is sometimes meaningful and the grammar should reflect it. For example, is [href]a (instead of more usual a[href]) a valid selector? Maybe the grammar should be clear that type selector is a rather 'special' sort of a simple selector and, if present, should always come first in the compound selector (and, obviuosly, be the only one)?

Maybe the definition of the compound selector chould be changed from <simple-selector>+ to something like this?

<compound-selector> = <type-selector>
                    [ <id-selector> | <class-selector> | <attribute-selector> |
                      <pseudo-class-selector> | <pseudo-element-selector> ]*
                    |
                    [ <id-selector> | <class-selector> | <attribute-selector> |
                      <pseudo-class-selector> | <pseudo-element-selector> ]+

And one more question about pseudo elements: the spec currently explicitly allows pseudo-classing for some pseudo-elements (and this is widely supported in browsers, e.g. in form of ::selection:window-inactive or ::-moz-range-track:hover), but does it prohibit pseudo-elements with classes (e.g. ::after.test)? The existing grammar seems to allow it, and at least Safari 9+ (unlike other browsers) considers such selectors as valid (codepen example). But do these selectors make any sense?

@fantasai, @tabatkins, could you please clarify this a bit?

[fantasai]

OK, I've tightened up the grammar:

• Type selector is only allowed as the first part of a compound selector.
• Pseudo-elements can follow any simple selectors, but can only be followed by other pseudo-elements and pseudo-classes.
• Removed pseudo-elements from the <simple-selector> production, consistent with the definition of “simple selector”.
• Made whitespace restrictions more comprehensive in the notes following the grammar.

@wargrey , @SelenIT , @dbaron Would you mind reviewing and letting me know if things look good now, or if anything further needs adjustment?

[SelenIT]

For me, everything looks clear and consistent now. Maybe only the <complex-selector> definition can be further shortened to <compound-selector> <relative-selector>*?

[fantasai]

I'd have to rewrite <relative-selector>, too, to avoid an infinite loop there. ;) It would be

<complex-selector> = <compound-selector> <relative-selector>*
<relative-selector> = [ <combinator>? <compound-selector> ]+

instead of

<complex-selector> = <compound-selector> [ <combinator>? <compound-selector> ]*
<relative-selector> = <combinator>? <complex-selector>

Upside is it's slightly simpler grammar, downside I guess is that <complex-selector> is a more fundamental concept in CSS. I don't have a strong opinion either way. @dbaron / @tabatkins ?

[tabatkins]

Yeah, whether you write complex-selector in terms of relative-selectors, or vice versa, is an arbitrary choice. Because complex selectors are a more fundamental concept, I chose to base relative-selector off of complex-selector - in the spec, we don't talk about complex selectors as being built out of relative selectors, a relative selector is just a special type of complex selector that starts with a combinator.

---

Your edits otherwise look fine, @fantasai. None of them were necessary - the additional conditions at the end covered things just fine - but moving them into the grammar works just as well.

[fantasai]

People get less confused when easily grammar-representable restrictions are represented in the grammar. :) (Imho the opposite is true if the grammar becomes overly convoluted, but it doesn't here.)

[css-meeting-bot]

The Working Group just discussed [selectors] some inconsistent concepts and descriptions, and agreed to the following resolutions:

• RESOLVED: Accept the proposed changes outlined here: https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902

The full IRC log of that discussion

<dael> Topic: [selectors] some inconsistent concepts and descriptions
<dael> github: https://github.com//issues/386
<dael> fantasai: Request to review some changes to selector grammer which are outlined in a comment.
<fantasai> https://github.com//issues/386#issuecomment-354649902
<dael> fantasai: What I did was put the restriction on type selectors and psuedo elments into the grammar rather than just the prose. I wanted to check if there were concerns.
<fantasai> * ordering thereof
<dael> Rossen_: I don't believe we, Edge, have an issue on this. I think we briefly discussed and it should be fine.
<dael> Rossen_: Seemed TabAtkins was also saying he's fine.
<dael> fantasai: I believe it should make no difference to impl. If you dn't understand a selector you have to throw it out wither it's ordering or not, but I wanted to check if it's okay to put in grammar.
<dael> Rossen_: sgtm. Obj?
<dael> RESOLVED: Accept the proposed changes outlined here: https://github.com//issues/386#issuecomment-354649902