#219: CSS Selectors 4

Visit on Github.

Opened Nov 30, 2017

Hello TAG!

I'm requesting a TAG review of:

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]

Discussions

Comment by @annevk Nov 30, 2017 (See Github)

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

Comment by @victoriasu Dec 1, 2017 (See Github)

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

Comment by @SelenIT Jan 17, 2018 (See Github)

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

Comment by @victoriasu Jan 18, 2018 (See Github)

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

Comment by @SelenIT Jan 19, 2018 (See Github)

@victoriasu, thank you!

Comment by @torgo Jan 31, 2018 (See Github)

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

Comment by @dbaron Jan 31, 2018 (See Github)

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.

Comment by @fantasai Jan 31, 2018 (See Github)

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.

Comment by @slightlyoff Feb 2, 2018 (See Github)

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).

Comment by @fantasai Feb 3, 2018 (See Github)

@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 https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-358124504, 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 https://github.com/w3c/csswg-drafts/issues/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~ ^_^
Discussed Mar 27, 2018 (See Github)

David: Looks like there was comment and response at London, nothing since.

Peter: Where do we go from here? Is feedback addressed?

Alex: I'll respond. Would love if David or Peter could weight in on question of explainer or in-document. I would like to see motivations outlined.

Peter: CSS WG hasn't generally done that, but might be useful for insertions into old documents.

Alex: And seems good to have an explainer explaining insertions into older documents to explain the constraints.

Peter: Done after this response?

Alex: Check back in next week after I write the response.

Comment by @slightlyoff Apr 5, 2018 (See Github)

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.
Comment by @LeaVerou Apr 10, 2018 (See Github)

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 (https://github.com/w3c/csswg-drafts/issues/2143). Please weigh in if you have opinions!

Comment by @ewilligers Dec 7, 2018 (See Github)

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.