Perhaps the most basic and obvious use of CSS custom properties is design tokens. Colors, fonts, spacings, timings, and other atomic bits of design that you can pull from as you design a site. If you pretty much only pull values from design tokens, you’ll be headed toward clean design and that consistent professional look that is typically the goal in web design. In fact, I’ve written that I think it’s exactly this that contributes to the popularity of utility class frameworks:
I’d argue some of that popularity is driven by the fact that if you choose from these pre-configured classes, that the design ends up fairly nice. You can’t go off the rails. You’re choosing from a limited selection of values that have been designed to look good.
I’m saying this (with a stylesheet that defines these classes as one-styling-job tokens):
<h1 class="color-primary size-large">Header<h1>…is a similar value proposition as this:
html {
--color-primary: green;
--size-large: 3rem;
/* ... and a whole set of tokens */
}
h1 {
color: var(--color-primary);
font-size: var(--size-large);
}There are zero-build versions of both. For example, Tachyons is an it-is-what-it is stylesheet with a slew of utility classes you just use, while Windi is a whole fancy thing with a just-in-time compiler and such. Pollen is an it-is-what-it is library of custom properties you just use, while the brand new Open Props has a just-in-time compiler to only deliver the custom properties that are used.
Right, so, Open Props!
The entire thing is literally just a whole pile of CSS custom properties you can use to design stuff. It’s like a massive starting point for your styles. It’s saying custom property all the things, but in the way that we’re already used to with design tokens where they are a limited pre-determined number of choices.
The analogies are clear to people:
My guess is what will draw people to this is the beautiful defaults.
What it doesn’t do is prevent you from having to name things, which is something I know utility-class lovers really enjoy. Here, you’ll need to continue to use regular ol’ CSS selectors (like with named classes) to select things and style them as you “normally” would. But rather than hand-crafting your own values, you’re plucking values from these custom properties.
The whole base thing (you can view the source here) rolls in at 4.4kb across the wire (that’s what my DevTools showed, anyway). That doesn’t include the CSS you write to use the custom properties, but it’s a pretty tiny amount of overhead. There are additional PropPacks that increase the size (but they are also super tiny), and if you’re worried about size, that’s what the whole just-in-time thing is about. You can play with that on StackBlitz.
Seems pretty sweet to me! I’d use it. I like that it’s ultimately just regular CSS, so there is nothing you can’t do. You’ll stay in good shape as CSS evolves.
I’ve been contemplating openprops actively since it’s come out. I’ve also found Pollen which is similar but covers a smaller set of things from first perusal.
My challenge is wrapping my brain around a property library that prescribes values to me. I realize the values are generally nicely scaled and generally awesome, but this also was an issue I had with Material Design. Even if I didn’t, every designer I’ve ever worked with at a company has had their own values (colors, fonts, sizing scales, etc.) that they would want me to implement (if I’m the FE developer).
But I think this is just something I need to contemplate more as OP definitely packs some very nice conveniences and has the whole postcss unused variables sister package too.
I think what would make this sort of tool a killer is a super convenient theme roller that you use to seed the values with. What do you think Chris?
Looks like it is customizable:
Which you’d almost surely do on a “big” project. I admit my brain doesn’t usually go for the “pick from a pre-selected pile of values” thing, but that’s my own weirdness and I think the industry is showing they actually like that.
Perhaps what might ease the over-the-fence thing would be something like a Figma plugin that means that designers are choose from the same list of possible values as developers are.
Yes, I see that quote. Honestly, I think that statement is a bit confusing. I feel uncomfortable speaking on Adam’s behalf so I have to preface this with a bit “I think”, but here’s my take on that statement:
“Map the props from JS”
I think what’s being asserted is that you could literally update the values in the javascript configuration files to whatever you like and recompile essentially. Totally valid. I’d actually consider something like this but I’m pretty sure 97%+ folks will not :smile:
“customize builds” — I actually believe to do this you’d need to fork the repo and point to something other then
lib:all:https://github.com/argyleink/open-props/blob/main/package.json#L74
You can see he has a lot of smaller package scripts for building individual minified stuff.
Also, I asked about this here https://github.com/argyleink/open-props/discussions/119
The other thing is from chatting back and forth with Adam he seems to still be adding to this library and constantly tweaking it to make it better (obviously a good thing!). So, I would be surprised if at some point if he hears enough feedback he’d add something more convenient to allow for customizations.
But that brings to your point Chris which I believe is correct that many folks prefer the prescribed values (probably even more so since unused ones can be postcss jit away).
I also agree the bi-directional Figma design tokens dream has to be coming soon. I mean, that’s what that whole W3C group is teeing up so guess we’ll see. Something native to Figma / Sketch et al is certainly going to be the ideal.