- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Apr 2020 22:37:40 +0000
- To: public-css-archive@w3.org
> @tabatkins, I know it's very expensive and unlikely be be implemented in browsers. My comment was a reply to @SebastianZ - I'd suggest drastically changing the meaning of the `has()` function when you already have shipping implementations isn't a great idea. The syntax I suggested is a subset of the currently specified, i.e. not a breaking change. Implementations already covering the currently defined syntax are then just ahead of time. Another option would be to already define both syntaxes in Level 4 and add a hint that implementations should support the fully-featured syntax if performance is irrelevant (e.g. in print engines) and fall back to the simpler syntax if performance is critical (like in browser engines). > No simplification of :has() that still allows arbitrary combinators is likely to have a noticeable effect on the perf. It's not the cost of evaluating the selector that's killer, it's the number of elements that have to be re-evaluated on every mutation. Currently it's all the descendants of the mutated element's parent; they're the only elements that can observe the mutation with today's selectors. :has() makes the entire document potentially able to observe the mutation. The suggested syntax with a single [`<combinator>`](https://drafts.csswg.org/selectors-4/#typedef-combinator) restricts the number of elements to either children (`>` combinator), next siblings (`+` combinator), subsequent siblings (`~` combinator), or a column relation (`||` combinator). With that, the performance impact should be very much mitigated. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4903#issuecomment-611230101 using your GitHub account
Received on Wednesday, 8 April 2020 22:37:43 UTC