Maybe I misunderstand your problem with scoping...
Scoping is the mechanism that controls the range in which rules are applied or definitions are valid. CSS has definitively made a nice progress in this field, as the initial approach of the "cascading" styles, that are applied to all children, often caused more trouble than it solved. So, the new "@scope" is a real step forward, but it is still some kind of "explicit scoping". You will need to name scopes manually.
I´m just comparing this to what we have in other languages, as any kind of programming language uses scopes:
In most languages we know a global scope, as we had in CSS all the time
Usually we have some kind of "local scope", which is different from inline-styles. A local scope is bound to a logical unit like a function or a class, inline styles are just bound to the element and have no real "range" (beside the direct children)
In OOP-languages scopes can be bound to a class. So all Objects derived from this class will automatically inherit this scope. I call this "logical scoping", as the scopes follow the logic of your code. This is often used to control the appearance of element families in UI´s.
CSS is still missing this level of "implicit scoping" which is a reason why people use CSS in JS solutions. Implicit scopes are much easier to maintain, as you do not need to care for naming. If a definition only makes sense in a certain context, it is useful that this definition is only valid there. Even with the new "@scope" you can apply a definition anywhere (maybe accidentially by typing a wrong letter), regardless if it is useful or not. This does not mean you cannot make any errors. It is just much easier if you just use named scopes.
Svelte introduced CSS that is bound to a module, which is a bit more like what we have in other languages. CSS in JS goes a similar way, as it allows to bind CSS to functions or classes, but as we see, this might come with some serious performance costs.
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.
Scoping is the mechanism that controls the range in which rules are applied or definitions are valid. CSS has definitively made a nice progress in this field, as the initial approach of the "cascading" styles, that are applied to all children, often caused more trouble than it solved. So, the new "@scope" is a real step forward, but it is still some kind of "explicit scoping". You will need to name scopes manually.
I´m just comparing this to what we have in other languages, as any kind of programming language uses scopes:
CSS is still missing this level of "implicit scoping" which is a reason why people use CSS in JS solutions. Implicit scopes are much easier to maintain, as you do not need to care for naming. If a definition only makes sense in a certain context, it is useful that this definition is only valid there. Even with the new "@scope" you can apply a definition anywhere (maybe accidentially by typing a wrong letter), regardless if it is useful or not. This does not mean you cannot make any errors. It is just much easier if you just use named scopes.
Svelte introduced CSS that is bound to a module, which is a bit more like what we have in other languages. CSS in JS goes a similar way, as it allows to bind CSS to functions or classes, but as we see, this might come with some serious performance costs.