W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2018

Re: [csswg-drafts] [selectors-4] :valid-within / :invalid-within pseudo-classes

From: Roman Komarov via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Nov 2018 23:52:58 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-439232748-1542325977-sysbot+gh@w3.org>
If something does not cover all use cases, it does not mean it won't cover _enough_, or that the solution for these cases it covers wouldn't be useful.

My line of thought is the following:

1. We can't have `:has()` or `:has-child()` with chaining due to performance concerns.
2. That does not mean those things are not implementable, but currently, we can basically have only things like `:focus-within` — specific cases without limitations, but with a very small scope which browsers can expect and optimize to.
3. We have a lot of different cases when we need to look inside an element, for different purposes like `:valid-within` etc. Introducing those, while would be possible, would be a bunch of spec & implementation work each time, and each time there'd be a need to see if the case is wide enough, if the downsides for the absent limitations would be ok performance-wise for a specific case etc. And we can get potentially a very long list of `:whatever-within`s, each potentially with its own implementation and bugs.
4. Something like `:has-child()` has a limited scope and if nesting it wouldn't be possible, then the performance concerns are, as I understand, minimal, and this is something implementors say they can consider.
5. If `:has-child()` would be accepted, it would be needed to spec & implement once, and it would already cover a lot of cases and allow developers who want specific `:whatever-within` for their cases to see if they can live with a smaller HTML structure in order to benefit from this. Other developers would come up with multiple unintended ways to achieve a lot of powerful stuff using this new feature, as this is a very general tool and could be used in a multitude of ways.
6. Basically, this `:has-child()` would come the closest to the universal “parent selector” holy grail, and while it won't cover all the cases, it would cover a lot.
7. After it would be implemented and developers would play with it in production, we could understand if more powerful and specific new tools like `:valid-within` would be needed. What would be cases that couldn't be solved with the HTML structure needed for `:has-child()`, and those things — if we'll have them — could be then implemented similarly to `:focus-within`. But my experience says that `:has-child()` would be enough for most of the practical cases.

Something like that.

And speaking of cases with virtual DOM, I has two counterpoints:

1. It is better for developers to know the DOM they style, and for selectors to be more specific. If `:has-child()` would be an incentive for developers to study HTML and how it works — this would be very good in my opinion.
2. If we're talking about virtual DOM and more complex JS solutions around it, then we can already do anything by ourselves — it is not very hard to implement things like `:focus-within`, `:valid-within` with modern reactive technologies, so those rare cases that couldn't be solvable by `:has-child()` could still be solved by JS.
3. Those modern technologies provide a lot of ways to write effective reusable code, so if we'd have `:has-child()` and developers would come up with solutions that would need specific, slightly more inconvenient HTML, those technologies would allow us to write and use this HTML in a maintainable way.

Overall, while I understand the concerns, I see that the pros of having something like `:has-child()` overwhelmingly overweight the cons, and that it would be much more healthier for CSS and developers to first have it, and only then look into more powerful but specific alternatives.

GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3072#issuecomment-439232748 using your GitHub account
Received on Thursday, 15 November 2018 23:52:59 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:39 UTC