Colors assigned as 'preset' colors do not render correctly in the editor: Are assigned both STYLE values and CLASSes.

[pbking]

When a 'preset' color is selected as the background color for an element BOTH of these things happen in the editor:

• the background-color is set as a style attribute to the color value selected (i.e. style="background-color:rgb(0,0,0)")
• the appropriate class is applied to the element (i.e. class="has-PRESET-background-color")

While the user's preferences are set to "light mode" this renders fine; the color values are the same.

The 'dark mode' of a theme changes the preset values to support that dark mode and the value are no longer the same as defined by the theme for the editor's consumption. Thus, while the user's preferences are set to "dark mode" this does NOT render fine as there is a mismatch between what the expected "preset" color is as represented in the editor and what will actually render as defined by the theme.

What is rendered in the VIEW is correct, as only those elements that have a custom color that is NOT set to a 'predefined' color have the style attribute added.

To reproduce
Steps to reproduce the behavior:

1. Set your system appearance to 'Light' mode.
2. Activate Spearhead (a theme that has dark mode support).
3. Add a

   block to a page and add some text.

4. Change the background color to the preset 'Foreground' which is represented as a BLACK color option.
5. Note that the Background Color of the

   block is correctly rendered as BLACK (and foreground text white).

6. Change your system appearance to 'Dark' mode.
7. Note that the Background Color of the

   block is still rendered as BLACK (however the foreground text is now also black).

8. Publish the page and observe it in VIEW mode.
9. Note that the

   tag is correctly rendered with a "white-ish" background (the FOREGROUND color of the theme while in dark mode).

Expected behavior
An element that has a BACKGROUND COLOR or TEXT COLOR applied that is NOT a 'custom color' but instead a color defined as a 'preset' color should NOT have the color values applied via a style attribute, but only by way of the 'preset' color classes. (This is the same color attribute assignment behavior found in the rendered view.)

Screenshots
<p> block in editor view with 'Foreground' preset color applied as the background (light mode):

The same block in view mode (light mode):

<p> block in editor view with 'Foreground' preset color applied as the background (dark mode):

The same block in view mode (dark mode):

Editor version (please complete the following information):

• WordPress version: 5.5.1
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? "gutenberg"
• If the Gutenberg plugin is installed, which version is it? 9.2.1

Desktop (please complete the following information):

• OS: Mac
• Browser: FireFox

Additional context

• This has been raised in the context of this issue: Spearhead: Dark mode text is unreadable by default when a preset color is selected Automattic/themes#2644

[scruffian]

One idea @kjellr had for how we could deal with this is to add a theme_support option that turns off the inline colors in the editor and uses class names instead. That way the colors would be based on whatever the stylesheet dictates.

[pbking]

I was able to track down that this change introduced adding the style attributes to the block. That was done to fix this issue.

It was also noted in the original bug that this type of behavior might occur and is a good reason NOT to have done that original fix.

This fix was originally done because of how TwentyNineteen defined its palette. I haven't yet confirmed if that has been addressed.

@kjellr suggested adding a theme_support option to disable this bit of code. An alternative might be to instead test the palette to determine if it was created in a state where this logic won't be necessary instead. (My expectation is that the code will rarely be ran in that case.) Or, perhaps the code can be simply removed if 2019 has been brought up-to-speed.

[stefanfisk]

This workaround solved the issue for me:

import { removeFilter } from '@wordpress/hooks';

removeFilter('editor.BlockListBlock', 'core/color/with-color-palette-styles');