Try: High-luminance default colors #20460
Conversation
jasmussen
requested review from
ajitbohra,
chrisvanpatten,
jorgefilipecosta and
youknowriad
as code owners
|
Size Change: +584 B (0%) Total Size: 825 kB
ℹ️ View Unchanged
|
packages/base-styles/_colors.scss
Outdated
| @@ -31,7 +31,7 @@ $medium-gray-text: #757575; | |||
| $light-gray-secondary: #ccc; | |||
| $light-gray-tertiary: #e7e8e9; | |||
| $theme-color: theme(button); | |||
| $blue-medium-focus: #007cba; // @todo: Currently being used as "spot" color. Needs to be considered in context of themes. | |||
| $blue-medium-focus: #3858e9; // @todo: Currently being used as "spot" color. Needs to be considered in context of themes. | |||
There was a problem hiding this comment.
Let's try to find a way to compute this based on "theme" (otherwise the alternative schemes are a bit broken)
There was a problem hiding this comment.
I pushed a fix. There really aren't that many shades of blue used here, but what shades there are should take from this now, right?
jasmussen
force-pushed
the
try/g2-colors
branch
from
ccb92ea
to
471d54d
Compare
|
😍 I like this a lot. |
I think core should overwrite the default one initially. |
|
It looks fresher. I like it. And yes...please be consistent with core... 😍 |
|
I updated to use theme colors, but kept the update to the default theme:
Here's Sunrise:
Here's Midnight:
This brings an excellent segue to the conversation on the plan for the core project. Honestly, every color theme here deserves an update, not just the default one. The Midnight one is lovely, but the idea of using the red spot color for buttons is perhaps not the best, as it indicates "danger". That aspect is unchanged, but worth bringing up. Matías plan makes sense:
That is, we can move forward with the fresh blue for the Gutenberg project itself, but we create a Trac ticket to add CSS to the core project to override these colors back to the #007bca color that the rest of the admin interface ships with. This keeps things consistent, even if it does mean anyone using the block editor as part of WordPress will get the lower-luminance colors, and even if that means the majority of users won't see these blues in the near future. It seems like a trac ticket to suggest that is the next step here? |
I don't think it's a great idea personally, because that variable usage can change here. We can add new components using this variable or update existings ones but we won't think that we need to do a trac ticket for each one of these changes to update the override. |
@youknowriad Here's an idea:
Can you help me do that? As it is now, there's a primary and a secondary color, that's all that's left, and the rewriting would need to do this: #3858e9 → #007cba But we could even simplify the base-styles further, as you can see the G2 UI reduces the need for many colors. We could make it a single spot color that's used everywhere, so all we'd have to do is this: #3858e9 → #007cba Let me know what you think. |
|
@jasmussen When Core consumes the styles, they are already built into CSS, so it's not just a single place or two, it's everywhere the variable is used and the only way for Core to override is to add a stylesheet overriding all the places where the variable was used. |
|
This would be before core. A different build for the playground and the plugin / core using a different base color. |
Yes, this is potentially the solution. Have two separate CSS outputs for the packages. I wonder about the performance impact on the build time. |
|
Would it make sense to run it only when creating the plugin bundle? (Then master would get the updated blue, but the plugin would get the WordPress blue.) |
jasmussen
force-pushed
the
try/g2-colors
branch
from
3c45c78
to
1438033
Compare
|
Rebased this to just freshen it up:
I could use help with the next steps. |
|
Rebased this and updated the screenshot in the PR ticket just as a refresher. I love the new color, I think it would be a great default for contexts outside of WordPress. But because it needs dev help to make that happen, I'm guessing this PR will go stale eventually, and so I extracted a small change into #22261 which can easily go in soon. |
These are colors that are explored through the G2 visual refresh (see #18667). The color change does a few things: - It is chosen and balanced against the rest of the visual refresh. - It reduces the overall color palette, removing secondary colors used for toggles or checkmarks, unifying on a single blue. - It increases contrast against white, quite a bit, which is good for toggles, focus, form widgets and buttons. The new blue has a contrast of 5.61:1 compared to 4.57:1 for the previously used WordPress blue (#007cba).
|
cc @gziolo since you were working on the CSS support for scripts. For context: we need a way to generate the stylesheets for two color schemes. One style to be used on "Core" with the default core colors (existing colors), and one to be used in the plugin with the high-luminance default colors. |
Does it mean, we want a different config depending on the context, i.e:
Do I get it correct? |
|
@gziolo yes, I guess npm users might also want to opt-in into the "plugin's" set |
|
Does it have to work like this forever or it's only until the plugin and WP core align? It's important because we could use |
|
I'm not sure how realistic is it to expect Core to use these colors everywhere anytime soon. That said, the requirement is that npm consumers could choose one or the other which means an env variable won't work, we'd need to ship both. |
|
It feels like we could add a new section to |
|
I'd love this to happen. Is there anyone who could help out? |
In #22727 (comment) we discussed how this PR might not be the approach we want to take after all. The intent of this PR is to bake in the high luminance blue color by default, so environments that use the block editor outside of wp-admin inherit this color. But wp-admin should still override it with existing brand colors. A slightly different approach would be to allow the environment that includs the block editor to provide this color, rather than rely on a default (which there might still be). This might involve some PostCSS magic that @gziolo has been thinking about. Ideally this should work in a way that is more conducive to theming — not with a ton of colors, maybe just a single spot color. |
Assuming it's fine to use CSS variables, the simplest solution here would be to use a CSS variable and change its value depending on the context. I know the #core-css folks on Core are experimenting with CSS variables for admin theme colors which would solve this issue. |
|
I'd love to move to a CSS variable. |
|
How about creating a new separate color scheme for the admin? |
I.e. new blue by default but overridden by an admin color theme? That could work too. |
|
Yes, it would be great to even have a new default and leave the rest alone for now. |
|
Closing in favor of #23048! |
These are colors that are explored through the G2 visual refresh (see #18667).
The color change does a few things:
The new blue has a contrast of 5.61:1 compared to 4.57:1 for the previously used WordPress blue (#007cba).
Before:
After: