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