I'm still against inline CSS and what are essentially inline css helper libraries (tailwind etc), but a big part of maintainability is co-location of related co

I'm still against inline CSS and what are essentially inline css helper libraries (tailwind etc), but a big part of maintainability is co-location of related code, which inline CSS provides at the cost of readability and control. I feel you can get most of that benefit with well organised SCSS, specifically something similar to the components/contexts model. For components, you have no styles outside of your component partials, so nothing influences a component except what's targeting it. All targeting is via BEM naming, so no inheritance even for nested components. So that's components, however sometimes things change depending on their context, which is really messy if you're using inline styles. You end up introducing logic, or you end up with different kinds of components for different contexts and having to maintain them all. When using components/contexts, if for example a product-card on the checkout needs to look different in some small way. You just have a _checkout.scss file, and in it you target .checkout-page .product-card, and that's it. Simple, clean, no weird inheritance/overriding issues, just hygienic scoping of CSS and one level of inheritance available if needed. The product-card never has to concern itself with checkouts, and the checkout knows it has a product card so it makes sense that it controls any changes it wants. I've been using this method for a while now, the majority of the time you end up with ~10-20 small component files, and then 4 or 5 context files with maybe 20 lines in them. You know exactly where all styles affecting your component live, it ends up really clean and easy to maintain.