In worst case complexity of styles resolution is O(nS*nD) where nS is a number of style rules and nD is a number of DOM elements. That's for current flat style table used by CSS. You can optimize bits and cases but it in general problem is like that.
> @media queries ... at least in Blink they're handled entirely different.
@media and @set are different mechanisms. :root in @set matches element that has this set applied. @set's are scoped set of rules. @media are not.
But I was talking about different thing - parsing, in particular in syntax highlighters and other tools.
@set aside-set {
:root {...}
... nA more rules
}
@set main-set {
:root {...}
... nM more rules
}
<aside> content style resolution will always be constant and independent from <main>, no matter how many nM rules you will have. While currently (with the flat table) adding rules for <main> content will increase complexity of <aside> DOM resolution too.
As a bonus: rules in two sets are completely isolated. Adding rule in main-set will never break existing aside design.
> In worst case complexity of styles resolution is O(nS*nD) where nS is a number of style rules and nD is a number of DOM elements. That's for current flat style table used by CSS. You can optimize bits and cases but it in general problem is like that.
Worst-case isn't really interesting for browsers, though. CSS doesn't have an adversarial performance model.
> @media and @set are different mechanisms. :root in @set matches element that has this set applied. @set's are scoped set of rules. @media are not.
Again, this roughly matches @scope (where :scope matches the element that has the given selector applied). But this is just a fantasy spec, right? There are no browsers that implement this, and just like with @scope or nesting or CSS at all, there's no guarantee in the spec what performance characteristics you would have?
FWIW, if you want something like this and get it through CSSWG, you'll most likely see it end up with worse performance than flat CSS, unless it becomes _really_ popular and browsers see the need to optimize certain sub-cases of it (the general case, with tons of different sets, will be nearly impossible to make really fast).
"All of that is very different between the various engines, making the whole process even less predictable."
Source: https://benfrain.com/css-performance-revisited-selectors-blo...
In worst case complexity of styles resolution is O(nS*nD) where nS is a number of style rules and nD is a number of DOM elements. That's for current flat style table used by CSS. You can optimize bits and cases but it in general problem is like that.
> @media queries ... at least in Blink they're handled entirely different.
@media and @set are different mechanisms. :root in @set matches element that has this set applied. @set's are scoped set of rules. @media are not.
But I was talking about different thing - parsing, in particular in syntax highlighters and other tools.
----
Consider this DOM:
And CSS: <aside> content style resolution will always be constant and independent from <main>, no matter how many nM rules you will have. While currently (with the flat table) adding rules for <main> content will increase complexity of <aside> DOM resolution too.As a bonus: rules in two sets are completely isolated. Adding rule in main-set will never break existing aside design.