[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:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility, css
----------------------------+-------------------------------------

Comment (by notlaura):

 Copying some notes/ideas I added in @ryelle's
 [https://github.com/WordPress/gutenberg/pull/21999/files/a768092eba5f713a6839212311e20515010bbcff
 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 - I'm not totally sure what that would be, but perhaps
 a flavor of UI, maybe theme vs. Gutenberg vs. wp-admin:


 {{{
 .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 );
         }
 }
 }}}

 Aside: I believe `hsl` color values are most appropriate for design system
 colors, but need to confirm that. So pretend the above examples are hsl,
 maybe.

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

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