This is the fundamental problem. :has() does have a performance impact even where it isn't used. When a DOM element is mutated, the cascade needs to be recomputed. Without :has() implemented in browsers, only the cascade of the descendant elements of the parent of the mutated element needs to be recomputed. With :has() implemented, it was believed that the cascade of every element in the DOM would need recomputing, even if :has() wasn't used in any selector. The work done recently to implement :has() was essentially about finding a way to short cut that process to minimise the amount of the cascade that needs to be recomputed. But it can't be entirely eliminated.
Similar ideas is the reason why Hyperlambda is so blistering fast, because parsing only implies "forward operations", and nothing during parsing can change anything backwards in the file, which of course allows the parser to exclusively look forward ignoring everything it's already seen. Thank you for re-iterating that fact ...
list all your selectors with :has() somewhere in them
keep track of all elements that match the rest of the selector
follow the selector up to whatever ancestor (or descendant) the :has() applies to
keep track of these elements and only re-compute styles for changes inside them
spend another three to four decades fixing the countless bugs in your implementation, and the bugs you create by fixing those bugs, and the bugs resulting from optimisations of your previous bugfixes...
/s
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is the fundamental problem.
:has()does have a performance impact even where it isn't used. When a DOM element is mutated, the cascade needs to be recomputed. Without:has()implemented in browsers, only the cascade of the descendant elements of the parent of the mutated element needs to be recomputed. With:has()implemented, it was believed that the cascade of every element in the DOM would need recomputing, even if:has()wasn't used in any selector. The work done recently to implement:has()was essentially about finding a way to short cut that process to minimise the amount of the cascade that needs to be recomputed. But it can't be entirely eliminated.Similar ideas is the reason why Hyperlambda is so blistering fast, because parsing only implies "forward operations", and nothing during parsing can change anything backwards in the file, which of course allows the parser to exclusively look forward ignoring everything it's already seen. Thank you for re-iterating that fact ...
It's super easy:
:has()somewhere in them:has()applies to/s