custom property naming
Hey, i'm kinda stumped on naming conventions for my spacing properties. I use these for things such as padding blocks, flow gaps and tie them in with the utility classes for those. Currently i use the 100 - 900 naming method e.g.
--space-400: XYZ; with the values going up in certain increments depending on the project, for example-
This has been doing the job along with changing the properties values in media queries if they get bigger on different viewports etc. But for a couple of projects i need to extend beyond the 900. So i was wondering whether i should continue to 1000 and so on or go in 25s or 50s such as --space-125: XYZ;. I'd appreciate anyones help with this, thank you in advance!60 Replies
Have you considered following the number system used in Tailwind? It seems to work for a lot of projects.
like naming the properties
--space-2.5: 2.5em; and --space-4: 4em; for example?doing that is as good as not having a variable at all
don't put your values in your variable names... ever
but to answer the post's question. What is stoping you from using
--space-1000 ?
and do you actually use the whole range of values you are declaring
it's not because the increment in the variables name is linear that the values should be tooNo. Look at how Tailwind handles the number in the class names for margins. The actual measurement isn't in that number. https://tailwindcss.com/docs/margin
Margin - Tailwind CSS
Utilities for controlling an element's margin.
nothing is stopping me at all, i was just asking if that's an okay practice for naming properties
for the most part, for the projects i don't that's when i use the 100-900 method as i can leave out some of the numbers. For the projects where i use all of them and above, i go to 1000 and beyond but i was just asking if that was something you should be doing as i was questioning it.
ah okay my bad, not familiar with tw, i thought it was that. So from what i've seen, the values increment in 2s and are named in .5s, e.g.
you'd recommend this sort of thing?
Yes. Tailwind is used in millions of projects and it seems to work for them.
alrighty i'll give that a shot. Thank you!
so i've set it up to look something like this, you would say this is a more suitable soltution?
I actually don't like Tailwind, but it works for a lot of projects.
ah fair enough, what would you usually do in this scenario?
I like the principle of utility classes. I just don't like how Tailwind names things. I actually would not make all these variables or class names. I make a minimal set of what is needed for the current project instead of a general purpose solution like this.
ah so you'd experiment with what values are needed and once you have them create your utility class names around them?
Not exactly experiment. As I am coding, I plan ahead and make what is needed, then I reuse it in other parts.
ah i didn't mean experiment sorry, that was the wrong word, for example if you had a figma file, you'd get all the spacing values and structure your utility classes around them instead of having general classes like you said?
Yes.
ah gotcha, much appreciate your help!
it being willdly used doesn't mean it's good...
I know. I didn't say it's good. I mentioned that because the OP wanted something that works. It has been tested on millions of projects, so we know it works.
vars + token
also if you are going to do .5 numbers you better off keep the 3 digits imo
--spacer-150 --spacer-50
I can't say why but I see --spacer-1-5 as a multi-value or something
Also best to set all those up and then have a var(--token, fallback) in your code
so like --spacer-lg: var(--space-700, 4.5rem);
π
or what ever too much to scroll to make it accurate to what you had haha
you get the idea.oh i never thought about doing it like that, i have a couple questions if that's okay?
if i have this for example what would be the benefit of the fallback for the spacer property?
would i need all the different space properties e.g.
--space-200: 1.5em; or could i just use their values as the fallback? for example
would i need to organize the spacer property into small, medium and large values, or can i integrate it into a utility class? for example
though i guess the last one is actually more than just simply adding a padding-block to test π
the fallback is just incase you are loading vars from another file and or they are not there for some silly reason.
Its kinda over the top honestly. I do it by habit cause I might be setting my tokens afterward so no value yet.
so like instead of just coding the hard value I put in the token name and a fallback so its got some styles while I'm coding the component out or what not.
Not sure if thats a bad habit or not but its def better than going back to add the var()
I got into it from doing 
I might be wrong in this logic but its mine lol I want a "contextual token" or a more human-readable token but also have the variation of variables to design with. It might be a bit redundant (not as much as it and a fallback but lol) but I find it helps me keep consistency better. like I don't have to remember was my main gutter 500 or 600?
Also its allows for like
--text-clr .... might not be the best token but you get the idea π
fill="var(--fill, currentColor/#defautColor)" on svg's I think lol
Like if I had a brand icon I wanted to keep their brand color on if I needed it π€·ββοΈ
i'm weird ik
I think fallbacks are cool too I might be wrong in this logic but its mine lol I want a "contextual token" or a more human-readable token but also have the variation of variables to design with. It might be a bit redundant (not as much as it and a fallback but lol) but I find it helps me keep consistency better. like I don't have to remember was my main gutter 500 or 600?
Also its allows for like
--text-clr .... might not be the best token but you get the idea π
--primary-txt is what I used yea thats better π€Ohh that actually makes a lot of sense
oh no I don't have one yet... sorry I'm still coming up with my own naming/system still too (i've been all over with naming things... cause naming shits hard)
yea --text-clr might actually fit for mine π€
cause I do --text-lg for sizes
gotta stew on that one
Ah so you prefer to have your gutter values and then set a value called letβs say
space-large to the gutter value with a fallback as you showed me?not quite so it would be more context than that
Would you mind explaining so I can understand?
so like I'm trying to come up with a better way still as I mentioned but I like to have some fluidity between my gutters/padding/spacers
but like you would have
--gutter: var(--gap-xl)
--card-pad: var(--gap-md);
not quite... but its close lol
you name things how you want but the idea is the same.
creat a token that has context to what it does
then have a set of vars you can assign to multiple tokens. that make sense for fluidity
So you are not changing things in 100 spots
or having all these different-sized margins/paddings on everything (something that scares me about TW)
Also keep in mind you don't need to go crazy if the project does not need that much "context"
sometimes just the var value does the trick
dont get all BEM thinking on it π (find a middle ground or "happy path")ah so for example you'd have a setup like this?
and the fluidity comes because you can do something like this?
sorry, meant to reply to the one under that π
so --gap would take the "main" gap
--gap: gap-xl;
so then if you wanted gap and gutter to flow together you can easy
or if they needed to be a bit different they can
sorry I know its hard to understand me sometimes and I'm doing to many things at once atm lol
really its less about the naming and more about the logic/function of them
You are trying to create a "design system" that allows you to control aspects of the site together or apart depending on your needs. That way when designers go... look that is 32px and thats is 24px you can be like oh right mb ...
--gap: --gap-lg;
xD
I'm still learning too mind you there are lots of design system experts out there that share different opinions and some of the same.Two awsome folks and a good watch.
Mike is a full time Design systems dev (meaning he pretty much only does CSS all day)
His favorite saying is "I write CSS so your devs don't have too" - Aparicio
and I love that π€£
You might pick up on some differences too and have ideas from watching that so do. And share back if you do β€οΈ
π± we grow together.
ohh so it'd look more like this? sorry if i keep getting this wrong, i'm trying to understand the best i can
no worries at all, you're a big help
oh awesome i'll check that out! will defo share back if i find anything!
I'm rewatching it now cause I'm in the middle of this myself hehe
Trying to build out a sensible system I might reuse for once π
normally I just toss up a few dozen props and call it a day
Ohhh haha weβre in it together then π
Would it be okay if you share your naming conventions once you find them? And if I manage to do anything with mine I can too π
Awesome much appreciate that ππ»
Naming things is hard
I thought you replied in this thread lol
to carry on from https://discord.com/channels/436251713830125568/1149025998554271864 I might also start looking at other Design system naming today when I need a break from designing
see what others are doing and find something that makes sense to my brain too.
i was just about to ping you here haha, yeah my fault
i'm still stumped on it too tbh
can't seem to find an organized flexible design for it that ties in with my flows and padding and other properties
@b1mind hope you don't mind the ping, i've been playing around with the one i've got, i know it may quite possibly be redundant or something haha but i feel like i'm getting at something even if it's a little off, anything you'd tweak? it's just those default value sorta things that bugs me, like
--spacing-100, they don't feel right to use
I'm still all over the place
Who would have thought .... naming things is so hard
<,<;;
yeah its quite the curve ball haha
I'm over here like... why do I have primary/highlight and font?
also I thought I had a mental model around how I wanted to do the "modifier" name first.... but now I'm second guessing lol
This looks great @b1mind
That seems like a pretty good layout though, definitely gives me some ideas, I have a question though as I see it being done differently sometimes-
whatβs the difference between doing
βprimary-clr: hsl(var(βpurple-5)); compared to βprimary-clr: 0, 0% 0%; for example?by not putting the hsl in the first tokens (vars) I can add opacity on them in the other.
Ohhh I see, and if you didnβt have opacity youβd use the other?
well no
kinda
so like --primary-clr-op: hsl(var(--purple), 0.5);
I might double back on doing it that way cause of two reasons though.
First is I've heard its almost always better to have the solid colors than a opacity for contracts. (so you would find the color value of the opacity on x back ground and get the color)
Second is you don't get to treat those as colors anymore in the editor as they are just values.
if you notice you don't see the color next to them
It's something I hadn't really played with before so I wanted to.
it does come in handy when doing overlays though xD
like darkening a picture background or dimming the screen for a modal bg.
Ah yeah I see, I notice some people rather than having the straight values like XYZ will set variables for the hue and lightness etc and have them there, then change those properties in a different section rather than the whole thing
Not sure if thatβs redundant or not though haha
yea π€·ββοΈ
Appreciate the help ππ»
what do you think of this sorta thing? i've kinda come to the conclusion that i'm going to have to set those space properties π
, any ideas on the
em and rem thing i've got going on too? i feel there's an easier way to do that sort of thing haha
only thing is make sure you want those gutters to grow with font size
em for next set and rem for root
like text flow sure probably
but like I have to sets of vars for mine so I can keep font flow spacing and gaps gutters seperate.
Cause I use rem for one and px for other π
padding* on a button in em/rem? sure maybe if that is your thing.
padding* on other elements ? #depends
I'm fighting with when I want padding for a spacer (to keep the bg color of the section) or margin flows
xD #devLife
Oh right yeah makes sense haha, should probably change the normal flow to ems
So you do a similar thing to me?
Hm yeah even iβd have to think about your one π
would you recommend a utility class for something like a padding block with this layout or simply just defining the padding block in the section?
Well, it's just a utility class so it won't really hurt but this how I like to think about it: padding is part of the element's content, just like font-size or line-height, it actually affects how the content within it is displayed. Therefore, padding should be part of the element's styles.
This is in contrast to margin which is not part of the element's content. You can use margin to push other elements and create space for the element but that's a layout issue, not content. An element should look good on its own and then you can apply margin from external sources: flex/grid gap, column system, utility classes, etc to position it according to the layout and other elements around it.
When I have an element that may need different amounts of padding when reused in different places, I like to use variants. For example
.hero-section, .hero-section-small, .hero-section-vertical, etc. I personally like BEM convention so this would be more like: .hero-section, .hero-section--small,.hero-section--vertical (just quick examples).
When I see this in my code I can already tell that the element not only can but is meant to be used in different places.
Of course, using a simple utility class may just solve the problem right then and there so... and in fact I actually do this quite a bit π
but always with a mental note to come back and "fix it later".That actually really helped a lot, thank you for the explanation and your time!
so for example, if i have a
padding-block that uses two different properties, is it more recommended to define the straight properties within the declaration or have two local properties for the top and bottom?
I don't think it's necessary, you can use the custom variables that you already have. If you need to use different values for them, you can always overwrite them inside that particular scope without affecting the rest of elements.
thereβs one different for the top and bottom, the padding is using two globally scopes variables defined in root, Iβm not changing the values of them, I was asking since I was using two if I should make two local ones for the top and bottom
Oh I see
Well, I guess if you're only going to make them available inside that scope... why not just write the values directly?
But nothing wrong with that approach, perhaps the only downside is that its a bit more code to read and keep track of
yeah very true, i think i'll go with writing the values directly then, thank you