Setting a White Background color on blocks isn't respected

[jromales]

Quick summary

Setting a white (#FFFFFF) background color on blocks are not being respected. The expected color is displayed on editor but not on the live site.

4823719-zd-woothemes

Steps to reproduce

1. Add any block that allows custom color background
2. Set a white (#FFFFFF) background color
3. Preview the page

What you expected to happen

When in the editor:

What actually happened

When previewing:

Context

I have tried it on another test site I own, using different blocks. Any background color is respected except #FFFFFF

Simple, Atomic or both?

Simple

Theme-specific issue?

So far I tried two themes only: Baker, Spearhead

Browser, operating system and other notes

Browser: Chrome, Safari
Operating system: Mac OS

Reproducibility

Consistent

Severity

One

Available workarounds?

Yes, difficult to implement

Workaround details

Setting the background color in Customizer fixes it, but doing that will also affect all other areas in the site. They only want the white background in some blocks.

[jromales]

I have another user with the same issue on setting white color, but this time on a text. I replicated it on a Paragpraph text, and on a Heading. 4824317-zd-woothemes

[jordesign]

Hey @jromales - when you found this issue to be happening - was the White color to be found labeled as the 'tertiary' color (probably the 3rd color in the pallette?)

if so - it could be this issue here:
Automattic/themes#5585

[jromales]

Hi @jordesign! It's from the "background" color from the pallette.

I also discovered a workaround. If you select the color using the pointer, it works.

Screen.Recording.2022-03-04.at.12.27.18.AM.mov

[marcuswisecaesar]

In this ticket - 4828767-zd-woothemes - the user had set the background color of the right hand sidebar to #333333. But when viewing the published site, the background color defaults to the tertiary color.

Workaround - Adding a custom class to the block, then adding CSS to adjust the background color with !important will work.

[1dr0]

I'm in ticket 4823719-zd-woothemes and did a few tests on my own test site.

Screen.Recording.2022-03-09.at.12.50.58.mov

It looks like the background color issue is occurring on non-FSE themes.

Tested with a random FSE theme (I selected Marl in the video example) and the background colors worked.

I may nudge the user to see if they are open to use an FSE theme, as it looks like they have only one main page up at the moment.

[ccwalburn]

Another issue only it doesn't work with black #000000
We changed it to #000001 and it works
The #000000 black is not a Tertiary color so I don't think it is this bug: Automattic/themes#5585
Theme: Rockfield
It is an AT site

[ivan-ottinger]

Spearhead

I'm in ticket 4823719-zd-woothemes and did a few tests on my own test site.

It looks like the background color issue is occurring on non-FSE themes.

Tested with a random FSE theme (I selected Marl in the video example) and the background colors worked.

The underlying issue seems to be related to the dark-mode and is reported over here: Automattic/themes#3410.

When the theme's dark-mode is used (e.g. when you have the dark-mode set in your OS preferences), the colors displayed in the block editor don't match with the colors/styles used in the front-end.

Example

Front-end when the ☀️ light-mode is selected:

Front-end when the 🌑 dark-mode is selected:

So it looks like the main issue stems from the fact the theme doesn't adjust the representation of colors in the block editor when the dark mode is used. Instead, the editor stays the same regardless of the dark/light mode and therefore selecting white background color is misleading (as when the dark-mode is on, selecting white color results in dark color, #1e1f21):

[ivan-ottinger]

Baker

In the Baker theme, the issue is likely related to the Custom Colors set in Customizer → Colours & Backgrounds. When I change the Background Color for instance:

it carries over to the blocks in the front-end:

regardless of the color we set in the block editor:

We had a related fix deployed last year: D64853-code. Issue: #54933.

Hey Caroline 👋🏼 @sixhours do you think my thought process is correct here? I wonder if a similar fix would help in this case as well. 🤔 (I am pinging you since you worked on that patch. Thank you!)

[ivan-ottinger]

Blank Canvas (retired Seedlet-based theme)

In this ticket - 4828767-zd-woothemes - the user had set the background color of the right hand sidebar to #333333. But when viewing the published site, the background color defaults to the tertiary color.

Workaround - Adding a custom class to the block, then adding CSS to adjust the background color with !important will work.

@marcuswisecaesar

I tried to reproduce the issue according to the user's page that was mentioned in chat, but with no luck. With that said, when I reviewed the user's site, there was inconsistency in color settings:

When we look into Customizer → Colours & Backgrounds on the user's site, here's what I see:

but when we look into a specific block setting, we get a different colors (e.g. Foreground color):

Looking at the issue deeper, turns out they are using retired version of the Blank Canvas theme that was built on top of Seedlet. Now there's a new version of Blank Canvas (Blocks) that is built on the Blockbase parent theme.

What we may want to suggest to our user is to switch to that new version of the theme:

Of course, making sure they are aware they may need to adjust the theme / site settings afterwards - to make the site look similar to how it looks now.

Since I wasn't able to reproduce the issue with the new Blank Canvas (Blocks) theme, once they switch to it, they shouldn't encounter the issue anymore.

The question is, whether it is worth it for the user to switch the theme only because of the color issue that we have already helped them fix with a CSS workaround.

[ivan-ottinger]

Another issue only it doesn't work with black #000000
We changed it to #1 and it works
The #000000 black is not a Tertiary color so I don't think it is this bug: Automattic/themes#5585
Theme: Rockfield
It is an AT site

I was able to reproduce this issue.

Turns out this is not specific to the Rockfield theme only. There was a Gutenberg bug reported yesterday: WordPress/gutenberg#40043.

Another similar issue reported: Automattic/themes#5723.

[MaggieCabrera]

is this still an issue? I found it was fixed for Stratford and 2013 themes while I could reproduce before.

[mashikag]

There were multiple issues raised in this ticket as pointed out in @ivan-ottinger comments.

It looks like only two are still remaining as open:

1. Spearhad theme issue as per the comment. This one seems to have a dedicated ticket open.
2. Baker theme issue as per the comment.

Therefore this ticket can be used to track and fix the Baker theme issue. Apex team has no experience in that area. @sixhours can you help with this?

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 4823719-zen
• 4824317-zen
• 4828767-zen