- From: Roman Komarov via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Nov 2018 23:52:58 +0000
- To: public-css-archive@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