WordPress.org

Make WordPress Core

Opened 10 months ago

Closed 8 days ago

Last modified 5 days ago

#49999 closed task (blessed) (fixed)

Iterating on Admin Color Schemes

Reported by: ryelle Owned by: ryelle
Milestone: 5.7 Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-docs has-dev-note
Focuses: ui, accessibility, css Cc:

Description

There are a set of color schemes available for wp-admin, but no new scheme has been added since these were created. If we want to add accessible color schemes (high or low contrast, dark mode, etc), we quickly run into issues with the current (Sass variable-based) system.

  1. The Sass variables are calculated from a set of about 3 colors, and those calculations only work for similar colors.

See Midnight, which sets the minimum variables and the defaults work well. Contrast the light blue color scheme, which needs to override other variables. The functions make assumptions about color & context, things that work for dark colors don't work well for light.

  1. Specificity of the core styles makes it complicated to override colors.

The default colors are defined in the main CSS, so every color scheme needs to override that. Currently this is done with a base _admin.scss file, but if a scheme needs to override a specific rule, its styles need to be just as specific. (This shouldn’t have to happen, but like above, not every color variable works out, for example the light blue color scheme also needs to override CSS)

That base file also needs to be kept up to date with any core changes.

  1. Not all colors are controlled by variables.

Text color (outside of menu & links) are not controlled by variables (not even the $text-color variable). Neither are the colors that identify actions (like unapproved comments, or deleting a post). Probably more? These would need to be overridden for high contrast & dark mode schemes.

Given those issues, how should we move forward to create new admin color schemes? If you’ve written a color scheme, are there other issues you’ve run into? Other color scheme implementations you think work well?

Attachments (6)

Capture d’écran 2021-01-13 à 23.29.52.png (291.2 KB) - added by audrasjb 7 weeks ago.
small color change in admin menus hover color (not the same blue) — but hey! I find it better than before :D
button-primary.png (3.1 KB) - added by joedolson 5 weeks ago.
Button Primary
contextual-help.png (1.9 KB) - added by joedolson 5 weeks ago.
Contextual help
jjj-on-2021-02-10-at-14-52-16@2x.png (159.6 KB) - added by johnjamesjacoby 3 weeks ago.
1 of 3 - Sugar Calendar: Mode button and Chosen.js select styling
jjj-on-2021-02-10-at-14-52-40@2x.png (119.3 KB) - added by johnjamesjacoby 3 weeks ago.
2 of 3 - Sugar Calendar: sub-menu hover, horizontal line overlap
jjj-on-2021-02-10-at-14-53-03@2x.png (563.2 KB) - added by johnjamesjacoby 3 weeks ago.
3 of 3 - Sugar Calendar: current vertical tab, jQuery date-picker UI colors

Download all attachments as: .zip

Change History (129)

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


10 months ago

#2 @joyously
10 months ago

  • Component changed from General to Administration

Things to consider:

  • browser support
  • colors only? (or opacity to affect color)
  • define the main areas of an admin page and have foreground and background variables for each?
  • naming scheme for variables (back compat?)
  • type of color definition: hex, rgb, hsl
  • should the schemes enforce contrast ratio internally?

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


10 months ago

#4 @ryelle
10 months ago

I tried an approach with color schemes in Gutenberg that could be worth exploring, it uses postcss to generate a list of colors & shades. This basically just swaps out the sass magic for a custom theme function, it wouldn’t solve most of the issues above, but does modernize things a bit. It could get us out of the specificity hole, at least.

Here’s an example of how the prototype works.

Options passed into postcss:

{
    defaults: { primary: '#00f' },
    themes: { red: { primary: '#f00' } },
}

CSS file

button {
    color: theme(primary);
    background: theme(primary, shade-20);
}

The postcss plugin runs and generates the tints & shades by adjusting the lightness of the value as hsl & converting back to hex (prototype, doesn’t support opacity, would love for this to be smarter). The CSS it outputs looks something like this:

:root {
    --color-primary: #00f;
    --color-primary--shade-10: #00c;
    --color-primary--shade-20: #009;
    ...
    --color-primary--tint-10: #33f;
    --color-primary--tint-20: #66f;
    ...
}
body.admin-scheme-red {
    --color-primary: #f00;
    --color-primary--shade-10: #c00;
    --color-primary--shade-20: #900;
    ...
    --color-primary--tint-10: #f33;
    --color-primary--tint-20: #f66;
    ...
}
button {
    color: var(--color-primary);
    background: var(--color-primary--shade-20);
}

IE support is still an issue, depending on how much support we need there could be different solutions:

  • just the default fallback, no color schemes for IE
  • creating a separate CSS file with just the color values for each color scheme that's only loaded on clients that don't support custom properties (a postcss plugin could do this)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-css by kirstyburgoine. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


10 months ago

#8 @notlaura
10 months ago

A practice in design systems that use themes/color schemes is to have an additional layer of abstraction, like the current Sass variables. To expand on @ryelle's example, it would be something like this:

:root {
    --color-primary: #00f;
    --color-primary--shade-10: #00c;
    --color-primary--shade-20: #009;
}


body.default {
    --sidebar-color: var( --color-primary--shade-20 );
}


body.dark {
    --sidebar-color: var( --color-primary );
}

.sidebar {
    color: #00f; // See note below
    color: var( --sidebar-color );
}

The fallback can come from an additional PostCSS step (not sure of the specific package, but this definitely exists). For color schemes that require IE11 support (e.g. a default and those related to accessibility), PostCSS could output a different stylesheet per color scheme that contains the appropriate fallback.

