I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Scoped styles which some CSS tooling does and a lot of CSS in JS frameworks do has a working draft as well.
Aside from that, there are more pseudo selectors and classes. The :has() pseudo-class gives us something folks have wanted for a while. A parent selector.
That working draft on CSS scoping is very outdated. Afaict it was very much dead for the longest time, and only recently got revived in the working draft of CSS Cascading and Inheritance Level 6
Nested selectors is about time. I'm not sure about :has() since it makes the rendering engines more complex algorithmically, possibly degrading performance, or ...?
At the very least, I'd expect :has() to have no performance impact where it isn't use. If that can be achieved, and it just turns into one of these features that shouldn't be overused, but won't instantly kill your whole website, then I wouldn't mind having it as a feature tbh.
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.
I think a lot of things that folks like about tooling are coming to CSS or are at least being discussed.
For example, in SASS, you can nest CSS rulesets.
There is a working draft of this for CSS.
Scoped styles which some CSS tooling does and a lot of CSS in JS frameworks do has a working draft as well.
Aside from that, there are more pseudo selectors and classes. The :has() pseudo-class gives us something folks have wanted for a while. A parent selector.
Just like the browser APIs adopted jQuery APIs or were inspired by them, the same appears to be happening for CSS.
All these improvements mean that you can do a lot more in CSS without relying on JS for a lot of things you had to in the past.
That working draft on CSS scoping is very outdated. Afaict it was very much dead for the longest time, and only recently got revived in the working draft of CSS Cascading and Inheritance Level 6
Nested selectors is about time. I'm not sure about :has() since it makes the rendering engines more complex algorithmically, possibly degrading performance, or ...?
At the very least, I'd expect
:has()to have no performance impact where it isn't use. If that can be achieved, and it just turns into one of these features that shouldn't be overused, but won't instantly kill your whole website, then I wouldn't mind having it as a feature tbh.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