> The biggest problem with CSS
Everything in CSS is global. Because of that, styles intended for one bit of markup often end up affecting another. Because of that, developers often resort to wild namespacing conventions (not 'rules', since they're very difficult to enforce) that mostly just increase your risk of RSI.
Hmm, I don't find namespace issues a problem to be honest. Generally I use a framework (e.g. Bootstrap) where I don't reuse any of its names, I have some global styling (e.g. buttons, forms, typography), each major screen/component gets it's own file with its own class identifier (e.g. page-home for the homepage) then in SASS/SCSS I make sure everything everything in each file is nested under the screen/component identifier (e.g. so everything to do with the homepage is nested under .page-home). It's going to be very obvious if you get a naming conflict and they're not hard to resolve.
Is there anything wrong with the above approach? You'd need something different if you were designing your own framework or general components across a huge website but for SPA and typical websites I don't see the need to make it more complex than this.
The problem I see with that approach is that it doesn't leave a lot of room for reusability in different types of design components.
Many times in larger web applications, designers will have similar design themes that span multiple pages (more than just simple things like forms). So there may be a callout with a border and all text inside is blue across 5 separate pages.
You may approach this as #homepage .callout at first but it begins to become hard to manage when you realize you need to refactor it into a side wide style.
Generally I approach everything in attempts to make it re-usable. And organize what I can into components. I'd rather write more css classes in the markup than have to specify names for certain cases where 'this heading is bold here but underlined in this case' yada yada, when I can just write .bold .underline .h5.
> You may approach this as #homepage .callout at first but it begins to become hard to manage when you realize you need to refactor it into a side wide style.
So one approach would be to have a "callout" css file, nest everything under ".callout" and have several callout styles you can use inside that file (e.g. ".callout .warning")?
> Generally I approach everything in attempts to make it re-usable. And organize what I can into components
Personally, I find very little CSS can be reused between different projects as designers want completely different looks so I let things like Bootstrap take care of the basics and customise from there. It takes time and effort to make things reusable (same with code) so you need to weigh up how likely you are to actually reuse things and how much time that would save you.
Sometimes duplication between projects saves time compared to maintaining the code for some generic widget that has to work in many scenarios. For me, I don't think it would save much time as each component is usually small and simple but I could understand if you were to create e.g. a calendar widget where it involves a lot of complex styling and code.
If you're just using Bootstrap and its classes, then you're probably not in the 'target market' for something like this.
I think you've actually agreed that Scoped CSS is really useful, but you just implement it manually by using a naming convention. What if you didn't have to worry about that and the language just worked like that normally?
> I think you've actually agreed that Scoped CSS is really useful, but you just implement it manually by using a naming convention. What if you didn't have to worry about that and the language just worked like that normally?
I agree scoping is universally useful in coding, I just can't empathise that the lack of proper namespacing in CSS is a huge headache when it takes little effort to emulate it by nesting classes. Unless there's more to it? Language support is nice though.
I wouldn't really say there's huge effort. CSS Modules provides scoping in the same way that C++ added scoping to C (AFAIK) - it just mangles the names transparently at 'build' time.
Hmm, I don't find namespace issues a problem to be honest. Generally I use a framework (e.g. Bootstrap) where I don't reuse any of its names, I have some global styling (e.g. buttons, forms, typography), each major screen/component gets it's own file with its own class identifier (e.g. page-home for the homepage) then in SASS/SCSS I make sure everything everything in each file is nested under the screen/component identifier (e.g. so everything to do with the homepage is nested under .page-home). It's going to be very obvious if you get a naming conflict and they're not hard to resolve.
Is there anything wrong with the above approach? You'd need something different if you were designing your own framework or general components across a huge website but for SPA and typical websites I don't see the need to make it more complex than this.