We may want to think of this as an exploration of design tokens. To support themes, the design tokens can be abstract names for the colors, so in this the color primary. The token primary is assigned a color value and then applied to specific contexts, like sidebar-color. There would need to be guidelines as to how the color tokens relate to one another to ensure appropriate color contrast e.g. primary must always have a certain contrast ratio with secondary.

Here are a couple examples of this "abstract design tokens" from design systems:

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


10 months ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


10 months ago

#11 @notlaura
10 months ago

Copying some notes/ideas I added in @ryelle's PR to Gutenberg and discussed in the CSS chat on 5/21/2020.

A spec for registering the color schemes (we would need to consult with designers on the naming here). The workflow goal would be to have someone fill out this spec file and they have created a new color scheme:

themes: {
	blue: {
		primary: '#76765',
		secondary: '#asdhhd',
		accent: '#asdggg',
		error: '#f098asd',
		success: '#624yihfs',
		tints: {
			lightest: '99',
			lighter: '82',
			light: '72',
			dark: '30',
			darker: '21',
			darkest: '8'
		},
		shades: {
			shallowest: '70',
			shallower: '64',
			shallow: '60',
			deep: '39',
			deeper: '25',
			deepest: '10'
		}
	}
}

PostCSS would generate custom properties for us, like these:

.theme-blue {
	--color-primary: #76765;
	--color-primary--tint-darkest: #242ads;
	--color-primary--tint-darker: #23423;
	--color-primary--tint-dark: #987972;
	// and so on...
}

Then there would need to be a middle, mapping step to plug the color values in to the UI based on a context - I'm not totally sure what that context would be, but perhaps a flavor of UI such as theme vs. Gutenberg vs. wp-admin, or even variations on a component:

.some-other-context {
	--button-background-color: var( --color-primary--shade-darkest );
	--button-text-color: var( --color-primary--shade-lightest );
	--button-focus-background-color: var( --color-secondary--shade-darkest );
	--button-focus-text-color: var( --color-secondary--shade-lightest );
}

Then the component itself would be totally separate from any specific color:

.components-button {
	background-color: var( --button-background-color );
	color: var( --button-text-color );

	// state bindings for the colors -
	// Fallbacks are perhaps in a separate stylesheet
	&:focus {
		--button-background-color: var( --button-focus-background-color );
		--button-text-color: var( --button-focus-text-color );
	}
} 


One requirement to this kind of approach is assuring appropriate color contrast with automated tests.

Last edited 10 months ago by notlaura (previous) (diff)

#12 @joyously
10 months ago

The problem with your middle, mapping step is that it defines Custom Properties. Oh, I see that is also in your component CSS. If you keep all the definitions at the :root level, it is much easier to be backward compatible with old browsers.
I think that's much too complicated. To reduce the number of colors used in the admin, and the chance of inaccessible combinations, I would suggest that the variables be limited to pairs (foreground, background) of colors to use for the various areas or prominence (such as primary, secondary, and hover states). There is a concern of whether the notifications should be part of the admin scheme, or always the same (specifying both foreground and background).
Generating many shades for all colors is not reducing the total colors. There are other ways of modifying a base color, such as using transparency and/or black and white semi-transparent colors in addition to the base.

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


9 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


9 months ago

#15 @Joen
8 months ago

Wonderful effort.

In https://core.trac.wordpress.org/ticket/50504 I created some work to add a new color scheme which features higher contrast (though still just AA level), and I'd love for it to land in 5.5. But I would love to also help with work on this effort to refresh and SCSS the color schemes, perhaps move towards CSS variables so we don't have to have color schemes registered in both WordPress and the block editor.

I'd love to help both with refreshing existing schemes, and creating dark and light mode themes. I could easily see a "dark mode" version of https://core.trac.wordpress.org/ticket/50504, for example, and I'd be happy to help with the block editor component of that too.

This ticket was mentioned in Slack in #design by joedolson. View the logs.


8 months ago

This ticket was mentioned in PR #386 on WordPress/wordpress-develop by youknowriad.


8 months ago

  • Keywords has-patch added

#18 @youknowriad
8 months ago

  • Milestone changed from Awaiting Review to 5.6

Hey folks, I wanted to help a bit this with these efforts. I started the PR above. It's working surprisingly well for a quick PR.

Here's some of the important notes from that PR:

  • I only added a variable for $highlight-color (and few variations for it).
  • I merged several similar colors that are close together. (I think we can probably remove/merge more by tweaking styles but this should be a separate effort).
  • I didn’t add support for CSS variables for the menu colors, I think it's better to get the system in place with a single color and decide separately to potentially add new CSS variables. The one we're certain about is the highlight color.
  • This PR requires compilation already to get the “default colors” but I'm hopeful we can remove that by just embedding the :root default colors into a CSS file that is always loaded in the admin.
  • I mirrored the naming of the Gutenberg variables like discussed in yesterday's meeting.

Also, let's consider this ticket for 5.6

#19 @ryokuhi
8 months ago

Sorry, wrong ticket! If someone can remove the attached patch, feel free to do that.

This ticket was mentioned in Slack in #core-js by youknowriad. View the logs.


8 months ago

#21 @afercia
8 months ago

Related: #50575.

This ticket was mentioned in Slack in #core-css by youknowriad. View the logs.


8 months ago

#23 @prbot
8 months ago

youknowriad commented on PR #386:

Looks like something is preventing the postcss plugin to work properly. this started happening after the rebase. You can still get the feeling of the PR using the custom scheme colors but the default one is broken right now.

#24 @prbot
8 months ago

youknowriad commented on PR #386:

Ok, now I have the setup is correct for me. What's left is some minor tweaks to the colors.

#25 @prbot
8 months ago

laras126 commented on PR #386:

