CSS Selectors 4

[victoriasu]

Hello TAG!

I'm requesting a TAG review of:

• Name: CSS Selectors 4
• Specification URL: https://drafts.csswg.org/selectors-4/
• Explainer, Requirements Doc, or Example code: N/A
• Tests: https://github.com/w3c/web-platform-tests/tree/master/css/selectors (will be placed here)
• Primary contacts: victoriasu, ewilligers (Blink implementation)

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[annevk]

If you're implementing this, how are you dealing with all the currently open issues? Is there a plan to get them resolved?

[victoriasu]

Currently I am planning on firstly implementing :any-link, :has(), and :matches(). This would be progress in unblocking Issues 1 and 22.

[SelenIT]

@victoriasu are you planning to implement :has() for the Live selector profile (so Issue 1 could be resolved)?

[victoriasu]

@SelenIT I'm no longer planning on implementing :has() but I am currently implementing :matches()

[SelenIT]

@victoriasu, thank you!

[torgo]

Taken up at London F2F. We noted that the lack of an explainer is problematic. Are the use cases documented?

[dbaron]

Also /cc @tabatkins @fantasai .

In addition to an explainer, it would probably also be useful to have a section that says what's new in selectors 4 relative to selectors 3.

[fantasai]

The levels for each selector are annotated in https://drafts.csswg.org/selectors-4/#overview
If you would like a separate section, I can create one. If you would like a detailed explanation of all the issues that were fixed between 2011 and now I will be really annoyed.

[slightlyoff]

Stream of consciousness reading the spec with @plinss :

• The Overview Section is slightly misleading regarding selectors that accept Selector Lists. E.g., instead of E:not(s1, s2), consider E:not(s1, s2, ...)
• :something (specificity adjustment) seems useful, but perhaps under-powered. Has the WG considered a modifier which would enable dropping the specificity of the left-hand side of a selector as well?
• It seems there are quite a few missing examples in the text, and some examples don't discuss the Level 4 syntax (e.g., :not()).
• It'd be great if there was a companion doc that detailed the motivations for these additions. What problems are they solving? How do we know that those problems are important? What design alternatives were considered and why were these versions chosen? This tends to be what's in an "Explainer" (along with sample code that shows how the solution addresses the stated problems).
• It's rather unfortunate to see input element state bleeding into everything. The new input-related pseudos seem like they could be perhaps subsumed by ::part or an extension to that (/cc @notwaldorf)
• The || (column) combinator reads to this programmer like "OR" 😞

Overall this looks well done, and I'm glad to see there aren't many new descendant selectors (modulo the grid structural selectors).

[fantasai]

@slightlyoff Responses:

• Added ellipses as requested.
• :something() can be added to shield part or all of any compound selector, not just the last one. There were some comments on whether to e.g. use bare parentheses to allow any part of the selector to be eliminated from the specificity count without affecting the structure of the selector, see [selectors4] Name the “functional pseudo-class like :matches() with 0 specificity” w3c/csswg-drafts#2143 (comment), but there wasn't much traction. If you think this is an alternative worth pursuing, please comment to that effect in the bug and/or file a new one? (I think the parsing issue in Tab's reply is solveable by having two forms, :(...) within a compound selector and (...) for higher-level annotation, or considering other notations.)
• Filed [selectors-4] Add more examples w3c/csswg-drafts#2267
• Tab and I believe that content that explains a feature belongs in the spec, not a separate document; in other words that the spec should be written understandable on its own, without auxiliary information, both to implementers and to authors. If there is insufficient context to understand the feature in the spec, then the spec should be improved (e.g. by adding examples, as you requested above). If you would like an archaeological record of the decisions made so that you can analyze whether they were good decisions or not, please let me know how detailed you want them and I will set aside the necessary time. A quick overview from memory should take a day or so. A disposition of comments since 2011 will probably take weeks.
• ::part is for styling parts of an input control, that is why it's a pseudo-element. The Input Pseudo-classes are for selecting state of an input control, which is why they're pseudo-classes. In any case, these are quite old (they first appeared in the CSS UI draft ~2002, were published as CR in 2004, and were moved to Selectors much later) and most have been implemented and deployed already.
• Do you have a suggested alternative? :) If you feel strongly about it, file an issue for bikeshedding~ ^_^

[slightlyoff]

Sorry for the slow reply.

We discussed again today at the W3C TAG F2F in TOK. Happy to see this move forward.

• Thanks!
• @dbaron talked us through this one and we agree that a new syntactic form would be pretty difficult here. Any update on a potential name?
• Thanks for filing. Any luck getting more examples in?
• Regarding the place for explainer-style justification for features, I'm not dogmatic. That could be in a non-normative section of a spec, but it'd still need to include all the detail of motivations, considered alternatives, and enough explanatory code to make the case for these particular additions. I haven't seen a spec doc that includes all of that, but it'd work.
• Thanks for explaining ::part pseudo. Makes sense!
• Don't have a suggested alternative and don't feel too strongly.

[LeaVerou]

Any update on a potential name?

Last time we discussed this in the call we could not reach consensus on the name, and decided to discuss more in the Github issue that @fantasai linked to (w3c/csswg-drafts#2143). Please weigh in if you have opinions!

[ewilligers]

Any update on a potential name?

We have now chosen :where() for the selector with zero specificity.

We have chosen :is() instead of :matches() for the selector that has the specificity of its most specific argument.