Gutenberg: Color settings not styling block in editor

Created on 27 Apr 2020  路  11Comments  路  Source: WordPress/gutenberg

Describe the bug
In the editor, the color settings are not styling the selected block with colors from editor-color-palette. Choosing a custom color does work.

Colors display as expected on frontend.

Also not displaying here: https://wordpress.org/gutenberg/

To reproduce
Steps to reproduce the behavior:

  1. create text block. type text
  2. in block controls, go to "color settings"
  3. choose swatch for text color.
  4. text does not change color.
  5. choose swatch for background color
  6. background does not change color though padding is added

Expected behavior
Selected block should change color.

Editor version (please complete the following information):

  • Fresh WordPress 5.4
  • gutenberg plugin 7.9.1
  • twenty nineteen theme

Desktop (please complete the following information):

  • OS: MacOS 10.15.4
  • Browser: Safari 13.1
Needs Design Feedback [Block] Paragraph [Feature] Themes [Status] In Progress [Type] Bug

Most helpful comment

When we made the change, we originally thought it was just a 2019 bug and not something other themes have done. It makes me think we might need to write a post about that at least.

All 11 comments

Update: If you use one of the named colors from the Gutenberg style.css, it will work. If you use a different name and slug, it does not work. If you define a color with no name or slug, it also works.

I am sorry I don't know how to test this better.

@cramdesign Thanks for reporting this. I tried to replicate but am having trouble doing so. Specifically, I'm able to use custom colors for both the text and background colors without a problem:

Screen Shot 2020-04-28 at 1 46 33 PM
Screen Shot 2020-04-28 at 1 46 31 PM

To help me better understand what's going on, can you share screenshots of step 3 or step 5? Thank you!

Hello. The first screenshot shows that I am using one of the defined swatches for both text and background. I have highlighted the text to show that it is actually there, otherwise it is white text on a white background. Notice that there is actually padding added around the text to accommodate the background but the color does not show.

Screen Shot 2020-04-28 at 9 04 06 PM

The second screenshot shows the same text and area but I have used the custom color option.

Screen Shot 2020-04-28 at 9 05 02 PM

Note that this is with the latest plugin version. Without the plugin, using the version of Gutenberg shipping with WP 5.4, the color controls behave as expected as seen in the third screenshot.

Screen Shot 2020-04-28 at 9 11 15 PM

Thank you for clarifying @cramdesign! I appreciate it. I upgraded to 8.0 and could replicate this strangeness:

https://cloudup.com/cMFir5lur0W

Screenshot from another test site replicating the same thing:

Screen Shot 2020-05-01 at 3 21 31 PM

Marking this as a bug so we can get more attention here :)

As we make the editor and frontend match we need to make sure the markup and styles match too and part of that is to rely on the same techniques to apply colors on both frontend and editor. In the recent Gutenberg releases, we stop relying on inline styles to apply colors on the editor for color palettes to match the frontend. Some themes do more than just applying the colors when you select the palette color (it can apply both background and text colors at the same time) so it's important to rely on the same techniques used in frontend.

The issue here is that Twenty Nineteen was not loading its color palette stylesheet on the editor.

Can we create a trac ticket to track that?

The issue here is that Twenty Nineteen was not loading its color palette stylesheet on the editor.

Looks like we may have a similar issue in Storefront. https://github.com/woocommerce/storefront/issues/1339

The issue here is that Twenty Nineteen was not loading its color palette stylesheet on the editor.

We also have identified this issue in our child themes.

When we made the change, we originally thought it was just a 2019 bug and not something other themes have done. It makes me think we might need to write a post about that at least.

Just noting that this shows up with FSE in the Twenty Twenty theme for RC 8.1 too: https://cloudup.com/cftxR25j_Xb

It seems I have just reported the same problem here: https://github.com/WordPress/gutenberg/issues/22482

The issue as I report it is slightly different so I will copy my problem here.

If you use editor styles then the custom background and text colours do not work in the editor. They will (generally) display on the front end.

To reproduce
Steps to reproduce the behavior:

  1. Activate Twenty Twenty.
  2. Add a button.
  3. Change the button background to a colour (one of the built in ones).
  4. The button background will not change to a gradient.

Expected behavior
The background should change to a gradient.

Screenshots
Screenshot 2020-05-19 at 23 13 29

Why is this happening
This happens because inline styles are not used in the editor. Classes are used and they are applied to the root element. For example the gradient in the screenshot above uses :root .has-blush-bordeaux-gradient-background. When you add editor styles they get prefixed with .editor-styles-wrapper which has a higher priority than root and so the editor styles take precendence.

The reason the default styles work is they are enqueued like a normal stylesheet and not loaded as editor styles, so don't have the .editor-styles-wrapper prefix.

FWIW, this issue is different from https://github.com/WordPress/gutenberg/issues/22482 (what happens here is a specificity issue that https://github.com/WordPress/gutenberg/pull/22526 fixes).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

davidsword picture davidsword  路  3Comments

moorscode picture moorscode  路  3Comments

cr101 picture cr101  路  3Comments

ellatrix picture ellatrix  路  3Comments

aaronjorbin picture aaronjorbin  路  3Comments