# Introducing CSS Custom Properties…

Introducing CSSCSS Cascading Style Sheets. Custom Properties to the WordPress Adminadmin (and super admin)

As part of the Iterating on Colour Schemes ticketticket Created for both bug reports and feature development on the bug tracker. (#49999) the #core-css team have been working on how to go about implementing the use of CSS Custom Properties in the WordPress Admin.

The first step of this task was to iterate on the existing colours used and reduce them down to a workable color palette. This work was committed to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. on Tuesday January 26th 2021 thanks to the awesome work of @ryelle and the rest of the #core-css team. This reduced the number of unique colours used from 199 to 99!

The next step now is to look at how we can use this work to create a colour palette using CSS Custom Properties and ensuring we have all of the relevant fallbacks. This is where we would really like to invite some discussion (and is the point of this post).

From discussions we’ve already had on various tickets and during the #core-css meetings, there are a number of options currently being considered.

Naming Custom Properties

We all know naming is hard! However, there have been a number suggestions already that could be considered.

The colours already have names (see this codepen for an easy reference: https://codepen.io/ryelle/full/WNGVEjw) so we could continue to use the same names. For example:

-—color-blue-20: #72aee6;
—-color-blue-40: #3582c4;

—-color-green-20: #1ed14b;
—-color-green-40: #00a32a;

We could, instead of using the actual colour name, implement using primary, secondary, tertiary names. For example:

—-color-primary-20: #72aee6;
—-color-primary-40: #3582c4;

—-color-secondary-20: #1ed14b;
—-color-secondary-40: #00a32a;

There was also a name proposal for hues in this post: https://make.wordpress.org/design/2019/11/26/proposal-a-new-color-palette-for-wordpress/ which looked like:

--color-background: light gray background used in WordPress.
--color-surface: white background used for UI elements.
--color-border: border color used on UI elements.
--color-on-surface: default dark gray text/icon color.
--color-on-surface-subtle: light gray text/icon color.

Implementing CSS Custom Properties.

So far the general approach to this, that has generated the most discussion and agreement, is to create a base colour palette and then apply those colours to properties named after their usage. Something similar to:

// Base color palette.
—-color-gray-0: #f6f7f7;
—-color-gray-100: #101517;

// Properties used in CSS.
—-body-background-color: var( —-color-gray-0 );
—-text-default-color: var( —-color-gray-100 );

// Application.
body-background-color: var( —-body-background-color );
color: var( —-text-default-color );

(Exact property names and colours used here are examples only)

This would give us the flexibility to utilise the dynamic nature of CSS custom properties to change the value of properties based on certain criteria, and without the danger of the name becoming misleading or incorrect.

I imagine that, which custom properties should be created in the abstracted layer applied in the CSS, would generate a lot of conversation. However, if there are other ways to implement custom properties that you feel may be worth exploring as well, please do still mention them.

Additional Considerations

One of the overall goals of this work is to ensure the admin is inclusive to everyone by utilising some of the newer features coming to CSS and honouring peoples individual system preferences. At the moment the focus of this is honouring dark mode but more customisation options are becoming available so how we name custom properties and choose to implement them needs to account for that. For example, this wouldn’t be suitable because the name becomes misleading.

—-colour-black-background: #000;

@media (prefers-color-scheme: light) {
    —-colour-black-background: #fff;

The other big consideration is that there are a number of alternative admin colour schemes already available, all of which should be able to take advantage of the use of custom properties once implemented. Therefore we need to keep the number of custom properties created concise and how we implement them needs to easily extendable.

As well as this we do also need to consider fallbacks for browsers that do not support CSS Custom Properties and this could impact how we name or implement them.

Next Steps

There is a lot of options here that could be discussed and the purpose of this post is to start some of those discussions and invite you all to give your opinions. So if you have any thoughts on this please do add them here and/or join in the live discussions in the weekly #core-css meeting every Thursday from 10pm UTC.


#00a32a, #1ed14b, #3582c4, #72aee6, #f6f7f7, #fff

CSS Chat Summary: 11th June…

CSSCSS Cascading Style Sheets. Chat Summary: 11th June 2020

Full meeting transcript on Slack: https://wordpress.slack.com/archives/CQ7V4966Q/p1591909237318500

I (@notlaura) facilitated the meeting.

Discussion on color naming with the design team

We started out by reviewing some goals of this color scheme initiative with regards to wp-adminadmin (and super admin):

  1. Easily create full-feature color schemes that apply to the entire wp-admin (e.g. dark mode)
  2. Improve existing wp-admin CSS

@joyously asked if this applies to properties like CSS filters and blend mode, and @kburgoine and I indicated that it would likely be limited to defining a base color palette and color values.

I then asked how the designers currently name colors in designs – @michael-arestad replied that he uses hex codes, and for colors named according to intent, it is only the accent color. @ryelle linked to this WordPress Colors CodePen. @nrqsnchz agreed that we should aim to use names that specify the use of the color vs. the color itself.

@michael-arestad linked to a couple of example projects where colors were organized into “sets”: the main colors (5-10 most common), a primary accent color, additional accent colors. Here is one example with multiple levels of abstraction and an older version.

I mentioned another goal – or perhaps an elaboration of what “easily create color schemes” means – is that creating a new color scheme should be a matter of updating a predefined set of variables with different colors values. One should not have to write any new CSS (save custom property definitions at a high level) to create a new color scheme, and to achieve this, multiple levels of abstraction will be required (e.g. assigning #FFF to --button-color, and thencolor: var( --button-color );).

@michael-arestad noted the importance of providing a range of lighter/darker versions of a colors to ensure folks aren’t coming up with slightly different shades of the same color, even though providing those options is important.

We discussed a next step of annotating some designs with potential color palettes and names – for example, a screenshot of wp-admin with the default color scheme and a screenshot in dark mode, with a Figma palette with the colors used in each. The intent of the annotations is not to determine specific color names yet, but to get an idea of the higher level “color buckets” or categories (e.g. color-primary, color-accent), and the UIUI User interface elements they may be applied to (e.g. --button-text-color, --sidebar-background-color).

Next, we talked about options for naming the variations in the colors – a couple of approaches mentioned were using terms lightest/lighter/light/dark/darker/darkest or using number 100-900 to allow for middle ranges. @ryelle mentioned another approach where 50 was used as a cutoff and above or below 50 indicated contrast with white/black, and we discussed the ideal of a naming system that would help ensure proper contrast ratio between colors. I shared an example of how we are handling our color naming at my job.

To conclude the meeting, I re-iterated / refined the goals of the color scheme initiative:

  • Creating a new color scheme should be similar to filling out a form with color values
  • All colors in the wp-admin should be controlled by the color schemes
  • Reduce the number of colors in use by providing default color palettes with varying shades

Our next steps are to start determining the “color buckets” and categories/mappings of the UI abstractions that will be used to apply the colors. We can start this process by annotating screenshots two screenshots (one of light mode and one of dark mode) with potential color names and corresponding color palettes.

Help Needed
Is someone with design knowledge up for creating these annotations? @michael-arestad offered to provide guidance and access to Figma where needed.

Latest and Greatest in CSS Link Share

@kburgoine shared Hybrid positioning with CSS variables and max() from Lea Verou (who’s website is using the default theme to great effect! 😄).

That was all for this week!

#summary #core-css