@youknowriad I'm thinking it would be advantageous for readability to use HSL values since they are semantic - what is the reason we cannot use HSL here? I remember discussing in the CSS chat - you had mentioned discussing with @joen:

HSL works but it would force us to have an API based on HSL colors, we want to have a more generic API where users just define a single variable.

Can you please expand on why we would not be able to have a generic API based on a single variable with HSL values? Is it because we don't want the API for color transformations to be in CSS custom properties?

I did find [an interesting example from Shopify's design system](https://github.com/Shopify/polaris-tokens/blob/master/src/color-factory.ts) that generates the color schemes from HSL starting with a configuration object for each color scheme like this:

primary: [
    {
      name: 'actionPrimary',
      description:
        'Used as the background color for primary actions, and as the fill color for icons and the text color in navigation and tabs to communicate interaction states.',
      light: {lightness: 47.3},
      dark: {lightness: 47.3},
      meta: {
        figmaName: 'Action Primary/Default',
      },
    },
    {
      name: 'actionPrimaryDisabled',
      description:
        'Used as the background color for disabled primary actions, and as the fill color for icons and the text color in navigation and tabs to communicate interaction states.',
      light: {lightness: 95, saturation: 0},
      dark: {lightness: 32},
      meta: {
        figmaName: 'Action Primary/Disabled',
      },
    },
...

And all colors schemes are stored in [a kind of manifest file here](https://github.com/Shopify/polaris-tokens/blob/master/src/configs/base.ts). My gut says that it will be a problem for design if they are restricted to generating schemes from a single value that has predetermined lightness/darkness values, so we will have to pass in additional information besides a single color.

So, whether or not that is in HSL, to support other color schemes with the same system, we'd have to pass in more than $color-primary to the mixin. Does that make sense? I'm kind of thinking as I'm writing :D

Last edited 8 months ago by notlaura (previous) (diff)

#26 @prbot
8 months ago

youknowriad commented on PR #386:

It's important to remember that CSS variables are APIs third-party users can use and not just an internal implementation. Ideally I think If I do this:

`
--wp-admin-theme-color: red;
--wp-admin-theme-color: #FF0000;
--wp-admin-theme-color: rgb(255,0,0);
`

All of these are expected to work from third-party users while if we rely on hsl it means we'd need three variables for each color:

`
--wp-admin-theme-color-h: something;
--wp-admin-theme-color-s: something;
--wp-admin-theme-color-l: something;
`

This is far from ideal to me, I'd rather offer variables for shades than forcing a very specific format you need to convert to for public APIs

#27 @prbot
8 months ago

laras126 commented on PR #386:

--wp-admin-theme-color: rgb(255,0,0);

That totally makes sense!

I see the readability gains as separate from the API point - so --wp-admin-theme-color: hsl(0,100,50);. Which would enable (what I consider to be) a more readable value for the color, e.g.:

--wp-admin-theme-color-light hsl(0,100,90);
--wp-admin-theme-color-base: hsl( 0, 100, 50 );
--wp-admin-theme-color-dark: hsl(0,100,20);

And the interface for whatever language comprises the API for the colors (Sass or JS), would be also be more semantic to work with e.g.:

$color-primary: 0,100;
$color-primary-shades: (
    'light': 90,
    'base': 50,
    'dark': 90
);
@mixin admin-scheme( $base, $shades ) {
    @each $key, $shade in $shades {
        --wp-admin-theme-color-#{$key}: hsl(#{$base}, #{$shade});
    }
}

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


8 months ago

#29 @kburgoine
7 months ago

So I spent a bit of time reading back through meeting chats and conversations on PR’s and I’m wondering if this whole topic has got a bit ahead of itself?

The recent conversations I’ve seen feel to me like we are discussing very specific issues that relate to a project that is much further along than this is. Maybe it's my misunderstanding so to better figure out what needs to happen to be able to use CSS custom properties in colour schemes, I decided to think about it from the beginning again.

And I thought I would share my thoughts here. If you’ve already covered this ground or you totally disagree that's completely fine with me, I just thought it might be worth taking a step back for a moment and considering. Feel free to ignore it 🙂

Some of this thinking was inspired because I recently re-read this article about how Stack Overflow built a dark mode: https://stackoverflow.blog/2020/03/31/building-dark-mode-on-stack-overflow/ and while a lot is not applicable to this, there is quite a lot that I think is. Most notably, they went back and refactored the use of colour throughout their CSS before trying to implement a dark mode, and I think that's what is needed here. Instead of focussing on how to implement a colour scheme using custom properties and the differences between schemes and modes, I think we should tie this back in with the CSS audit, use that to look at the current colour usage and see how it can be simplified and ultimately refactored so that it's in the shape needed to do cool things with it like dark mode or new colour schemes.

(apologies in advance if any of this seems niave, I’ve misunderstood anything or it's actually not at all achievable in a project of this nature)

Firstly, I would not look at SASS mixins or any of the cool features of postCSS yet, I would start by looking at purely what is achievable with native CSS. These things can be used later to iterate on the approach and improve it.

  1. So, the first step I think should be to look at the default colour usage in the admin (which has been done as part of the audit already), identify the main colours (including colours not currently included in schemes i.e background-colour) and try to whittle it down to a usable/manageable colour palette using CSS Custom Properties. Personally, I think an approach similar to what @notlaura mentioned above with an abstraction layer of properties that are then mapped to more specific properties would be a good way forward. Either way, this is the point I would think discussions around naming, and whether an abstracted layer of variables is needed would start to happen - and also discussions with design to ensure not too much is being stripped out. This colour palette would be scoped to :root and organised into one base stylesheet.
  1. I would then try to refactor the main admin colours used, to now use this new custom properties based colour palette. By taking advantage of the benefits of CSS Custom Properties we could hopefully remove a lot of duplication and specificity that just wouldn’t be needed and allow more elements to inherit properly (as @youknowriad demonstrated in his PR). I imagine there would be a lot of further discussion around naming and how much middle mapping to an abstraction layer of properties is required here as it starts to get implemented and there are real-world scenarios.
  1. Once a default colour scheme using CSS custom properties has been defined and applied, I would test it by creating a dark mode version using the feature query to ensure that all naming holds up and is readable when the values have changed and all areas of the admin that need to change colour, do. I wouldn’t expect this to be a completed piece of work in itself, that could be worked on and polished as a separate piece of work, this would be purely to see how well the work done stands up when the values are changed.

Once that has all been completed, a lot of the conversations and questions currently being discussed around general usage and naming will have been resolved. This would be a lot of work so it probably would be better to break down steps 1 & 2 into smaller bite-size chunks first to slowly edge toward that overall goal of a complete default colour scheme using custom properties rather than trying to do everything in one go.

  1. The next step would then be to create a test colour scheme that redefines the values of already established custom properties, but this time scoped to a theme class. For example, .theme-blue.
  1. There should be no need to create new custom properties because everything should be created in the default theme and can be referenced from the base stylesheet created in step 1. It would be fantastic if all people needed to do to implement a new scheme would be to fill out the spec file as suggested above, and all of the values update based on what has been defined as default. But, for example, in a darker coloured theme I suspect things like this:

--button-focus-background-color: var( --color-secondary--shade-darkest );
Would probably have to change to:
--button-focus-background-color: var( --color-secondary—shade-lightest );
making that possibly too restrictive:

But this is where I would imagine there would be more discussion. There would need to be a way to keep this flexible and possibly, this would be redeclaring the properties but scoped to the colour scheme class inside a file in each scheme, similar to how it's done now, or possibly not. But, if the base theme defaults have been architected properly it should still remove the need for people to start adding specific selectors to override what’s been done in the default theme (This is where the planning of middle mapped custom variables would be especially important).

In my mind, this is something along the lines of what the end result could be:

A new file (or re-use one if it's applicable) in ./wp-admin/css/colors.css
This file would contain CSS custom properties (and maybe IE11 fallbacks if postCSS can’t automate these?) that is then available for use in all stylesheets used for the admin.

The custom properties defined in this file would be not just the base colours / shades / tints but also all of those referred to as middle mapped properties. For example:

:root {
    --color-default: #000000;
    --color-default-inverted: #ffffff;

    --color-primary: #B1E2E4;
    --color-primary--tint-darkest: #6B8762;
    --color-primary--tint-lightest: #ECF6FE;

    --color-secondary: #E4C93F
    --color-secondary--shade-darkest: #81870A;
    --color-secondary--shade-lightest: #FEF6DC;
    // etc.

    --text-default-color: var( --color-default );
    --body-background-color: var( --color-default-inverted );

    --button-background-color: var( --color-primary--shade-darkest );
    --button-text-color: var( --color-primary--shade-lightest );
    --button-focus-background-color: var( --color-secondary--shade-darkest );
    --button-focus-text-color: var( --color-secondary--shade-lightest );
}

Totally accept that the naming here may be off, this isn’t meant to incite discussions around the names, only illustrate the point of how second level middle mapped properties would be very useful to keep a level of abstraction that prevents us having to use colour properties directly.

The second level set of properties keeps the readability because as mentioned above the default CSS for a button would look something like:

body {
    background-colour: var( --body-background-color );
    color: var( --text-default-color );
}

.button__primary {
    background-colour: var( --button-background-color );
    color: var( --button-text-color );
}

.button__primary:focus {
    background-colour: var( --button-focus-background-color );
    color: var( --button-focus-text-color );
}

This would create a complete default theme, which could then be tweaked later for any contrast / colour variation needed much more easily, and will make it possible for people wanting to create their own colour schemes to only need to redefine the values of the custom properties they actually need to change.

For example:

.theme-blue {
    // no need for default properties here, but maybe would in other schemes or modes.

    --color-primary: #3F75E4;;
    --color-primary--tint-darkest: #550A87;
    --color-primary--tint-lightest: #DCF2FE;


    --color-secondary: #E44F3F;
    --color-secondary--shade-darkest: #873A0A;
    --color-secondary--shade-lightest: #FEDCDC;
    // etc.

    // and only those elements whose value needs a different property to what is defaulted to.
    --button-background-color: var( --color-primary—shade-lightest );
    --button-text-color: var( --color-primary—shade-darkest );
    --button-focus-background-color: var( --color-secondary—shade-lightest );
    --button-focus-text-color: var( --color-secondary—shade-darkest );
}

Hopefully, my idea here isn’t totally off base (and this is the right ticket to have added it to), reading back through the last few weeks meetings I’ve agreed with a lot of what everyone has said, I just think we need to circle back to the beginning and look at an overall plan for implementation rather focussing on specific areas.

But, I may be totally wrong or this has already been done and I missed it. What do you all think?

Also, sorry for the massively long post. Apparently I can't write short ones! 🙂

This ticket was mentioned in Slack in #core-css by kirstyburgoine. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


6 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 months ago

#37 @afercia
6 months ago

  • Owner set to ryelle
  • Status changed from new to assigned

#38 @ryelle
6 months ago

A project status update, since we've been quiet on this ticket:

  • We have generally agreed that a solution using custom properties with appropriate fallbacks will be used, but getting any more specific than that right now is bikeshedding.
  • Instead, we're focusing energy on reducing the number of colors used in wp-admin, so that any color scheme can be more easily implemented. This is currently in progress, and we'll be looking for design and accessibility help to make sure we're using the right colors.
  • Once we've reduced the colors used, we can pull out those colors into custom properties.
  • The next step will be where the naming conversations and "what should be abstracted" will come back into play. It might make the most sense to reimplement the current admin scheme pattern using custom properties, then moving to expand from there. We can also see where Gutenberg is at this point.

More details for the current stage of the project:

  • I've written a tool using PostCSS which filters through CSS files and replaces every color in the file with the "closest" color in a list. Here's an example of how the matching works.
  • This will let us programmatically reduce the colors in wp-admin, using a color palette provided by design.
  • This PR is a demo, using a palette proposed in 2019. You can see some of the limits here. For example, there are no oranges in the palette, so pending comments don't have special backgrounds. Should the color palette be updated to add an orange hue? Another example, the light blue background of active plugins is converted to white. Maybe there should be a lighter blue, or maybe it's okay to only indicate active with the side border. Or maybe these questions are irrelevant, because we should use a different color palette.

There will be a post on make/design to get more input on the above questions in the next 24 hours.

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


6 months ago

#41 @youknowriad
6 months ago

We have generally agreed that a solution using custom properties with appropriate fallbacks will be used, but getting any more specific than that right now is bikeshedding.
Instead, we're focusing energy on reducing the number of colors used in wp-admin, so that any color scheme can be more easily implemented. This is currently in progress, and we'll be looking for design and accessibility help to make sure we're using the right colors.
Once we've reduced the colors used, we can pull out those colors into custom properties.

I have to share that this is exactly what my PR does. it was ready a few weeks ago. This how I feel now. Instead of reviewing a PR and helping land it which would have taken a few days maybe. We're going to spend way more time to just do the exact same work.

My PR already reduces the number of colors, adds the custom properties and setup the PostCSS plugin properly to support IE11. At the same time it also fixes a bug already on Core where people use the Gutenberg components relying on Gutenberg's custom properties on Core pages that don't use Gutenberg (This has been reported on Gutenberg).

I think WP-Admin usage of colors is small enough to be able to do this in a patch/PR.

If you all want to continue with your direction that will just take months to land for the same result, that's fine, I understand the need to take time to understand things properly but if folks want to achieve the exact same result in a week or two, I'm happy to help. So far I didn't feel like my contributions are welcome.

#42 @afercia
6 months ago

we're focusing energy on reducing the number of colors used in wp-admin,

Awesome. What I'd really like to see in WordPress is a tool to analyze all the core CSS (including Gutenberg and excluding third-party tools) and provide some data.

Five years ago in #35783 I tried a very non-scientific method just passing the admin minified stylesheet to cssstats.com and got some results: https://cldup.com/10C6ryGsN3.png

Re: colors:

  • 55 unique text colors
  • 49 unique background colors

Things are certainly changed in 5 years but I'm pretty sure the numbers are still pretty high.

Such a tool would greatly help in making well informed decision and establish a good plan.

#43 @ryelle
6 months ago

What I'd really like to see in WordPress is a tool to analyze all the core CSS (including Gutenberg and excluding third-party tools) and provide some data.

That's the other focus of the CSS group, a tool to generate audit reports of the core CSS 🙂 You can see more effort there on this ticket: #49582, and the reporting tool is being worked on in github. @notlaura posted the start of a report page yesterday.


I have to share that this is exactly what my PR does. … We're going to spend way more time to just do the exact same work.

Not exactly — we're trying to reduce the number of colors, whereas your PR seems to replace colors with PostCSS variables. The PostCSS setup will definitely be useful once we've figured out the color palette, but for now we're trying to take a more holistic view of how different colors are used.


The post I mentioned before has been posted on make/design: Reducing colors in core

#44 @afercia
6 months ago

Thanks for the info @ryelle! Looking forward to #49582 🎉

#45 @youknowriad
6 months ago

The PR does reduce the colors used as well, it limits the main color variations (shades) used to only 4/5 per color. (The same used on Gutenberg already)

This ticket was mentioned in Slack in #core-css by kirstyburgoine. View the logs.


5 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 months ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


5 months ago

#52 @hellofromTonya
5 months ago

  • Keywords needs-testing added

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


4 months ago

#54 @hellofromTonya
4 months ago

  • Keywords early added
  • Milestone changed from 5.6 to Future Release

From scrub today, Beta 1 is tomorrow. Punting this ticket to Future Release. This one is a potential early 5.7 candidate.

As Helen noted:

Yeah this is unfortunately really hard to judge without (dun dun dun) visual regression testing…

As Garrett noted:

Ya I believe the discussion in #core-css was to try for early 5.7

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

This ticket was mentioned in Slack in #core-css by danfarrow. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-css by danfarrow. View the logs.


3 months ago

This ticket was mentioned in Slack in #design by ibdz. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


3 months ago

This ticket was mentioned in Slack in #core-css by hellofromtonya. View the logs.


3 months ago

#65 @hellofromTonya
3 months ago

  • Milestone changed from Future Release to 5.7

After talking with @ryelle, moving this ticket into the 5.7 milestone and keeping it marked as early as:

oh, definitely early — it will need a lot of feedback, and we haven’t managed to get much with the branch as it is

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 months ago

This ticket was mentioned in PR #818 on WordPress/wordpress-develop by ryelle.


3 months ago

This is part of a longer project in cleaning up core's admin CSS; eventually making color schemes easier and a dark mode possible. This collapses all colors used in the CSS to one of the colors listed in this color palette. This was initially automated, with some very basic manual cleanup. This should be visually checked for contrast and if anything's off with the design.

See some before & after screenshots here.

Trac ticket: https://core.trac.wordpress.org/ticket/49999

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


3 months ago

#69 @prbot
2 months ago

danfarrow commented on PR #818:

The "back to the PR" link on the before & after page doesn't have an href attribute, I just noticed

#70 @prbot
2 months ago

ryelle commented on PR #818:

@danfarrow Thanks for catching that— I put up the page before the PR was created, and forgot to update it.

This ticket was mentioned in Slack in #core by lukecarbis. View the logs.


2 months ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


8 weeks ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


8 weeks ago

This ticket was mentioned in Slack in #core by metalandcoffee. View the logs.


7 weeks ago

#75 @audrasjb
7 weeks ago

Great work @ryelle 🙌

I tested your PR and the changes are almost unnoticeable. I was only able to notice the color change in the WP Admin Menu main navigation (not the same blue).
Also, everything looks good in terms of accessibility.
This is a big win for WordPress Core, thank you.

On my side, this patch is ready to go 🌟

Everyone please help testing this PR so this can be committed early in the release cycle :)

@audrasjb
7 weeks ago

small color change in admin menus hover color (not the same blue) — but hey! I find it better than before :D

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


7 weeks ago

#77 @ryelle
7 weeks ago

  • Keywords needs-design-feedback added

#78 @ryelle
7 weeks ago

I've added the "needs design feedback" label for the reduced colors work in the attached PR. There's the screenshot above, and also a set of before and after screenshots here.

#79 @audrasjb
7 weeks ago

(just opening a small parenthesis to say thank you for such an impressive work on screenshots)

#80 @Joen
7 weeks ago

Thank you for working on this.

In my opinion one of the most important tasks for refreshing the admin color schemes, outside of moving to CSS variables, is to reduce the total number of colors in use. Instead of having 30 different shades of gray, less than ten is vastly preferable simply because it forces just a little bit of consistency and systematization across the interface. I hope and believe this cleanup will be a first of many that help streamline the interface.

I would also echo audrasjb above, those before and after screenshots are really helpful.

Why did the settings page background gray change so much? See https://cloudup.com/ie3QGqTnW5D

I'm not personally afraid of design changes, but I do think they're best made in a more holistic way. Just on its own, this change of gray is very visible, and while we're no-where near AA contrast levels, the relative shift in contrast still puts it in that space where it's so light, it might as well just be white.

I may have answered my own question, that it's a result of a reduction in grays. And my objection is not a strong one at all. It just seems like a tiny step backwards.

Thanks again.

#81 @ryelle
7 weeks ago

Why did the settings page background gray change so much?

All the page backgrounds changed, because they're currently #f1f1f1, and the closest available grey is #f6f7f7, same with the attachment modal - that's #f3f3f3. These colors came from this color palette, where "Gray 0" is #f6f7f7 and "Gray 5" is #dcdcde (which is too dark, IMO). Maybe we need a "Gray 2": #ececed?

Personally, I like the lighter background, but I see your point that it's barely there now.

#82 @Joen
6 weeks ago

The colors proposed are beautiful. Nevertheless I missed the aspect of this effort where the colors were not only reduced and made into variables, but updated as well. I don't see that as fundamentally problematic, nor a blocker for this effort to land. But I did want to highlight that the block editor uses neutral grays, as part of this effort https://github.com/WordPress/gutenberg/issues/18667

The grayscale is perhaps the most re-used set of colors, across the different themes, especially as the palettes gets reduced to primarily grays and spot colors. For that reason, I would love to see the grays converge with what the block editor does.

It also happens that the shades of gray currently used for the block editor have a #f0f0f0 that is very close to the currently used background, #f1f1f1. Here's a before/after https://cloudup.com/c6yY1OATMmY

The full sheet of colors is shown here: https://github.com/WordPress/gutenberg/blob/master/packages/base-styles/_colors.scss

Whether here and now, or later, there's an opportunity to unify here.

#83 @ryelle
6 weeks ago

I'm happy to tweak the colors, but I think we need more greys in core than Gutenberg — I quickly ran the replacement with these greys, and found a few issues due to the fact that there are no greys between #1e1e1e and #757575

  • The admin menu is lacking contrast around submenus, except in the secondary submenu which has a lot of contrast :)
  • The secondary text color uses #757575, which doesn't have enough contrast against the grey background (that color barely passes on white)

The design team did approve this original palette, so I think we have two options:

  1. Go ahead with the color updates as currently exist in the PR and screenshots, and once more of core is cleaned up we could start bringing in the greyscale greys to replace the blue-greys (perhaps as other GB style patterns also move into core)
    • Optionally, add "Gray 2": #ececed (this is halfway between Grey 0 and Grey 5)
  2. Discard this PR, create more greys in the gutenberg palette, and spin up another replacements PR to use those new colors.

I'm happy to work closer with a designer to create a more comprehensive set of greys, but I do think approach 1 makes more sense.

#84 @Joen
6 weeks ago

Thank you for looking at that.

I don't think there's any reason to discard the work here, much less can do. The only color that looks starkly different is the settings background color, and even keeping the current one as is, or replacing with f0f0f0, seem like fine intermediate options. Followup work, and I'm happy to help here, could then look at a palette unification. With all the hard variable work done, such things can come together fast.

#85 @ryelle
6 weeks ago

With all the hard variable work done

No variables have been created yet - the PR we're talking about here is this one, #818 CSS: Reduce colors used in wp-admin (I regret not creating a separate ticket for this sub-project).

Creating the variables will be the next step after this, since we want to create a system that will allow for more flexible admin color schemes.

keeping the current one as is, or replacing with f0f0f0

I'll defer to you here, but would it be strange to have one monochrome grey when the rest of the greys in this palette are slightly blue-grey? That's why I was suggesting #ececed.

#86 @Joen
6 weeks ago

Ah, thanks for the explanation. I'm happy to defer to you and others on the next step! Thanks for your work.

#87 @prbot
6 weeks ago

ryelle commented on PR #818:

Based on feedback on the ticket, I've added another valid grey, #f0f0f1, to be used as the page background color.

https://i0.wp.com/user-images.githubusercontent.com/541093/105386621-9aa25b00-5be2-11eb-9e2f-b77af17351d0.png

https://i0.wp.com/user-images.githubusercontent.com/541093/105386617-98d89780-5be2-11eb-984b-b8df7cc18a50.png

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


6 weeks ago

This ticket was mentioned in Slack in #core by francina. View the logs.


6 weeks ago

#90 @hedgefield
5 weeks ago

  • Keywords commit added; needs-design-feedback removed

Looks good to me, @Joen and @melchoyce agree, so I think we can mark this for commit!

#91 @Joen
5 weeks ago

Thank you ryelle for your work. While I had some thoughts on the gray, I love that there's movement on the color schemes again. I hope we revisit them all and polish them up and continue refining on a more ongoing basis!

#92 @audrasjb
5 weeks ago

  • Keywords needs-testing removed

Thank you to the design team for your work and really helpful feedback 😎 On tech side, I think we are also good to go. @ryelle I think we can commit it so we can start to test it on the wild to find potential issues/edge cases 👍

#93 @ibdz
5 weeks ago

Thank you @ryelle for your hard work. The screenshots are really helpful. I think everything works well!

Only few changes can be noticable by human eyes eg. the comment row background, the red text link inside the row (trash / spam), the lightest gray background (which is solved now).

I can't wait to see the next iteration on the Admin Colors (CSS Variables) and Colors Unification.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


5 weeks ago

#95 @ryelle
5 weeks ago

In 50025:

Administration: Standardize colors used in CSS to a single palette.

This is part of a larger project in cleaning up core's admin CSS. This collapses all colors used in the CSS to one of 12 blues, greens, reds, and yellows, 13 grays, pure black, and pure white. The colors are perceptually uniform from light to dark, half of each range has a 4.5 or higher contrast against white, the other half has a 4.5 or higher contrast against black.

Standardizing on this set of colors will help contributors make consistent, accessible design decisions. The full color palette can be seen here: https://codepen.io/ryelle/full/WNGVEjw

Props notlaura, danfarrow, kburgoine, drw158, audrasjb, Joen, hedgefield, ibdz, melchoyce.
See #49999.

#96 follow-up: @ryelle
5 weeks ago

  • Keywords early commit removed

Removing commit & early after [50025]. Any issues with the new color palette should be brought up in new tickets - we'll re-focus this ticket back on CSS custom properties & color schemes.

#97 @ryelle
5 weeks ago

  • Keywords has-patch removed

#98 @audrasjb
5 weeks ago

  • Keywords needs-dev-note needs-docs added

Adding needs-dev-note and needs-docs keywords :)

#99 @johnjamesjacoby
5 weeks ago

Nice to see all of this cleaned up.

Dropping a note here to say that the official Dev Note for visibility is really important to many plugin authors. Anyone who has put in the extra work in their plugins to match the core UI colors exactly now has a bunch of extra work to do during beta to keep up.

Maybe a before & after list of the previous color and the new color, so that folks can easily find/replace in their own CSS files.

Also, plugins who want to support 5.7 and 5.6 and earlier will need some guidance on how best to do that in their CSS. Do they ship completely different files? Can they variableize ahead of time? Some advice on how best to proceed – and be prepared for what’s coming next so they don’t need to redo this again in 5.8 – would be excellent.

Last edited 5 weeks ago by johnjamesjacoby (previous) (diff)

#100 @audrasjb
5 weeks ago

@johnjamesjacoby thanks for your comment and for pointing out some specific needs concerning the dev note 🌟

As Docs focus lead for 5.7, I can confirm this dev note is already marked as a top priority. We should be able to publish it around beta 1 or 2. Of course, I'll get in touch with @ryelle for specific insights.

#101 @ryelle
5 weeks ago

@johnjamesjacoby these are good prompts, thanks! Do you have plugin(s) in mind that would be affected by this? (asking for some concrete examples so we can have a clearer picture about the upcoming variable-ization)

I just briefly wrote up a PostCSS tool which can be used on any CSS file to either replace or create a second CSS file with the 5.7 colors - this is essentially the same process that ran over core, so it should make the same matches in plugin CSS. We can expand on the write-up and include it in the dev note if it's helpful.

#102 @prbot
5 weeks ago

ryelle commented on PR #818:

Merged in [50025]

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 weeks ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


5 weeks ago

#105 @joedolson
5 weeks ago

Couple broadly applicable contrast issues noted with new color scheme:

1) Primary button color: 4.08:1 contrast.
2) Contextual help link: 4.20:1 contrast

