-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try: Provide a baseline submenu background color. #30831
Conversation
Size Change: +64 B (0%) Total Size: 1.43 MB
ℹ️ View Unchanged
|
// This includes blocks that have a background color, | ||
// as you might switch themes and the color specified is no longer registered. | ||
// But when one is explicitly chosen after the fact, it will override these rules. | ||
.wp-block-navigation.has-background, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. Weird situation. The fact that we attach presets as classes make switching themes fragile. I hope this can be lessened by having "core" colors #29568 but still there will be situations in which there may be preset theme colors.
I wonder if 29568 is a good opportunity to revisit how we do colors and whether presets can be inline colors (so we fix the theme switching issue).
I'm going to close this one. I think there's still a conversation to be had, but I'm not comfortable adding too many edgecase handlings directly to this block. The concern I think is worth thinking about, but handling for all blocks, not just this one. |
Description
This one is a bit unique, and is a followup inspired by work in #30805. It is a draft because it is in part more of a question about best practices, and the fix attached I only have medium confidence level in.
Situation: the navigation block allows submenus. When a submenu has a color set by the user, we can then colorize submenus according to that color (see also #29963).
When the navigation block does not have an explicitly set background color, we have to choose a background color for submenus, they can't just be transparent. But as soon as we choose a background color, we have to also choose a text color. Right now we do this by assigning a white background and black text with a
:not(.has-background) { background-color: inherit; color: inherit; }
rule. It works well enough.However a theme can assign a palette. For example I have a
bright-red
. So when I assign that to my navigation block, it gets classeshas-background has-bright-red-background-color
. The tricky bit is, those classes continue to exist when I switch from one theme to another, and that other theme likely doesn't have abright-red
color defined. In that case, my navigation block will now have transparent submenus, because the CSS assumes there is a background color, even when one isn't actually defined:This PR fixes that by assigning the white background even when the block has a background, but then relies on the color definition when present to override it. Here's what that looks like when the color is not defined:
But what's the best practice here? Presumably the problem is the same if I set a background color on my paragraph, then switch themes?
Checklist:
*.native.js
files for terms that need renaming or removal).