Navigation: color consistence between front-end and editor-canvas

[retrofox]

Be consistent with text color in the front-end and the editor-canvas.

Twenty-twenty

front-end

editor-canvas

[paaljoachim]

I am doing a status update of older issues.

Text Color is sometimes working and other times not with theme Twenty Twenty.

I see the same problem in Twenty Twenty One.

Because of the color combination warnings a certain mix of colors is not being allowed to be used, but this is only in the backend. The frontend will show the colors.

WordPress 5.6
Gutenberg plugin 9.7.4
Local site running Desktop Server.
Chrome
Mac OSX 10.15.7

@kjellr

[jasmussen]

I took a look today and it appears to be a specificity fight between themes, editor styles, and colors. Here's TwentyTwentyOne:

Note how the text color doesn't work in the editor. But it works on the frontend:

This is the offending rule:

TwentyTwentyOne outputs this CSS in its editor style:

:not(.has-text-color).has-black-background-color[class],
:not(.has-text-color).has-gray-background-color[class],
:not(.has-text-color).has-dark-gray-background-color[class] {
	color: var(--global--color-white);
}

That has way higher specificity than what the navigation color system outputs:

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

Because of this added specificity, the editor style will always win this fight.

We could change the global styles to output this instead:

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

that would win the fight. However to me it feels like TwentyTwentyOne is doing it wrong, and is adding too high specificity. Since this was reported for TwentyTwenty as well, that either means two themes are doing it wrong, OR that what both themes are trying to accomplish is not well handled by the editor here.

I'm tempted to say both themes are doing it wrong, because it works on the frontend but not in the editor. But that could still point to a complexity in the editor markup that led to the extra specificity being added to the editor style in the first place.

@kjellr do you have any thoughts here?

[jasmussen]

A good friend did some investigative work and uncovered that navigation li is missing the has-text-color on the editor. Seems like that could throw a wrench into the specificity wars, and that by adding this missing class in the editor, we'd solve the issue! @retrofox how hard would this be to address?

[retrofox]

A good friend did some investigative work and uncovered that navigation li is missing the has-text-color on the editor. Seems like that could throw a wrench into the specificity wars, and that by adding this missing class in the editor, we'd solve the issue! @retrofox how hard would this be to address?

I think it won't be a big deal but I need to dive into the code since I've been away from a loooong time ago. Going to take a look in a few days if it's still useful. :-D

[jasmussen]

Oh, didn't mean for you to necessarily fix it, just wanted a quick gut check! I'll see if I can find some help.

[mrfoxtalbot]

While still not 100% consistent, this appears to be less of an issue now:

Do you have any thoughts on what to do here next @jasmussen?

[jasmussen]

Oh nice, looks like #44578 also fixes this one.

[mrfoxtalbot]

Cool! I will add this to my list to review and close if it is no longer relevant after #44578 is merged.

Thank you @jasmussen