Last edited 5 weeks ago by joedolson (previous) (diff)

@joedolson
5 weeks ago

Button Primary

@joedolson
5 weeks ago

Contextual help

#106 @audrasjb
5 weeks ago

  • Keywords needs-patch added

Good catch.
Following Ryelle’s color palette, I'd suggest:

Primary buttons:

  • Background color: replace #2271b1 with #135e96
  • Border color: replace #2271b1 with #135e96
  • Hover background color: replace #135e96 with #0a4b78
  • Hover border color: replace #135e96 with #0a4b78

Help tab buttons:

  • Font color: replace #787c82 with #646970

I tested those combinaisons. It works fine visually and it's AA compliant for both large and small text.

#107 in reply to: ↑ 96 @audrasjb
5 weeks ago

  • Keywords needs-patch removed

Replying to ryelle:

Removing commit & early after [50025]. Any issues with the new color palette should be brought up in new tickets - we'll re-focus this ticket back on CSS custom properties & color schemes.

Oh sorry I missed that comment. Opening a new ticket right now.

#108 @hellofromTonya
4 weeks ago

  • Type changed from enhancement to task (blessed)

Reclassifying the refinement of this effort to task as we are past Beta 1 (ie hard stop for all enhancements).

#109 @ryelle
4 weeks ago

