#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.
- 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.
- 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.
- 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)
Change History (151)
This ticket was mentioned in โSlack in #core-css by ryelle. โView the logs.
5 years ago
This ticket was mentioned in โSlack in #core-css by ryelle. โView the logs.
5 years ago
#4
@
5 years 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.
5 years ago
This ticket was mentioned in โSlack in #core-css by kirstyburgoine. โView the logs.
5 years ago
This ticket was mentioned in โSlack in #core-css by ryelle. โView the logs.
5 years ago
#8
@
5 years 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:
- Salesforce Lightning design tokens: โhttps://www.lightningdesignsystem.com/design-tokens/
- Skyscanner Backpack design tokens: โhttps://backpack.github.io/guidelines/colors#section_dynamic-palette
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
5 years ago
This ticket was mentioned in โSlack in #accessibility by audrasjb. โView the logs.
5 years ago
#11
@
5 years 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.
#12
@
5 years 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.
5 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
#15
@
4 years 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.
4 years ago
This ticket was mentioned in โPR #386 on โWordPress/wordpress-develop by โyouknowriad.
4 years ago
#17
- Keywords has-patch added
Trac ticket: https://core.trac.wordpress.org/ticket/49999
#18
@
4 years 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
@
4 years 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.
4 years ago
This ticket was mentioned in โSlack in #core-css by youknowriad. โView the logs.
4 years ago
โyouknowriad commented on โPR #386:
4 years ago
#23
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.
โyouknowriad commented on โPR #386:
4 years ago
#24
Ok, now I have the setup is correct for me. What's left is some minor tweaks to the colors.
โlaras126 commented on โPR #386:
4 years ago
#25
@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
โyouknowriad commented on โPR #386:
4 years ago
#26
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
โlaras126 commented on โPR #386:
4 years ago
#27
--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 years ago
#29
@
4 years 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.
- 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.
- 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.
- 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.
- 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
.
- 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 years ago
This ticket was mentioned in โSlack in #core-css by ryelle. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by afercia. โView the logs.
4 years ago
#38
@
4 years 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.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
#41
@
4 years 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
@
4 years 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
@
4 years 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
#45
@
4 years 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.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by afercia. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by audrasjb. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core by hellofromtonya. โView the logs.
4 years ago
#54
@
4 years 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 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by danfarrow. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #design by ibdz. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by hellofromtonya. โView the logs.
4 years ago
#65
@
4 years 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.
4 years ago
This ticket was mentioned in โPR #818 on โWordPress/wordpress-develop by โryelle.
4 years ago
#67
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.
4 years ago
โdanfarrow commented on โPR #818:
4 years ago
#69
The "back to the PR" link on the before & after page doesn't have an href
attribute, I just noticed
โryelle commented on โPR #818:
4 years ago
#70
@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.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by ryokuhi. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core by metalandcoffee. โView the logs.
4 years ago
#75
@
4 years 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 :)
@
4 years 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.
4 years ago
#78
@
4 years 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
@
4 years ago
(just opening a small parenthesis to say thank you for such an impressive work on screenshots)
#80
@
4 years 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
@
4 years 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
@
4 years 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
@
4 years 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:
- 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)
- Optionally, add "Gray 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
@
4 years 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
@
4 years 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
@
4 years ago
Ah, thanks for the explanation. I'm happy to defer to you and others on the next step! Thanks for your work.
โryelle commented on โPR #818:
4 years ago
#87
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core by francina. โView the logs.
4 years ago
#90
@
4 years 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
@
4 years 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
@
4 years 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
@
4 years 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.
4 years ago
#96
follow-up:
โย 107
@
4 years 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.
#98
@
4 years ago
- Keywords needs-dev-note needs-docs added
Adding needs-dev-note
and needs-docs
keywords :)
#99
@
4 years 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 go 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.
#100
@
4 years 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
@
4 years 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.
โryelle commented on โPR #818:
4 years ago
#102
Merged in [50025]
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by ryokuhi. โView the logs.
4 years ago
#105
@
4 years 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
#106
@
4 years 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.
#108
@
4 years 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
@
4 years 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
@
4 years 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 years ago
This ticket was mentioned in โSlack in #accessibility by ryokuhi. โView the logs.
4 years ago
#113
@
4 years 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:
- 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.
- 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.
- 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
@
4 years ago
I forgot to add links to the CSS that Sugar Calendar uses, as an example of one plugin's efforts.
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
@
4 years 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.
4 years ago
This ticket was mentioned in โSlack in #accessibility by ryokuhi. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by ryokuhi. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #accessibility by ryokuhi. โView the logs.
4 years ago
#121
@
4 years 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.
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by danfarrow. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by danfarrow. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by danfarrow. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by colorful-tones. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by notlaura. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by colorful-tones. โView the logs.
4 years ago
โcolorful-tones commented on โPR #386:
4 years ago
#137
I know this closed and deleted. I just wanted to note that โthe use of HSL came up again in today's #core-css Slack meeting.
I see a great benefit to having verbosity in colors. A single variable approach is super restrictive, but if we have agreed naming conventions then there is no reason for aliases.
transparency and if we break them down in to H, S, and L values then we can alter them, e.g. /* Red - #ff0000 */ --wp-admin-color-page-background-h: 0; --wp-admin-color-page-background-s: 100%, --wp-admin-color-page-background-l: 50%; --wp-admin-color-page-background-hsl: hsl(var(--wp-admin-color-page-background-h), var(--wp-admin-color-page-background-s), var(--wp-admin-color-page-background-l));
This ticket was mentioned in โSlack in #core-css by colorful-tones. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by colorful-tones. โView the logs.
4 years ago
This ticket was mentioned in โSlack in #core-css by codekraft-studio. โView the logs.
3 years ago
#141
@
2 years ago
@audrasjb @ryelle This updated colour palette never made its way into the design handbook: โhttps://make.wordpress.org/design/handbook/design-guide/foundations/colors/ . It would be great to get that page updated as it still details the previous colours.
#142
@
2 years ago
Absolutely! I don't have access to Make/Design but I'll share it during the next design team meeting if possible. Thank you!
This ticket was mentioned in โSlack in #design by audrasjb. โView the logs.
2 years ago
#144
@
17 months ago
@audrasjb @francisco It seems the colors are not updated yet in the Design Handbook. At least I could have not find the following changes, that got suggest from @audrasjb
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:
Does someone knows, if the current state of โhttps://make.wordpress.org/design/handbook/design-guide/foundations/colors/ is up to date?
#145
@
17 months ago
The colors in the handbook are indeed out of date, and overdue for an update. In fact I'd love to see in the near future a more easily findable central location for all things design (such as wordpress.org/design) that would include details like these.
At the moment the best way to find info on explored new colors are in โthe WordPress Design Library Figma, as well as โthe WordPress.org Design Library. As noted, I expect those to expand to a central and easily findable location.
That said, I would suggest there ould always be a "classic" color scheme with the existing colors.
Things to consider: