Re: [csswg-drafts] [selectors-4]Why "Pseudo-elements cannot be represented by the matches-any pseudo-class"?

Ah, [I dug up the old thread]( (from 2012!).

The parsing problem with reinterpreting `::` as a combinator is indeed lethal.  It's a one-two punch of backwards-compatibility.

First, selectors like `.foo > ::before` exist today.  if `::` is a combinator, then that's two combinators in a row. We'd have to additionally add a new ability to selectors - if you have multiple combinators in a row, it implies a `*` selector between them.  That way, the previous selector is identical to `foo > * :: before`, which has the meaning we want.

However, this requires a new constraint - the descendant combinator (at least in its current whitespace form) *can't* play with this new chained-combinators feature, or else `.foo > .bar` would suddenly start interpreting as three combinators in a row, meaning `.foo * > * .bar`. That's not right! So we'd have to add in a new non-whitespace version of the descendant combinator to allow it to work with this feature.

But *this* causes another problem! Selectors like `.foo ::before` exist today. Today, that's equivalent to `.foo *::before`; with the new combinator-chaining feature and the descendant-combinator restriction, it changes meaning to become `.foo :: before` (the `before` pseudo-element of the `.foo` element).  This isn't acceptable!

So, we're screwed. Some existing selectors require a new feature to be parsed the same, which requires a funky restriction, which causes other existing selectors to not parse the same.

The only way around this is to add a *totally new* combinator for pseudo-children, not `::`, and that's much harder to sell as being worthwhile. :(

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Friday, 9 February 2018 21:56:51 UTC