@hellofromTonya The only remaining task on this ticket for 5.7 is to make sure a dev note happens - any tweaks to the new colors are happening on #52402.

Once the dev note/docs are taken care of, we can move this to a 5.8 milestone for custom properties work (which is being discussed on make/core).

#110 @hellofromTonya
4 weeks ago

After discussions with @ryelle, this ticket will remain an epic for the overarching discussions and planning of the initiative while the work itself will be contained in sub-tickets linked to this one. The classification of task (blessed) fits well for an epic that covers multiple release milestone cycles.

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


4 weeks ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


4 weeks ago

@johnjamesjacoby
3 weeks ago

1 of 3 - Sugar Calendar: Mode button and Chosen.js select styling

@johnjamesjacoby
3 weeks ago

2 of 3 - Sugar Calendar: sub-menu hover, horizontal line overlap

@johnjamesjacoby
3 weeks ago

3 of 3 - Sugar Calendar: current vertical tab, jQuery date-picker UI colors

#113 @johnjamesjacoby
3 weeks ago

@ryelle hey there! I've attached 3 screen shots of some unique styling in Sugar Calendar.

It is my hope that these screen shots will help highlight ways that plugins have needed to copy existing color scheme colors to integrate them into their own designs. The red squares draw attention to color scheme specific CSS included in a single plugin that will need to be changed to match the updated colors in 5.7.

