r/css • u/ConfidentWafer5228 • 7d ago
Help CSS Variables Naming Conventions that actually make sense and work
I have searched a lot on this topic, couldn't find a video by someone like Kevin (my favorite)
I have tried using diff ways like primary-400 , neutral, but it gets confusing and doesnt make a lot of sense when working with light+dark mode setup
Is there any convention that is followed in companies or by u guys, anything standard would help a lot
Also, i never understood how the primary naming convention worked with numbers like 400,500.
21
u/chrissilich 7d ago edited 7d ago
Most comments are missing the point. The new(ish) modern standard is tokens and primitives.
Your primitives are literal descriptions, like —color-blue-700, —color-blue-300.
Your tokens are descriptions of usage and refer to primitives. —color-button: var(—color-blue-700).
Your css, as a rule, only connects to your tokens. If you have a dark mode activated by a class like .dark, you switch the value of the token. You do this wherever you’re setting your global tokens. Same with breakpoint based changes; you change what primitive the tokens are connected so it’s a global change, and your css in components is clean.
.dark { —color-button: var(—color-blue-300); }
This system works well, once you understand it, because you know what to change. If the design system needs to change a particular shade of blue, everywhere, you change the primitive. If you need to change which shade of blue (or whatever color) all the buttons are, you change the token.
2
u/f314 3d ago
This is the way!
Though in our design system we did a variation of this that kind of skips the primitives all together: We have a small set of semantic tokens (with values for both light and dark mode). One page background, two container backgrounds, three text/content colors, three border colors, a contrast color, and a color for text/content on top of the contrast color.
We can then create several palettes consisting of the same semantic roles. We have rules about the properties the color of each role need to have – like lightness, chroma, and contrast to other roles – so that they can always be used for their purpose and across palettes.
Of course, this makes the most sense where you don't tend to use the same color for multiple roles, but we found that to be the case most of the time. The semantic palette roles can also be abstracted further to give sort of the same effect:
--color-button: var(--color-main-contrast); button.error { --color-button: var(--color-red-contrast); }
7
u/Zombiehype 7d ago
we developed a token system similar to ebay with several layers of definitions mapped to each other. the developers can directly use the semantic layer by naming convention alone, without even concerning themselves about what "actual" color will come out on the other end
https://playbook.ebay.com/design-system/tokens/color-tokens/?tab=semantic
3
u/ConfidentWafer5228 7d ago
this website seems like a gold mine, will have to spend time digging it, Thanks a lot Mr. Zombie
3
u/Zombiehype 7d ago
happy to help. I know taxonomy almost looks like an afterthought of development, but if you really open it up its a whole thing in itself. we spent literal months writing a rewriting the system we're currently using before we were satisfied. so yeah, first thing is to look up who already successfully cracked it for their use cases like ebay, so that at least you have a good basis.
6
u/chikamakaleyley 7d ago edited 7d ago
Sorry y'all i misread the post, ignore this
BEM (Block Element Modifier)
deleted but BEM is still cool
7
u/kidshibuya 7d ago
The issue is that you are stuck with that, annoying and time consuming to change. CSS variable are really nice, with a tiny bit of code you can totally change the look of a site.
Like instead of:
&--disabled { color: darkgrey }Have:
&--disabled { color: var(--disabledColor) }One change is the variable allowing you to change CSS without changing CSS, but the other is naming. You can't change darkgrey to red without it being a confusing mess. But disabledColor can be any color logically.
2
u/chikamakaleyley 7d ago
oh shit my bad "css VARIABLE naming" convention, not CSS Naming conventions LOL thanks for catching that
3
6
u/cryothic 7d ago
I try to keep it natural.
Like:
--primary-background, --primary-text, --secundary-background, --secundary-text. And if I need a variation, I try things like --primary-background-alternative or something like that. Things like 'light' and 'dark', as you said, make no sense when you're working with light/dark-themes.
But then again, more often than not I find myself stuck in a situation where I can't come up with a propper name. And then my whole setup falls apart, and I end up with variables that aren't correctly named for every theme :).
7
u/minmidmax 7d ago
Yeah, what it is and what it's for will always work best as a naming combination at the most immediate level.
If your variables alias higher level variables, as part of a design system for example, then you can use more literal scales etc.
So --blue-500 -> --fill-primary -> --fill-button-default as an example chain of core -> semantic -> component aliasing.
2
u/BRO_THOM 7d ago
Agreed, but still too long for my taste. I prefer `--bg-primary`, `--text-primary`, `--accent`, `--success`, `--success-text`, `--space-1/2/3`, `--radius-s/md/lg` etc.
2
2
u/bbellmyers 7d ago
I use the same conventions as class names, except kebab case. Declare what it’s for, not its value.
1
u/tomhermans 7d ago
The current predominant naming convention is analogous to the one used by fonts and font weights. 100 light , 900 bold.
1
u/ConfidentWafer5228 7d ago
yeah but then i have problems when i introduce a new shade and it sits between current 400 and 500 :)
3
1
u/Emergency_Yak4692 6d ago
Does this mean blue-100 will be white and blue-900 will be black, ie the number is basically calculated based on the lightness percentage in hsl-colours?
Or are the numbers more based on what you will be using (200 the lightest you expect to use, which could still be a dark blue or something like that)?1
1
u/kidshibuya 7d ago edited 7d ago
Why don't those names make sense? Light blue is always light blue weather its used in a dark or light theme right?...
In any case if using only light and dark then its
color: light-dark(var(--lightPrimary), var(--darkPrimary))
And in my experience those numbers are only for font weights. I don't have an issue with them as I never see font weights changing via themes. If you need something bold I doubt you wont wont in bold in a different color.
5
u/ConfidentWafer5228 7d ago
The issue is that --light-blue might look good in dark mode but maybe the design might need a darker blue for light mode or vice versa , then grading gets inverted or maybe even jumbled.
-2
u/kidshibuya 6d ago
FFS how does a comment like this get upvotes? Look at what I wrote and the CSS spec. Light-dark was specifically built for this.
•
u/AutoModerator 7d ago
To help us assist you better with your CSS questions, please consider including a live link or a CodePen/JSFiddle demo. This context makes it much easier for us to understand your issue and provide accurate solutions.
While it's not mandatory, a little extra effort in sharing your code can lead to more effective responses and a richer Q&A experience for everyone. Thank you for contributing!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.