navigation-menu: apply colors correctly in edition mode

[retrofox]

Description

This PR fixes implements the following changes:

• Align the Aa text of the toolbar colors-selector button.
• Apply the styles via CSS classes when the colores comes from the color palette.
• Apply the styles via inline styles when the colors are custom one.

These changes are implemented in the Editor Canvas. Let's handle the front-end in another PR.

Screenshots

before

after

Checklist:

• My code is tested.
• My code follows the WordPress code style.

[tellthemachines]

Thanks for addressing this bug! Left a couple comments; the major issue here is with IE support 😢

[talldan]

@retrofox lets defer to @tellthemachines' review and replace the CSS vars with inline styles—I agree it's important we don't forget IE support. I mistakenly thought that was being fixed on #18150.

Deferring to the review from @tellthemachines

[marekhrabe]

I think that setting the background and font color only on the nav block (where it is configured using block attributes) and propagating it only through CSS to appropriate nav items would be the easiest way forward. Skipping the need to pass props between parent-child blocks (unexplored territory) and also skipping CSS vars. I think they would be best to do the job but the current support still includes IE11 so we need to make sure it works.

To put code where my mouth is 😀https://jsfiddle.net/marek/54uvko21/

[draganescu]

We could not have this feature available in IE, and move ahead implementing it using tools available in modern browsers. That means the actual button in the toolbar would not be available in IE. @shaunandrews @mtias

[retrofox]

👋 I've added some changes applying the styles in the navigation menu, instead of each item:

• It will, indirectly, help to make this feature available for IE.
• It's possible that we want to apply specific styles for each item. Think for instance make the Home link different to the rest of others. Changes on this PR are aligned with this idea.

[tellthemachines]

This is now working on IE 🎉 🎉

I'm not able to preview most of the colours on the editor side though. This happens on all browsers and I think it's due to the inline styles not being applied as per my comment below.

Another slight issue that might pop up, depending on how theme styles are set, is the background colour not being applied to the submenu dropdowns:

It might be worth applying the inline styles to the submenu <ul>s too.

Question: should the colours reset to default when switching themes? Right now it's not happening but colours don't always translate 100% from one theme to another, say if accent colour was set as background in one theme it doesn't necessarily stay set in another. I am also noticing some intermittent weirdness when setting custom colours and then switching themes. This happened with a green custom accent set in Twenty Nineteen, and then switching to Twenty Twenty:

[retrofox]

@tellthemachines thanks for your comments here, and they make totally sense but I'd like to handle the front-end in a different PR. Make sense for you?
I've added the These changes are implemented in the Editor Canvas. Let's handle the front-end in another PR. comment in the PR description.
I've rebased the branch with master as well.

[tellthemachines]

@tellthemachines thanks for your comments here, and they make totally sense but I'd like to handle the front-end in a different PR. Make sense for you?

The only front end issue I mentioned was the submenu styling one, the others are all affecting the editor experience. The main one is the previews for most of the default colour choices in the editor not working:

I think this is happening because we are relying on classnames which have no CSS attached to them on the editor side, and we should be able to fix it by inlining the styles instead. That's what I was trying to say in my comment above, sorry if it wasn't clear.

[retrofox]

I think this is happening because we are relying on classnames which have no CSS attached to them on the editor side, and we should be able to fix it by inlining the styles instead. That's what I was trying to say in my comment above, sorry if it wasn't clear.

Thanks. Make sense. Sorry, you were; pretty clear. :-)

[tellthemachines]

This is working much better now! Approving the PR, and let's tackle the remaining issues in follow-up PRs.

Apart from the styling bugs I mentioned previously, there are a couple of accessibility problems we need to fix:

• Each colour palette should be wrapped in a fieldset with a legend instead of a plain div with a span for a label, so that screen readers can read out those labels.
• There's no way to close the dropdown once options are selected except for clicking outside or pressing Esc. Perhaps a close button would be useful?

[obenland]

Thanks @tellthemachines!

@WunderBart Maybe one or both of those accessibility issues could be a good substitute for #18135 (comment)?

[retrofox]

Apart from the styling bugs I mentioned previously, there are a couple of accessibility problems we need to fix:

Each colour palette should be wrapped in a fieldset with a legend instead of a plain div with a span for a label, so that screen readers can read out those labels.
There's no way to close the dropdown once options are selected except for clicking outside or pressing Esc. Perhaps a close button would be useful?

Thank you very much for your help here. Let's create issues in order to avoid forgetting them.

[mtias]

This change introduced a regression in how selected items displayed by forcing font-size: $text-editor-font-size;.