Wish: more robust Color swatch handling

As 2024 unfolds, I’d appreciate upgrades to the swatch manager.

When using templates, we can define ‘Primary’ and ‘Primary Variant’ swatches. If saved blocs and brics reference these swatches, we can build out our pages, then make adjustments to these Primary swatches and the changes trickle down across all of the elements using them. Very straightforward.

However, I recently learned that this functionality is limited to only two swatches. I would very much like any named swatch to behave this way so that a template maker could build a Design System naming swatches like:

Light theme:
Light surface primary, Light surface primary variant, Light text primary, Light text primary variant.

Dark theme:
Dark surface primary, Dark surface primary variant, Dark text primary, Dark text primary variant.

I would also like to be able to organise the swatch manager a bit, maybe with groups that could be named and dividers in between.

I believe every new project should start with a few base swatches according to Design Systems that many use today. We’d have a default ‘Light’ group that is separated from a default ‘Dark’ group. Each would contain weights like 100, 200, 300…900. Very common across many design tools/systems.

Template makers could then leverage this when building themes, knowing that the naming convention remained constant. It would be very powerful and appreciated. And I don’t think it’s ‘way out there’ in terms of complexity to implement (famously always said by the one who doesn’t have to implement it…)

:clinking_glasses: to a great 2024.

Thanks.

3 Likes

There are 4 colours, Primary, Primary Variant, Secondary, Secondary Variant.

The concept here is to keep the list simple and easier to use, but it could be expanded.

I’ll bookmark this and see what I can come up with.

3 Likes

Ah, so already a 100% improvement to what I thought :blush: so that’s great!

As nice as it is to keep things simple, I’d like to offer the following quote from Homer Kelly:

“Demanding that something complex be ‘kept simple’ doesn’t make it simple. Only incomplete”

In all seriousness, I think that we’ve seen that when designing something like a webpage or a UI, and we’re considering all colors we need to cover light/dark, various shades and borders plus accent colors… we quickly run out of colors—even with 4.

I appreciate that you take it into consideration.

4 Likes

I think thats the challenge, keeping true to the Blocs approach, compared to how other apps may work, which can have more direct control of colour variables that Bootstrap uses for example. And Bootstrap 6 is probably going to see even more enhancements in these variables.

CSS variables are defiantly way more main stream now.

A lot of styling can be achieved with them, without creating a lot of additional classes. Many would suggest this is the approach you should first take when building your website, then add additional classes as needed.

By the way… love the quote.

1 Like

Yes, that might be the way to go. But there’s no way to connect user-defined variables to the swatch manager or the interface, like the inspector color picker, right?

1 Like