- Avoid cascading (i.e. no nested selectors except when there's "no other way")
- Implement separate selectors for styling and page/component layout (separation of concerns)
- Using a good naming convention and stick with it
The first point can also be achieved with using style attributes if that floats your boat, although Svelte kind of gives you the best of both worlds just by compartmentalizing the CSS, not necessarily by preventing cascading.
I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.
Styling is setting colors/fonts/padding etc on a specific component.
eg. .sign-up-form .delete-button .accept-button
Importing HTML files as modules with localized CSS+JS as web components would be one such option for example.
Yep. I find of the usage of !important I see daily is failure of the programmer to understand precedence rules, which, as you pointed towards, is mostly due to cascading.
[1] Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?
[2] Of course Tailwind supports modifiers, which do cascade, but everything is still local to a single element.
> Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?
Yes, it's nothing something you'd want to do willy-nilly or all the time, but there are perfectly valid use cases. This issue has been one of the single most-commented in the Svelte repos with tons of back and forth and a lot of demand so this isn't just an obscure complaint either.
As for how to resolve it, there are plenty of clean ways to do it. Svelte's style scoping is done via a unique class per component. It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it. There are many possible variations on this theme. The obstacle to resolving this problem isn't technical infeasibility, it's that to date the maintainers just haven't cared.
Again, the child component can't decide what to do with a class, as it can't know specifics about the parent. It would break the modularity.
I checked the most commented issue, it's about the reactivity system doing only one round of checking in topological ordering, which could be fixed, but could cause infinite loop, and again the problem is not implementation, but deciding on the best design:
https://github.com/sveltejs/svelte/issues?q=is%3Aissue+is%3A...