🔥 HOT: Ticket/ - High Quality

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#51927 closed defect (bug) (fixed)

Twenty Twenty-One: Buttons lose contrast consistency in Dark Mode

Reported by: allancole's profile allancole Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 5.7 Priority: normal
Severity: normal Version: 5.6
Component: Bundled Theme Keywords: 2nd-opinion has-patch
Focuses: css Cc:

Description (last modified by desrosj)

While digging into another issue I discovered a possible flaw that suggests we may need to change the theme’s default palette colors when Dark Mode is turned on. The color system in TT1 gets confused in Dark Mode when it tries to deal with pastel background-colors and nested blocks that need special contrast to retain a11y.

This CodePen lays out whats happening and some options for how to correct it:
https://codepen.io/allancole/pen/wvzKYWq

I’m pretty sure TT1 has some fall backs that catch some this already. But we’re doing it with block-by-block overrides which make it harder to comprehend and difficult to unravel and fix.

To test this,
1) Create a group block using the pastel-yellow palette colors as the background.
2) Nest a paragraph block and a button block inside of that group.
3) Publish.
4) Set the theme to Dark Mode and visit the frontend.

See screenshots to se expected and actual results.

I have two possible suggestions to solve this.

Solution 1: Reverse the brightness for palette colors in Dark Mode.

This requires adding the theme’s pastel and dark color variables to our style-dark-mode.css and including some new Dark Mode specific pastel colors that are effectively reversed. the downside here is that if we change the theme’s palette colors, we might also might need to update the palette colors in the customizer and the block editor which is especially difficult and quite a big change.

Solution 2: Revise our utility classes to account for the Dark Mode class.

This would require us to revisit the color-palette.scss utility classes and include a new rule for Dark Mode to make the text appear the right color.

Example:

.has-green-background-color[class] {
	background-color: var(--global--color-green);
}

.is-darkmode .has-black-background-color[class]:not(.has-text-color) {
	color: var(--global--color-dark-gray); /* Make text dark when in Dark Mode */
}

I’m still exploring the two options, but so far the second one seems the easiest to do with the least amount of refactoring and friction.

I’m curious to hear other’s thoughts on this. Maybe there’s some other way to solve this?

Attachments (2)

expected-result.png (59.6 KB) - added by allancole 5 years ago.
Expected result.
actual-result.png (56.3 KB) - added by allancole 5 years ago.
Actual result

Download all attachments as: .zip

Change History (30)

@allancole
5 years ago

Expected result.

@allancole
5 years ago

Actual result

#1 @poena
5 years ago

These are not new but well known and thorougly tested issues that we were not able to solve in time.

The second solution has been tested but the pull request was not accepted.