Chrome/FF seems to parse :before#id or :before.class as invalid (instead of valid and matching nothing) but I do not see on which part of the spec this is based.
Pseudo-elements are featureless, and so can’t be matched by any other selector
This does not make them invalid.
Legacy : pseudo-element syntax is defined in <subclass-selector> as a <pseudo-class-selector>.
<compound-selector> = [ <type-selector>? <subclass-selector>* [ <pseudo-element-selector> <pseudo-class-selector>* ]* ]!
Subclass selectors can appear in any order while still selecting the same set of elements, but this is not true for a pseudo-element specified with the legacy single : syntax.
Therefore I assume that :before must be handled as if it has been specified with ::before and matched <pseudo-element-selector>. If so, it may be helpfull to define it in the spec.
A similar confusion occurred to me when parsing a <color-stop-list>, whose syntax requires two color stops but its grammar accepts an implicit color stop defining two stops with the same color.
Chrome/FF seems to parse
:before#idor:before.classas invalid (instead of valid and matching nothing) but I do not see on which part of the spec this is based.This does not make them invalid.
Legacy
:pseudo-element syntax is defined in<subclass-selector>as a<pseudo-class-selector>.Subclass selectors can appear in any order while still selecting the same set of elements, but this is not true for a pseudo-element specified with the legacy single
:syntax.Therefore I assume that
:beforemust be handled as if it has been specified with::beforeand matched<pseudo-element-selector>. If so, it may be helpfull to define it in the spec.A similar confusion occurred to me when parsing a
<color-stop-list>, whose syntax requires two color stops but its grammar accepts an implicit color stop defining two stops with the same color.