Most of the time you're right, a CSS methodology works great and avoids scoping issues. But regular CSS is non-scoped and non-modular by definition, so there's always the possibility that in a larger app, a developer will unknowingly use a component or utility name that is already in use elsewhere, thus destroying the semantic barriers between components and causing style conflicts. I've seen this happen a few times (with BEM) and it can be very difficult to figure out why things are broken.
That said, I'm not opposed to CSS methodologies at all, but if scoped CSS is an option I will always choose that because it's far less likely to fail due to human error.
In my company, we separate each CSS component in different files (button.scss, tabs.scss, etc). This way, there'no way to get conflicts.
If you think, css classes create scopes the same way js functions does.
CSS is not the problem. Developers are.
That's not the way I see it. If I have two separate JavaScript functions and each declares a variable named "foo", they will always refer to different memory locations. There is no way to get "foo" in one function to refer to "foo" in the other function. In CSS, if I declare two classes named "foo", both of them globally refer to everything with the class "foo."
Separating CSS components into different files doesn't create new CSS scopes. If you happen to use the same selector in both, then you'll end up with two different sets of styles for a single element. This isn't a rarity in large apps; it happens often. If one developer wants to create a tab that acts like a button (.button-tab) and another developer wants to create a button that looks like a tab (.button-tab) they'll end up with an overlapping selector. Some developers will dig through the codebase to figure out where the conflict is and rename the class to fix things; many will not, and instead choose to bump up the specificity in order to make their styles work, which over time reduces maintainability.
CSS was created for developers. If developers consistently have trouble with certain aspects of it, then blaming the developers isn't a productive approach. Scoped CSS is inherently predictable and debuggable in ways that global CSS is not.
If you create 2 foo functions globally, they will conflict. Of course you won't do it.
In CSS you can also prevent that. For example you can use BEM - or even nested selectors to help.
That's what I was trying to explain.
About separated CSS files, I forgot to say that every class inside each file must start with its name. For example, in the file button.scss you would put .button, .button--big, .button__icon, etc.
Developers - specially with less experience - have problems with every language. That doesn't mean the languages are bad or wrong. It means we must create patterns and best practices for them.
If you follow a CSS methodology, your code is going to be modular and you won't have any problem with scope. Try ITCSS, for example.
Most of the time you're right, a CSS methodology works great and avoids scoping issues. But regular CSS is non-scoped and non-modular by definition, so there's always the possibility that in a larger app, a developer will unknowingly use a component or utility name that is already in use elsewhere, thus destroying the semantic barriers between components and causing style conflicts. I've seen this happen a few times (with BEM) and it can be very difficult to figure out why things are broken.
That said, I'm not opposed to CSS methodologies at all, but if scoped CSS is an option I will always choose that because it's far less likely to fail due to human error.
In my company, we separate each CSS component in different files (button.scss, tabs.scss, etc). This way, there'no way to get conflicts.
If you think, css classes create scopes the same way js functions does.
CSS is not the problem. Developers are.
That's not the way I see it. If I have two separate JavaScript functions and each declares a variable named "foo", they will always refer to different memory locations. There is no way to get "foo" in one function to refer to "foo" in the other function. In CSS, if I declare two classes named "foo", both of them globally refer to everything with the class "foo."
Separating CSS components into different files doesn't create new CSS scopes. If you happen to use the same selector in both, then you'll end up with two different sets of styles for a single element. This isn't a rarity in large apps; it happens often. If one developer wants to create a tab that acts like a button (
.button-tab) and another developer wants to create a button that looks like a tab (.button-tab) they'll end up with an overlapping selector. Some developers will dig through the codebase to figure out where the conflict is and rename the class to fix things; many will not, and instead choose to bump up the specificity in order to make their styles work, which over time reduces maintainability.CSS was created for developers. If developers consistently have trouble with certain aspects of it, then blaming the developers isn't a productive approach. Scoped CSS is inherently predictable and debuggable in ways that global CSS is not.
If you create 2 foo functions globally, they will conflict. Of course you won't do it.
In CSS you can also prevent that. For example you can use BEM - or even nested selectors to help.
That's what I was trying to explain.
About separated CSS files, I forgot to say that every class inside each file must start with its name. For example, in the file button.scss you would put
.button,.button--big,.button__icon, etc.Developers - specially with less experience - have problems with every language. That doesn't mean the languages are bad or wrong. It means we must create patterns and best practices for them.
"A CSS methodolody"... is a thing?! Oh you mean a way of structuring and naming selectors...?
Yes. Such as BEM, ITCSS, OOCSS, Atomic, etc.