[css-syntax] '>>' and '>>>' should be a token

[TakayoshiKochi]

CSS scoping spec defines >>> as shadow-piercing descendant combinator:
https://drafts.csswg.org/css-scoping/#deep-combinator

CSS selectors defines >> as descendant combinator:
https://drafts.csswg.org/selectors-4/#descendant-combinator

Currently CSS syntax does not specify these (>> and >>>) as tokens,
and >>> is parsed as 3 consecutive delim-token(>) s.
https://drafts.csswg.org/css-syntax/

Therefore >/**/>/**/> is allowed to mean a >>> combinator, but probably
it does not make any sense. We propose to define >> and >>> as
distinct tokens.

[tabatkins]

I'd prefer not to add more Selectors-specific tokens unless necessary; they can theoretically make things complicated in the future.

That said, the original Selectors-specific tokens were added so that the Selectors grammar was LR(1) (that is, just based on the next token to be consumed, no additional "lookahead" at all). If we want to maintain that invariant, we will have to add >> and >>> tokens. If we don't care about that invariant (and are okay with expanding Selectors to an LR(3) language - CSS in general is LR(4) iiuc), then we can avoid doing this, and drop the other special Selectors tokens, too.

[tabatkins]

Ugh, hit Comment too soon.

Therefore >/**/>/**/> is allowed to mean a >>> combinator, but probably it does not make any sense.

I don't think this is a reasonable argument. ./**/foo is a valid class selector, :/**/hover is a valid pseudo-class selector. On the other hand, #/**/foo is not a valid ID selector, and :nth-child/**/(2n) is not a valid pseudo-class selector. In other words, whether comments are allowed in a given spot is already mostly irrelevant, and just falls out of accidental details of the grammar definition. We don't actually consider it when designing anything, and so it shouldn't affect our thinking here either.

So, back to my original argument: if it's important that Selectors remain LR(1), then we need to add two new tokens to handle the combinators. If it's not, we don't and shouldn't, and should go ahead and remove the other special combinators too.

[TakayoshiKochi]

Okay, I understand that comment (/**/) can be inserted to a point within a combinator would not be much persuading argument with your examples, and I don't care whether we should be strict about LR(1) or LR(1+). So I do not have a strong opinion to make >> and >>> distinct tokens.

@hayatoito @rune-opera @tim-loh do you have any concerns if we go without these tokens? My gut feeling is (as one who implemented the parsing part for >>> in Blink) it doesn't make any difference whether >>> is a single token or 3 tokens outside the combinator parsing function. But I'm not sure - e.g. when calc() supports >> as a operator, or something that I'm not aware of.

[tim-loh]

I don't have any concerns with either option, as a Blink implementer. Tab's position seems pretty sensible to me.

[TakayoshiKochi]

Thanks Tim for the comment. Now I think it is fair enough to leave the CSS syntax as is for >> and >>>.
Let me close this issue as wontfix.

If you have any concrete reasons to have tokens for them, please feel free to reopen.

Didn't see this until now, but +1 for closing.

[tabatkins]

I added Agenda+ to this topic, but I'll be in the air on the way to vacation next Wednesday morning. My arguments are complete above - if @dbaron or others can review this and have an opinion on it by the next telcon, feel free to discuss it without me; I'll accept either outcome.

Otherwise, we can do it on the 14th, when I'll be back.

[dbaron]

There's also some danger to adding new tokens in that it can change the tokenization of other things in CSS. See, for example, this bug on unicode-range tokens messing up selectors (and I think there's another similar bug somewhere).

It's also not clear to me if this is needed for selectors to be LR(1), given that >,>>, and >>> are all combinators. But I don't really remember the details of the formal definition. I think that in practice it makes it less problematic.

[tabatkins]

Whoops, GitHub didn't live-update this page, so my last comment was made without having seen any of the responses since my previous comment. :/

Happy to keep it closed, tho note that all the implementors chiming in are Blinkers. I wouldn't mind someone from Moz chiming in with whether or not keeping Selectors LR(1) is vital or not; if it's not, I'll open a wider issue to drop the other special tokens. @dbaron?

[tabatkins]

UGH FFS THIS KEEPS HAPPENING DARN YOU GITHUB.

David, any opinion on whether Selectors needs to be LR(1)? (CSS tokenization in general appears to be LR(4), since it uses the current input character + 3 characters of lookahead; I think CSS parsing is LR(2).)

[tabatkins]

Resolution (pending anyone objecting) is that we drop the implicit requirement that Selectors remain LR(1) (of course, still maintaining the implicit requirement that CSS should only require small, finite amounts of lookahead). As a result we also drop the older Selectors-specific tokens from Syntax, and fix Selectors to just refer to delim tokens.