Size Change: +584 B (0%)

Total Size: 825 kB

_{compressed-size-action}

😍 I like this a lot.

What's the plan for WordPress Core here? I'm assuming we want to stay consistent. Should we create a trac ticket, make/core post for the next steps?

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:

I think core should overwrite the default one initially.

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?

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

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.

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:

When we build the plugin we replace the color

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
#1635bb → #11a0d2

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.

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.)

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.

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.

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:

1. One set of colors for that lands in packages and is consumed by WordPress core, 3rd party projects, or Storybook.
2. The alternative set is used only by the Gutenberg plugin.

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 process.env.WP_HIGH_LUMINANCE flag to control it if it's temporary :)

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 @wordpress/base-styles next to default. You should know better how much work it would be to update postcss plugin to consume this section. I think you authored this plugin, didn't you?

I'd love this to happen. Is there anyone who could help out?

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.

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?

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!