-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Implicit Text, Hover, Focus Colors as Part of Color Palette #34717
Comments
I agree with what you are saying. I love the idea of presets, but setting a default for the text inside "palette" might make sense, but hover and focus can be used in a variety of ways and may be impacted by block style. Hover color could be applied to border-color, background, text, etc and the block with a background color selected may not even need or want hover effects. Text Color DefaultTheme.json "palette": { { "slug": "white", "color": "#FFF", "name": "White", "default": { "text": "darkGray" } }, ... } Implementation: Develop a hook into the block color support and set the default text color if block support allows. Block supports already allow default attribute values for color. This would also allow for cascading and overriding in block settings in theme.json. This would set the initial value and automatically apply .has-{color-slug}-color to the block. Then the user can override that default by selecting a new text color. I think this is a cleaner approach then adding color to the background-color class. Hover/Focus DefaultsIf hover/focus colors were included as a default setting, it would need to be included in block settings for those with "hover" support. It would be great if selecting certain block styles activated supports for different hover settings. For example, a button block would be a logical choice with hover color support, but hover color support would have nested support based on the style selected. A theme could register an "Outline" button style and add nested hover support for background-color (think Material.io imitation hover "overlay" effect) or border-color. It would depend on the theme design for that particular style. This would require big changes to implement though. NOTE: Hover support does not currently exist nor does registering block styles with varying block supports. Block styles only add a style class at this time. |
This was a big pain point when developing Twenty Twenty-One. Perhaps there should a palette type called "color pairs"? |
@carolinan I'd love to learn more about that. Are there specific tickets that would be helpful to review for understanding that history? In my experience, so long as the background color classes are listed first and have the same or lower specificity as the text color classes, they don't interfere with user preferences. Handling all possible nesting scenarios does get more complicated but feels like it's probably still solvable. Higher specificity via source order
Higher specificity via selector
The "color pairs:" idea would definitely be an improvement over the current state, though my concern would remain about added pain when switching themes. |
In Twenty Twenty-One, the button is inverted on hover; the filled style is the hovered style for the outlined, and vice versa. And then all that was reverted in dark mode... |
Thinking about this more the other day, an alternative might be a dynamically calculated class for That way a theme could add just two new rulesets and have pretty darn good defaults: .has-dark-background {
color: white;
}
.has-light-background {
color: black;
} |
If you use CSS Custom properties for declaring palette color values in theme.json becomes much easier to replace a color. This is an example simplified withouth all the rest of the css, this should work (on my machine), only to get the idea: .wp-block-button__link {
color: var(--wp--custom--button--text);
}
.has-base-background-color {
background-color: var(--wp--preset--color--base) !important;
}
.wp-block-button__link.has-base-background-color {
--wp--custom--button--text: [my-custom-value-here]
} <div class="wp-block-button">
<a class="wp-block-button__link has-base-background-color has-background">Button</a>
</div> You can also generate this from SASS and add hover support. Adding contrast to more elements could stretch the css. |
I posted a similar suggestion and @cbirdsong kindly pointed me to this one. I've closed my post in favor of this one.
This is exactly where I was going with my suggestion. Gutenberg already has a way to assess lightness or darkness in the editor (although it could be improved to better understand gradients). The Cover block is automatically given an If a simple Because that CSS is quite general, those foreground colors can be easily overridden by the user by selecting something different from the color palette if desired, addressing @carolinan's point:
This method gives content creators the same amount of control they have now (they can still pick any text color from the color palette that they would like), but provides sensible defaults that better meet accessibility standards. And it does so with a very tiny amount of CSS. |
Would love to see this I just noticed that in the editor side there is a |
What problem does this address?
The thing that will keep me from adopting
theme.json
for my color palette CSS is that I prefer to automatically set text color when a user sets a background color that has poor contrast. e.g.:Current Experience:
Better experience!
This is a great user experience. (In fact, a client yesterday mentioned how much they loved it during their first training ever with the block editor, literally saying, "It just works!"
Without automatically setting a sensible text color, the user must make a second click for many (most?) color changes (background and text color) and also remember the consistent background-foreground combinations they use throughout the site.
Further, by increasing the number of blocks with both a background and foreground color classes, it increases the chances of bad results following a theme change that might use the same color names like primary, secondary, accent, etc. but have different contrasting colors.
What is your proposed solution?
Extend
theme.json
's color palettes to include an optional implicit foreground color for each color, so that background-color styles include acolor
CSS property as well.Due to the point about theme changes, I wouldn't want to see this implemented as automatically setting the foreground color, because that is an independent action on top of the better default I'm proposing.
Taking this same thought process further, being able to define hover and focus styles for colors when applied to buttons and links would be even better!
The text was updated successfully, but these errors were encountered: