Title: FFF – Make WordPress Core

---

#  Tag Archives: FFF

 [  ](https://profiles.wordpress.org/kburgoine/) [Kirsty Burgoine](https://profiles.wordpress.org/kburgoine/)
4:41 pm _on_ January 29, 2021     
Tags: 00a32a, 1ed14b, 3582c4, 72aee6, [core-css ( 192 )](https://make.wordpress.org/core/tag/core-css/),
f6f7f7, FFF   

# 󠀁[# Introducing CSS Custom Properties…](https://make.wordpress.org/core/2021/01/29/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](https://core.trac.wordpress.org/ticket/49999)
ticketticket Created for both bug reports and feature development on the bug tracker.(
[#49999)](https://core.trac.wordpress.org/ticket/49999) the [#core-css](https://make.wordpress.org/core/tag/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](https://core.trac.wordpress.org/changeset/50025)
thanks to the awesome work of [@ryelle](https://profiles.wordpress.org/ryelle/) 
and the rest of the [#core-css](https://make.wordpress.org/core/tag/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](https://make.wordpress.org/core/tag/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:

    ```notranslate
    -—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:

    ```notranslate
    —-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:

    ```notranslate
    --color-primary
    --color-error
    --color-warning
    --color-success
    --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:

    ```notranslate
    // 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.

    ```notranslate
    —-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](https://make.wordpress.org/core/tag/core-css/)
meeting every [Thursday from 10pm UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Core+CSS+Weekly+Chat&iso=20210204T22&p1=%3A&ah=1).

[#core-css](https://make.wordpress.org/core/tag/core-css/)

[#00a32a](https://make.wordpress.org/core/tag/00a32a/), [#1ed14b](https://make.wordpress.org/core/tag/1ed14b/),
[#3582c4](https://make.wordpress.org/core/tag/3582c4/), [#72aee6](https://make.wordpress.org/core/tag/72aee6/),
[#f6f7f7](https://make.wordpress.org/core/tag/f6f7f7/), [#fff](https://make.wordpress.org/core/tag/fff/)

 [  ](https://profiles.wordpress.org/notlaura/) [Lara Schenck](https://profiles.wordpress.org/notlaura/)
3:55 pm _on_ June 16, 2020     
Tags: [core-css ( 192 )](https://make.wordpress.org/core/tag/core-css/),
FFF, [summary ( 981 )](https://make.wordpress.org/core/tag/summary/)   

# 󠀁[CSS Chat Summary: 11th June…](https://make.wordpress.org/core/2020/06/16/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/joyously/) asked if this applies to properties
like CSS filters and blend mode, and [@kburgoine](https://profiles.wordpress.org/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](https://profiles.wordpress.org/michael-arestad/)
replied that he uses hex codes, and for colors named according to intent, it is 
only the accent color. [@ryelle](https://profiles.wordpress.org/ryelle/) linked 
to this [WordPress Colors CodePen](https://codepen.io/hugobaeta/pen/RNOzoV). [@nrqsnchz](https://profiles.wordpress.org/nrqsnchz/)
agreed that we should aim to use names that specify the use of the color vs. the
color itself.

[@michael-arestad](https://profiles.wordpress.org/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](https://github.com/Automattic/wp-calypso/blob/master/packages/calypso-color-schemes/src/shared/color-schemes/_classic-blue.scss)
and [an older version](https://github.com/Automattic/jetpack/blob/master/_inc/client/scss/calypso-colors.scss).

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](https://make.wordpress.org/core/tag/fff/) to `--
button-color`, and then`color: var( --button-color );`).

[@michael-arestad](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://penske-media-corp.github.io/pmc-larva/packages/larva-tokens/style-guides/sheknows.html#hr-color).

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](https://profiles.wordpress.org/michael-arestad/) offered to provide
guidance and access to Figma where needed.

### Latest and Greatest in CSS Link Share

[@kburgoine](https://profiles.wordpress.org/kburgoine/) shared [Hybrid positioning with CSS variables and max()](https://lea.verou.me/2020/06/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](https://make.wordpress.org/core/tag/summary/) [#core-css](https://make.wordpress.org/core/tag/core-css/)