Conversation
1ac0fa7 to
7ac9372
Compare
Builds ready [7ac9372]
Page Load Metrics (543 ± 64 ms)
|
| .nyc_output/** | ||
| .vscode/** | ||
| test/e2e/send-eth-with-private-key-test/** | ||
| *.scss |
There was a problem hiding this comment.
... was prettier linting our scss before now? 🤔
There was a problem hiding this comment.
it was... and I think we should re-enable it once we tweak some stylelint settings?
It was breaking apart the src: lines in the typography file into multiple lines and stylelint would then complain about that.
| @@ -0,0 +1,41 @@ | |||
| export const COLORS = { | |||
| UI1: 'ui-1', | |||
There was a problem hiding this comment.
The purpose of these first 6 colours seems unclear to me (the UI# ones, and the black and white).
If we're going to try to make this more easily theme-able in the future, then "UI1" could be more descriptive. And "black" might be confusing if it's a dark theme, where we might want to assign a lighter colour to it.
There was a problem hiding this comment.
The goal of the UI# is for exactly that, to make it so that the colors could be updated or even themed without changing the variable names or meaning. I do get your point about the black/white UI colors. I think we have a long way to go to get to a place where the color system supports easily swapping to a dark theme.
For example Material UI's palette color type
interface PaletteColor {
light?: string;
main: string;
dark?: string;
contrastText?: string;
}particularly of interest is the contrastText which is the biggest barrier to entry with switching from light/dark themes -- finding the right accessible color for text when a given background color is applied.
As for black/white bases, they are usually added to color systems (including material-ui theme.white/theme.black) Also, in our case ui-black is not #000 and in different themes what is considered "white" and "black" may be variations of the color and not #fff / #000
Happy to discuss more and get design team into the conversation as well.
There was a problem hiding this comment.
Interesting - maybe this relates to conventions I just don't have any experience with then. For example if I were designing a new UI and I had to choose a background colour and a border colour, I'd have no idea whether 1 or 4 were more suitable. Presumably there must be something more we can say about when each of these could be used.
There was a problem hiding this comment.
They are intended to be general-purpose colors for building UI and are used for font colors, borders, backgrounds, etc. If such a distinction could be made in usage I doubt a single name could cover it, or we'd end up with a very long list of color names -- some with identical values.
@rachelcope @cjeria @rickycodes @jakehaugen and I (if I'm forgetting anyone, my apologies) looked through some blog posts related to color systems at large organizations. In the end, we borrowed heavily from that research but took some liberties. This conversation predated the channel we created, and I'm going largely from memory here so I could be mistaken.
7ac9372 to
b7b60c3
Compare
Builds ready [b7b60c3]
Page Load Metrics (856 ± 49 ms)
|
Changes
versus
Both are currently valid, the later is more explicit the former is easier to type.
Having the typography variant is useful for the
Typographycomponent I am working on because I can loop through variants thusly:If the variant map changes then the Typography component automatically supports it.