Pseudo-classes and pseudo-elements

[KillyMXI]

Specification:

• https://drafts.csswg.org/selectors-4/ (majority of the document content describes various pseudo-classes);
• some parts of https://drafts.csswg.org/css-syntax/ (such as 6. The An+B microsyntax);
• https://drafts.csswg.org/css-pseudo-4/ (pseudo-elements).

Kinds of simple selectors to support:

• pseudo-element (such as ::first-letter or ::after). There is not such thing as functional pseudo-element (yet?) which makes them easy to support;
• regular pseudo-class (such as :hover). Very straightforward;
• functional pseudo-class (FPC) (such as :not(), :nth-child(), :dir(), :lang(), etc). This is the most complicated part. Each FPC has it's own subset of possible values inside parentheses.

Possible implementations:

• partial. Don't support FPC, for the time being at least. Cons: may require breaking changes later on;
• include exact FPC names into the grammar. Pros: exact grammar for values is known at parsing time and well reflected in the parsed object. Cons: Blow up the parser grammar in size; can only support a fixed subset of pseudo-classes;
• parse FPC based on it's value. Different value sub-parser matched - different output type is produced. Consumer code will first look for the type then for the pseudo-class name. Pros: smaller grammar, no need for boilerplate listing all possible names. Cons: more complicated client code, have to handle collisions between sub-parsers somehow. Probably returning a list of valid interpretations from sub-parsers. The challenge: how to do it with nearley. Also, overall specificity can't be computed without knowing which interpretation to choose.
• return FPC args as a raw string, provide a separate parse function(s) for An+B and whatever else needed. Client code can decide which one to use. Pros: smaller grammar, simpler implementation. Cons: more complicated client code, can't compute specificity!

Possible sub-parsers for FPC:

• list selector (inside :is(), :not(), :where(), etc);
• fixed string (ltr, rtl inside :dir());
• list of arbitrary strings (inside :lang());
• even | odd | An+B (inside :nth-col(), etc);
• even | odd | An+B [of S] (inside :nth-child(), etc).

Note: inner selectors usually affect specificity. For most list selectors the max specificity is used, :where() has 0 specificity.

Considering we have to know exactly what sub-parser to use and can't give up on specificity calculation, there is no option other than include names into the grammar.
Each sub-parser will include an enumeration of possible names (there is a possibility to make it extensible via options).
Pseudo-elements and regular pseudo-classes can have arbitrary names. It is not really consistent with FPC but I'd call a compact grammar is a priority here.

Possible fallback behavior for unknown FPC names:

• return a raw string. Not really consistent. Will require to expose sub-parsers to help the client code. Challenges: parentheses balance, specificity computation;
• provide an extension point (callback) for the client code to handle unknown FPC. This might be more adaptable to any future grammar, but updating the package would be a better way. Just letting clients to assign existing FPC grammars to new names seems more reasonable compromise.
• parse failure. Will require the package update for any new name.

Making it a parse failure for now, with a possibility to introduce a new return types later if needed and with a possibility to assign existing grammars to new names - does seem like the most reasonable approach.