Color Schemes: Add color schemes via CSS custom properties

[frontdevde]

This PR is part of a series of PRs aiming to provide support for Color Schemes in Calypso.
This PR focuses on adding color scheme support via CSS custom properties.

General

Notable additions in this PR:

• This PR adds the plugin postcss-custom-properties to the postcss build step
• The options for autoprefixer and postcss-custom-properties are combined in a dedicated postcss.config.json config file in the project root
• A new file stylesheets/shared/_color-schemes.scss that contains the color schemes
• A dark and light color scheme are added and demonstrated on the Masterbar

Considerations

• enable instant preview of the selected color scheme
• easily switch between color schemes via a single class
• define the styles for a new theme in a single location
• neatly integrates into the current CSS architecture
• minimal impact on overall CSS file size and build complexity
• keep default theme exactly as it is
• treat it as a progressive enhancement (current theme remains the default)

For a more detailed description of the feature, the chosen approach and its advantages feel free to check out my post on the subject: p4TIVU-75d-p2 (internal reference).

Hat tip to @folletto for a good idea that resulted in the solution presented here, which offers an even better developer experience than the initially suggested one. :)

How to test

• Visit https://calypso.live/?branch=add/color-schemes/add-style-portion or test locally.
• Navigate to the Accounts Settings page and scroll down to the Admin Color Scheme section.
• Depending on whether the browser supports CSS custom properties, the Admin Color Scheme Picker will be present or not (for browser support see http://caniuse.com/#feat=css-variables)
• Select a color scheme to change the appearance of the Masterbar
• Save to persist or reload without saving to discard your selection

Suggestions as to what to test

• Do the Color Schemes work in all browsers that support custom properties (see browser support)?
• Is the Color Scheme Selector on the Account Settings page hidden when viewing on a browser that doesn't support custom properties (aka does the feature detection work)?
• Is the responsive behavior sufficient?
• Is the selection being persisted when saved? Is it being discarded when reloading without saving?

Notes

This PR currently compares its changes to PR #17307. This is so the changes can be easily identified. The following PRs (in chronological order) need to be merged prior to this PR:

PR #17157: Color Schemes: Add new form components as basis for color scheme switcher
PR #17200: Color Schemes: Add Color Scheme Picker
PR #17259: Color Schemes: Add Color Scheme Picker to Account Settings
PR #17307: Color Schemes: Add selected Color Scheme to Layout
PR #17310: Color Schemes: Add Feature Detection

This PR will be pointed at master once all of the above have been merged.

Design Review

I'd like to use this PR to also get some design review on the visual elements introduced in this and the PRs mentioned above. I'm thus also posting some additional screenshots here of the visual elements that are being introduced by the Color Scheme PRs.

Form Components: Form Radio with Thumbnail & Form Radios Bar

devdocs/design/form-fields – first introduced in PR #17157

Using several FormRadioWithThumbnail components will list them vertically. For a nicer visual appearance, they can be wrapped in the FormRadiosBar which will display them in a horizontal grid. The FormRadiosBar also provides a nicer developer experience for both normal and thumbnail radios as they can now be passed in as an object.

Blocks: Color Scheme Picker

devdocs/blocks/color-scheme-picker – first introduced in PR #17200

This is added as a block with its potential future of becoming a per-person per-site selection in mind. That would involve adding more components like e.g. a site selector.

Note: I created the theme previews in Photoshop, that's why they are currently PNGs. I've already noted down converting them to SVG as a future todo. Or if you'd like to help with that... :)

Thanks for reading! 🚀

[frontdevde]

Referencing issues #457, #16699 & https://github.com/Automattic/wp-desktop/issues/320 for the sake of continuity.
The PR #15731 they referenced was closed in favor of this one.

[folletto]

Can we add a comment regarding the need of preserve?

[folletto]

Excellent. Can we add a short version of that explanation to the file comments – so people are aware in the future that we are walking around that edge? :)

[ehg]

Do we need this now?

[frontdevde]

I left it in there in case one of the CSS steps e.g. editor wants to back out of using any further postcss plugins apart from autoprefixer. So it's more left as an option, it's not a necessity for the current build. Want me to remove it? :)

[ehg]

I think we need to regen shrinkwrap here? npm run update-deps

[frontdevde]

Done and pushed 👌

I'm wondering though if npm run update-deps hasn't been run in a while. It updated quite a bit more than just the postcss-custom-properties:

https://github.com/Automattic/wp-calypso/pull/17366/files#diff-36018a6a9e1de1798516799b84841318

[frontdevde]

Looks like the initial install with --save should've updated the shrinkwrap. I'm going to investigate why that did not happen in this case.

[frontdevde]

OK, I reverted back to a state prior to this PR and ran npm install --save for postcss-custom-properties again. This time it triggered the shrinkwrap update automagically like it should as per the docs. Not sure why that didn't happen the first time around, wondering if it has to do with me editing the css build steps in the package.json at the same time.

Either way this time it only added the dependencies it actually should. So I decided to do an interactive rebase, delete the old shrinkwrap commit and add the new one. Issue should be resolved now 👍

[spen]

Awesome work - this looks much more reasonable, thanks for looking in to this! :)

[kwight]

Took a spin through this on macOS+Chrome and it looks great – wasn't able to save though:

[frontdevde]

Hey, @kwight 👋 Thanks for letting me know 👍
It's working on my end but this seems to indicate that there might be an issue when a user doesn't have a saved color scheme setting yet. Will investigate further :)

[matticbot]

@frontdevde This PR needs a rebase

[frontdevde]

Commenting for continuity: The issue where the selection couldn't be persisted was solved in one of the preceding PRs. Once those are merged into master, this one will be pointed at master so we can confirm the fix is working.

[frontdevde]

Closing this PR in favor of newer PRs (see references above).