Closed mmailaender closed 8 months ago
Let's handle these 1 by 1:
Background colors vs page colors Good point. I think what we mean there is that page can have colored sections so it can be applicable there, but that's definitely more of an exception than a rule. I'll update this part.
faded vs non-faded Like mentioned in the docs, it's safe to use foreground colors on top of faded background. Non faded background colors won't have enough contrast with foreground and that's why they require onBackground colors for the text to automatically resolve to black or white. Would you rather group these two ideas here into a small table of sorts that compares them?
elevation Not sure about this one since as a concept implemented across many design systems, it's only responsible for different shades of gray in dark mode and it replaces the role of shadows used together with the color (shadow token names are aligned with the elevation colors). It might introduce a bit more naming alignment but those names will mean different things in the implementation.
Maybe what will help is the theming editor we've discussed before and I'm building it right now for the next release. So there is an opportunity to illustrate the meaning of colors there using real examples
I took your answers as an opportunity to do another deep dive into the topic 😉
I'm still in the middle, but I have found two points I want to bring up already.
For point 3: I found in Material Design 3
that they follow a consistent greying approach for light and dark for elevation (They call it surface colors) instead of defaulting all light elevations to the same color code.
But I wonder why you use different shades of colors in Reshaped
for borders
and background
? I haven't seen that somewhere else e.g. Material 3
. There, I have accent
, neutral
(used for both as far as I understand) and outline colors as system tokens
:
Good point about the border. I was thinking about this before and I understand why it works for material, but at the same time I saw a number of cases where elements with neutral/primary/etc backgrounds can have a slightly different border color. You can see it in practice even here on github:
(Which also made me notice there is some color artifact neutral button has at the corners 😆 )
For the elevation, I like the idea of bright and dimmed surface (as well as sunken elevation Atlassian does), but I've got to figure how that fits into the overall system, since material does it only for grayscale colors, while for others it only has container colors which is similar to the "faded" modifier
Created a project board item with v3 ideas where we will research updates to elevation https://github.com/orgs/formaat-design/projects/2/views/1?pane=issue&itemId=41516596
There are different tokens used for backgrounds, and it feels complex to understand the logic of when to use what and why so many additional background tokens exist:
Background colors:
But then why also a dedicated
page color
token?Almost every component I know has elements on top that use
foreground color
or another container that usesbackground-color
(Or should better useelevation-color
- see next point). Why then differentiate betweennon-faded
andfaded
?Elevation colors
For this, I want to use the analogy of a house in a top-down view to synchronize my understanding with yours: We have different floors, and on every floor, we have furniture. If all floors and furniture have the same color, you would not be able to identify any of them looking from the top. So we need contrast - we can use borders or different background colors for this. So, why not merge
background colors
withelevation colors
and provide one sleek approach that maintains the contrast?Then I would have only
background colors with different elevations
ANDforeground colors
The foreground colors would maintain their contrast ratio automatically based on the background color (Simplifying alsoforeground on background
) token.