Nested rules is just a syntax sugar. In Sciter, 10 years ago, I came up with style sets: @set Main { :root { ... } // root element that has this set applied .bar { ... } article { ... } :root > article { ... } } main { style-set: Main; } // main element with the set applied This solution solves two problems: 1. Modular/componentized style definition - same goal as in nesting styles, but without introduction of new sy…
If syntactic sugar was really just sugar, JS would have sticked to callback functions, and we’d still be inventing abstractions to make our lives easier. Syntactic sugar, sometimes, is the promise of sunnier mornings and that matters.
When you want to add a feature you should ask first if that can be accomplished by existing mechanisms.
And the second, if to go with with the change that affect millions of users, can we solve not just one problem (that already has a solution like LeSS & Co.) but possibly other principal too?
So for #1. If we already have @media sections, why not to use the same notation?
@media name { ...rules... }
and @set name { ...rules... }
@set can use existing code in parsers. Not just in browsers but in tons of existing tools and editors that do syntax highlighting.And #2. Style sets solve problem of global CSS namespace pollution.
Consider this rule:
div [name="some"] { ... }
then, while calculating styles of DOM elements, absolutely all N DOM elements need to be checked against this rule. So it is a O(N) complex task. And proposed nested rules thing does not reduce the N, but may make this even worse - more rules will be used.While in style set solution:
@set ComponentA {
div [name="some"] { ... }
}
that rule will be checked only against children of componentA - the rule is local/scoped to DOM subtree. Still O(n), but n <<< N.