[wp-trac] [WordPress Trac] #49999: Iterating on Admin Color Schemes

[WordPress Trac]

#49999: Iterating on Admin Color Schemes
----------------------------+-------------------------------------
 Reporter:  ryelle          |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  5.6
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  ui, accessibility, css
----------------------------+-------------------------------------

Comment (by kburgoine):

 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.

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

 3. 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`.

 2. 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! 🙂

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49999#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform