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... |
mrwweb commentedSep 9, 2021
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: