Twenty Nineteen: Group color styles prevent custom colors

[Joen]

When TwentyNineteen was created, the ability to colorize various blocks was not as full-featured as it is today. You could easily choose text and background colors in a block, that would have no contrast at all.

However this is less of an issue today, where the contrast checker will help inform you whether the text is sufficiently legible or not.

In addition to this, the rules that colorize text according to what background color you applied to a group means that custom colors don't work at all, which will be more of an issue as global styles let you colorize more aspects.

This was originally reported in ​https://github.com/WordPress/gutenberg/issues/21672.

[Joen]

Text color not working in group.

[poena]

Update style-editor.scss

[poena]

While testing on WordPress 6.4.2 and current trunk I found that when a container block has a background color from the palette, the text color works on the front but not in the editor.

Because of that I have submitted a patch that only updates the style-editor.scss file.
With the patch, the default contrasting text color is only applied if the user has not selected a text color.

Testing Instructions

Steps to Test

1. Apply the patch
2. Build the updated stylsheets by running the npm command "npm run build"
3. Go to the block editor.
4. Add a group block with a paragraph. Select the group and add the blue background color and any text color.
5. Confirm that the colors work in the editor and the front.
6. Select the paragraph and add a text color. Confirm that this text color is used, and not the text color that was set on the group: It should override the group colors.
7. Now repeat step 4-6 with the different background colors: blue, dark blue, dark grey, light grey, and white.
8. Finally, open the Customizer, open the color panel, and change the color from default to custom.

Confirm that the colors work in the editor and the front.

Bonus: Try with other blocks such as columns and media & text.

Expected Results

The text color that the user chooses shows in both the editor and the front,
no matter what the background color is.

[harshgajipara]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: https://core.trac.wordpress.org/attachment/ticket/49931/49931.diff

Environment

OS: Windows
PHP: 8.1.9
WordPress: 6.4.2
Browser: Chrome
Theme: Twenty Nineteen
Plugins: None activated

Actual Results:

✅ Before patch: The text color works on the front but not in the editor.
Backend: ​https://prnt.sc/WHmD63qd3TA3
Frontend: ​https://prnt.sc/6aNJcIEp3AFp

✅ After patch: The text color works on the front and the editor.
Backend: ​https://prnt.sc/wGDg97IAxbdk
Frontend: ​https://prnt.sc/oou0Qlg8HiWl

[shailu25]

Test Report

This Report validates that the indicated patch addresses the issue.✅

Patch Tested: https://core.trac.wordpress.org/attachment/ticket/49931/49931.diff

Environment:

WordPress - 6.4.2
OS - Windows
Browser - Chrome
Theme: Twenty Nineteen
PHP - 8.0.18
Active Plugin - None

Expected Results:

• The text color that the user chooses should show in both the editor and the front.

Actual Results:

• After Applying Patch, The text color that the user chooses are showing in both the editor and the front.✅

Before Patch Screenshots:

Backend: ​https://prnt.sc/E331xIlxosWQ
Frontend: ​https://prnt.sc/RG2ZmY0BCL79

After Patch Screenshots:

Backend: ​https://prnt.sc/mdDuvU_muVL5
Frontend: ​https://prnt.sc/EaqTVuW4n6E0

With Different Background & Text Color:
Backend: ​https://prnt.sc/9yoJwJY9Ad4J
Front-end: ​https://prnt.sc/yP9bDO4CAqE9

[poena]

Thank you for testing.
I'm still hesitant about this PR because I'm wondering if this could be fixed without the :not.

[karmatosed]

I'm still hesitant about this PR because I'm wondering if this could be fixed without the :not.

I tend to agree with you @poena and wonder if just saying if have the class works better? I might be missing something though.

[poena]

Pinging @sabernhardt for feedback about the use of :not(.has-text-color) to apply a default text color to a block only when a user does not use a block setting to change the text color.

[karmatosed]

If it is ok with you @poena I am going to assign this to @sabernhardt for that check so we can start to move this on.

[sabernhardt]

#61429 was marked as a duplicate.

[sabernhardt]

#61474 was marked as a duplicate.

[sabernhardt]

#61913 was marked as a duplicate.

[sabernhardt]

I closed some tickets that also touch the same automatic contrast text colors issue. We need to consider multiple blocks for this ticket, including

• Media & Text block (#61429)
• Latest Posts Block (#61474 and #61138)
• Details block (#61913)

Additional props from closed tickets:
krupajnanda, narenin, pitamdey, pranitdugad, sudipatel007, viralsampat

[sabernhardt]

lower specificity (on front) and inherit text colors

[sabernhardt]

I uploaded a patch to show a different direction, but I do not expect that to be the final iteration (especially due to the links).

1. Because the element with the background color class has the text color value, child elements could inherit that instead of re-declaring the same value.
2. By grouping the headings and paragraph elements inside :where(), the background color ruleset would not override the text color classes added later in style.css. Then :not(.has-text-color) would be unnecessary.
3. I removed the child combinator from style.css, which was not in the editor styles.
4. The patch also inherits text colors for links unless the link element has a text color class or it is inside a Button or File block. Someone who has one of the theme's background colors on a Latest Posts or Query Loop block may find that other links should not inherit a text color either.
5. In the editor, links would need a higher specificity to override .editor-styles-wrapper .wp-block a and .editor-styles-wrapper .wp-block a:hover when the Primary color is customized.

[sabernhardt]

#62635 was marked as a duplicate.