(As a preface, I empathize with why these changes were deemed necessary. I understand that admin styling can and will change. I understand that plugins take or certain risks and responsibilities when opting into supporting admin color schemes. Ultimately, I will make sure my plugins work with all WordPress versions, because I believe it's the right thing to do. It is not my intent to diminish anyone's efforts. I only hope to provide contextual feedback about the result of them in my specific field.)

Because, as we know, WordPress does not (currently) supply simple semantic classes that can be easily applied to custom UI elements (think .left-border-fresh or something), and because there are no variables that plugins can easily use, every plugin needs to do their own due diligence to make sure their custom UI elements fit in with all color schemes. It's not enough to just assume "Fresh" or blue all of the time, everywhere.

This means when changes are made to WordPress core color scheme styling, plugins usually will not automatically inherit very much of those color changes, and is likely a major reason behind why colors are changed so infrequently. (Previous changes in (I think?) 5.2 caused a similar set of maintenance problems.)

The batch of changes related to this specific issue introduces some unique challenges for all plugins who add support for the core color schemes, and I'll try to number them below:

  1. If the goal for 5.8 and later is to use CSS variables, that makes the 5.7 release a single unique approach to CSS styling. That means plugins will need to support 3 different styling decisions: 5.6 and earlier, 5.7, and 5.8 and later.
  2. Slightly tweaking the colors between versions means that schemes like "Fresh" and "Blue" ultimately mean something different for 5.6 and earlier, and 5.7 and later. Using the API as intended, I would expect the changed schemes to be "Fresh Modern" or "Blue Modern" or something else. They are simply different schemes, albeit very similar to their 5.6-and-earlier siblings.
  3. I acknowledge that very few users or people will notice. Of those who do notice, even fewer will complain to me about the colors of my plugins being slightly off. But, these small changes echo through-out the plugins who are working hard to provide the very best experience to their users, resulting in doubling or tripling the effort required for 5.8.

I'm not in a position to make a recommendation on anything that can or should change in the 5.7 release cycle to improve any of my findings. I don't think it makes sense to revert anything, or wait until 5.8, especially since this has been soaking in trunk for a while now, and I'm the only one with this perspective so far. It's safe to say the footprint is relatively small.

Thank you for reading 💙

#114 @johnjamesjacoby
3 weeks ago

I forgot to add links to the CSS that Sugar Calendar uses, as an example of one plugin's efforts.

  1. jQuery Datepicker
  2. Chosen.js Select
  3. Sub-Navigation
  4. Meta-Box

Changes to the 5.7 color schemes mean all of these chunks of CSS now need to be copied to target specific versions of WordPress for the old-Fresh and new-Fresh differences.

For context, I'm using Sugar Calendar as my example because it includes so many different CSS dependencies. Each of these are separate libraries, and are also used in several other plugins that I've worked on (including Easy Digital Downloads, WP User Profiles, and a few others)

Sorry for the notification noise everyone. Thank you again.

#115 @johnbillion
3 weeks ago

This is a meta question but I haven't seen it mentioned yet.

#0073aa has been the "WordPress Blue" for a while now and it's used all across wordpress.org. It's detailed here: https://make.wordpress.org/design/handbook/design-guide/foundations/colors/

Are there plans to change this colour or is this change restricted to just the admin area? ie. will the official "WordPress Blue" be changing?

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


12 days ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


12 days ago

#121 @hellofromTonya
8 days ago

  • Resolution set to fixed
  • Status changed from assigned to closed

After checking with @ryelle, there is no further changesets needed for this ticket in 5.7. Only the dev note is pending.

To prep for 5.7 RC1, closing this ticket. After RC1, will reopen on the 5.8 milestone. Why? Closing with 5.7 as the milestone reminds us to get the dev note done in 5.7 while getting it out of the changes needed workflow.

#122 @audrasjb
8 days ago

  • Keywords has-dev-note added; needs-dev-note removed

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.


5 days ago

Note: See TracTickets for help on using tickets.