WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 20 hours ago

#49999 assigned enhancement

Iterating on Admin Color Schemes

Reported by: ryelle Owned by: ryelle
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch needs-testing early
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?

Change History (60)

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


7 months ago

#2 @joyously
7 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.


7 months ago

#4 @ryelle
7 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.


7 months ago

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

#8 @notlaura
7 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.


7 months ago

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


7 months ago

#11 @notlaura
6 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 6 months ago by notlaura (previous) (diff)

#12 @joyously
6 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.


6 months ago

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


6 months ago

#15 @Joen
5 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.


5 months ago

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


5 months ago

  • Keywords has-patch added

#18 @youknowriad
5 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
5 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.


5 months ago

#21 @afercia
5 months ago

Related: #50575.

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


5 months ago

#23 @prbot
5 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
5 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
5 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 5 months ago by notlaura (previous) (diff)

#26 @prbot
5 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
4 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.


4 months ago

#29 @kburgoine
4 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.


4 months ago

This ticket was mentioned in Slack in #core-css by ryelle. 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 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 #accessibility by afercia. View the logs.


3 months ago

#37 @afercia
3 months ago

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

#38 @ryelle
2 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.


2 months ago

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


2 months ago

#41 @youknowriad
2 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
2 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
2 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
2 months ago

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

#45 @youknowriad
2 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.


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 #core-css by notlaura. View the logs.


7 weeks ago

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


7 weeks ago

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


6 weeks ago

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


6 weeks ago

#52 @hellofromTonya
6 weeks ago

  • Keywords needs-testing added

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


6 weeks ago

#54 @hellofromTonya
6 weeks 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.


5 weeks ago

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


4 weeks ago

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


3 weeks ago

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


2 weeks ago

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


8 days ago

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


20 hours ago

Note: See TracTickets for help on using tickets.