Thinking globally vs. specifically
Hi guys, I had an interesting discussion on Reddit about styling. The discussion was about thinking globally (styling all
h1s, p, etc. the same) vs. using more specific selectors / approaches like BEM, scoped CSS, or utility classes.
I was of the opinion that we should try to think globally first, and let the styles cascade down. If we have a component library, we can hope that most of the h1s will be similar, so they should share the same styles. If we need variations, like for a blog, we can give it a utility class: .h1--blog.
The other commentor was of the mind that using global styles led to a lot of overrides and specificity issues down the road when building a large application. Especially when thinking about headings, there can be many variations and changing the global heading can have unintended side effects (I have this happen a lot actually).
What are your opinions? After talking with them, I think for smaller marketing websites, thinking globally can be a fine approach since generally there won't be much variation between base elements. But when you're styling a larger website, there are probably too many variations between common elements like headings that it doesn't make sense to think globally.7 Replies
Side note: this is an issue I've had for a few years now since I started writing CSS and was hoping as I gained more experience I would find the answer. But I realize there probably isn't a one-size-fits-all answer to this. Writing good CSS is hard!!
I think the key is in the name: Cascading Style Sheet. It's designed to be global-first.
BEM, scoped CSS, etc are all attempts to remove the "C"β¦so technically it's fighting against the language.
I use both global and specific styling together. With your headings example, I would generally use the same font family on all of them, so that would be global, but each heading level gets a different font size and may get different colors, so that would be specific.
The other commentor was of the mind that using global styles led to a lot of overrides and specificity issues down the road when building a large application.The reeks of skill issue, TBH. "I can't figure out how to do X well so it's a language problem" π I'm a big fan of what I call "class-scope". I'll set global defaults (and by that I mean pretty much leave everything the browser default except for maybe font size [using
clamp()], font family, and potentially max-inline-size) then use classes to "scope" styles.
For example:
That way the styles are "scoped" to the .card class and can be used in multiple places to get the same card-type feel
Especially when thinking about headings, there can be many variations and changing the global heading can have unintended side effects (I have this happen a lot actually).If there are many variations then it shouldn't be a "global" heading, yeah? That's exactly what classes are for!
But when you're styling a larger website, there are probably too many variations between common elements like headings that it doesn't make sense to think globally.This is an issue for any programming language at scale, not just a CSS thing. If you don't plan ahead and make solid rules for the team to follow then you'll have Problemsβ’. Also, custom elements could be a big help here. It gives you style encapsulation and a solid library of UI components to use so there's less "cowboy code" (shooting from the hip and making it "work")
I agree! I also love doing the class scoping styles too. For the work I do, we can't really make 'components' in the traditional sense (like web components etc.) so it would really just be class scoping it with a custom component class.
But I think what the commentor said had merit. You're right, if it doesn't make sense to put it in a global style if there are too many variations, don't do it. I think you guys kind of agree in that sense haha, just saying it a bit differently
It's interesting to think about. I think that's kind of the crux of the issue that I have at least, speaking personally. I try to force things to be global without giving it too much thought. I need to start really planning ahead consciously and think about how I want to do my styles when I have the Figma file in my hands
So here's my 2Β’ on the topic:
* Element selectors are global. Anything on them are applied to all elements unless overridden by something more specific
* Classes either modify an element or scope child element's styles
* IDs are 98% for anchor tags and 2% for unique styles
Additionally, USE CUSTOM VARIABLES! That's a super simple and easy way to modify something without needing to do something wonky.
-# slight sidebar, but custom variables should describe what they're for, not what they are. As an example, you should have
--clr-primary and not --clr-red. If you the second and need to change the primary colour you'll have to change the selector everywhere! Rule of thumb: if the custom variable can be replaced by an existing value and not change, you're doing it wrong.It's funny because I use custom variables but don't change them π
So like:
And then I'll do: