Opened 5 years ago
Last modified 3 weeks ago
#49930 new enhancement
Replace wp-admin color schemes with CSS custom properties
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | |
Focuses: | ui, accessibility, css | Cc: |
Description
There has been some discussion in the #core-css channel on Slack around changing the colours used for the colour schemes to use CSS Custom Properties. There are a number of complexities and issues that need to be considered before this could happen. This ticket is to capture those conversations here.
CSS custom properties have a lot of benefits including future-proofing for when media queries focussing on accessibility features are more heavily used. For example: @media (prefers-color-scheme: dark) {}
However, the biggest drawback with using CSS Custom Properties is the lack of support in older browsers: https://caniuse.com/#feat=css-variables shows no support for IE 6 - 11 and therefore a strategy for this would also have to be considered.
Some tickets/resources that already exist that could affect this discussion are:
- https://core.trac.wordpress.org/ticket/26691 Admin Color Schemes: generic classes for colors
- https://github.com/ryelle/admin-color-schemes / https://wordpress.org/plugins/admin-color-schemes/ Admin colour schemes plugin
- https://wordpress.org/plugins/dark-mode/ Dark mode feature plugin
(This is not an exhaustive list, only what has been mentioned in Slack already)
Also see this discussion in Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1586792806203800
and https://wordpress.slack.com/archives/CQ7V4966Q/p1586793176207300
Change History (49)
This ticket was mentioned in Slack in #core-css by kirstyburgoine. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#4
in reply to:
↑ 2
@
5 years ago
Replying to afercia:
I'd like to remind there are plugins (and maybe themes) that use or extend the existing scss variables. I'm not sure the existing scss-based color schemes can be "replaced" as that would likely break any third-party code that is using them.
Admittedly, using 'replace' in the ticket title might be a bit misleading here. In order to support IE11 there would need to be fallback colours for browsers that don't read the CSS Custom Properties. Depending on the strategy decided, I would imagine that existing scss variables would still be used for that purpose and would then provide the compatibility needed for existing themes and plugins.
However, that could raise the potential problem of the Custom Property overwriting an existing scss variable if, how it has been scoped means that it is actually a different colour to the value stored in the scss variable. The dynamic nature of custom properties makes it so that it's not as easy as having a direct replacement.
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 afercia. View the logs.
5 years ago
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 notlaura. View the logs.
5 years ago
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 alexstine. 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 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 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
#21
@
4 years ago
Update:
This post provides a good overview of progress so far: https://make.wordpress.org/core/2021/05/10/css-custom-properties-project-update/
We have been working on documentation and information for contributors here: https://docs.google.com/document/d/1Z0Wo1W0ZQwFJYPcJ8GlsubA9uKhcFdT8ifYnso82z9I/edit#
For contributions, each person "claims" a file to work through. That list so far is:
admin-bar.css - @ryelle
admin-menu.css - @ryelle
buttons.css - @ryelle
common.css - @ryelle
forms.css - @danfarrow
dashboard.css - @notlaura
site-health.css - @dryanpress
login.css - @dryanpress
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 dryanpress. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-css by dryanpress. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-css by robertg. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by dryanpress. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by danfarrow. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by danfarrow. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by wazeter. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by dryanpress. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by danfarrow. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by dryanpress. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by wazeter. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by wazeter. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by wazeter. View the logs.
3 years ago
This ticket was mentioned in Slack in #design by joyously. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by notlaura. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by notlaura. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by notlaura. View the logs.
3 years ago
#40
@
3 years ago
We've been keeping track of the project status in this Google doc.
As of December 9, 2021, our next steps and remaining tasks are:
- Review and merge pull requests on Kelly's wordpress-develop fork.
- Once unified on a single branch, we need to look for duplication and opportunities to normalize and consolidate. A natural by-product of one author per-file is we didn't collaborate on naming and sharing properties.
- We need to make some decisions around handling rgba() and box-shadow values.
- We need to address PHP and JS files that need to be reviewed and appropriately upgrade to Custom Properties if need be.
- We need to consider the best way for existing Core Admin Color Schemes to leverage this API.
- We need concise documentation to explain what's been done, how to leverage it and methodology/guidance for other contributors to maintain and expand on this API.
- We need to add the --experimental prefix prior to merge.
- We need to set goals and ongoing tasks (if any) to address while the --experimental API is in the wild. We also need to set project and community expectations for how the experimental API should be leveraged, when we recommend not using it and how migration to a stable set of properties will happen. Should we have a fallback where we map experimental properties to stable ones? If so, should that be opt-in or temporarily opt-out with the goal to sunset?
- Are there any properties that should permanently remain experimental, “legacy,” or “internal”? Where we wanted to address them today, but the intention is to deprecate over time as we move towards a normalized palette? Keeping a non-official prefix on them could signal that intention, discourage adoption and reduce risk of that deprecation being a surprise.
- How can we provide examples (like the suggestion of new Admin Color schemes to demonstrate) and documentation to set this project up for success and communicate timeline?
This ticket was mentioned in Slack in #core-css by notlaura. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-css by notlaura. View the logs.
3 years ago
#44
@
3 years ago
@sabernhardt suggested that we maybe merge #55898 into this ticket as well. It would then mostly be about letting developers target CSS variables for colors used for notices e.g. success, warning, error, and, info.
If you have agreed on how to name the variables, it might also be developed separately but would be kept consistent in the approach on this ticket. As #55898 is much smaller and has a different aim than this ticket IMHO.
How can I help?
#45
@
3 weeks ago
I just created a new ticket unaware of this one, apologies, to start this work which seems incredibly similar. I don't want to duplicate but also this work was 3 years ago and seems on another repo. Would I be able to get an update on where things got? It feels like this covers a bit more than I am proposing which is a simple variable approach in https://core.trac.wordpress.org/ticket/62872. I don't want to duplicate work though.
My proposal is to go all in on variables using sass over css custom properties. This might be the wrong approach based on this tickets conversations and thoughts. If we are jumping right in with CSS variables I can get behind with that. I was going with Sass because they were there already and the need to have variables is so required.
This ticket was mentioned in Slack in #core by joemcgill. View the logs.
3 weeks ago
#47
@
3 weeks ago
I just want to mention that some packages already use CSS custom properties based on the active color scheme. (All pages that load wp-components or other similar stylesheets).
These are the variables that are currently output (this is the SASS mixing used to print these variables based on the current admin scheme).
@mixin admin-scheme($color-primary) { // Define RGB equivalents for use in rgba function. // Hexadecimal css vars do not work in the rgba function. --wp-admin-theme-color: #{$color-primary}; --wp-admin-theme-color--rgb: #{hex-to-rgb($color-primary)}; // Darker shades. --wp-admin-theme-color-darker-10: #{darken($color-primary, 5%)}; --wp-admin-theme-color-darker-10--rgb: #{hex-to-rgb(darken($color-primary, 5%))}; --wp-admin-theme-color-darker-20: #{darken($color-primary, 10%)}; --wp-admin-theme-color-darker-20--rgb: #{hex-to-rgb(darken($color-primary, 10%))}; // Focus style width. // Avoid rounding issues by showing a whole 2px for 1x screens, and 1.5px on high resolution screens. --wp-admin-border-width-focus: 2px; @media ( -webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { --wp-admin-border-width-focus: 1.5px; } }
The purpose of the ticket I think shouldn't be about inventing a new system, the system already exists, the tool to generate these variables exist, what is missing is to include this CSS in all WP-Admin pages and not just the ones using these specific stylesheets.
I want to mention that there were also several other efforts in the Gutenberg repository to expand on this and introduce theming/branding for the components package, which IMO is just the same thing as the admin color schemes.
So the ideal here would be to start small and just output these already existing CSS variables everywhere in the admin.
#48
@
3 weeks ago
Thank you @youknowriad for that perspective. Based on today's conversation in core the approach should be now:
- Create a core post outlining the plan. This will likely be very minimal and start with just colors, using what we have today.
- Consider how light we can take things now that browser support is there as called out by @joedolson.
That won't negate or close any of this work and should also respect and draw on it.
We have a few sources to draw on in doing this but starting is key. If we start we might be able to get a small aspect of this in for this release even.
The rejuvenation of this is done on the shoulders of the work here, not against. So I feel doing under this ticket makes sense. If that isn't suitable we can always pivot to another. We should learn from the work even a few years ago.
I'd like to remind there are plugins (and maybe themes) that use or extend the existing scss variables. I'm not sure the existing scss-based color schemes can be "replaced" as that would likely break any third-party code that is using them.
I'd tend to think a more viable approach would be:
Adding the
accessibility
focus as the accessibility team is interested in shipping new color schemes for specific accessibility needs, e.g.: low contrast, high contrast, possibly more.