[WIP] Block Supports: Relocate text and bg color controls to Typography and Background panels#77279
Draft
aaronrobertshaw wants to merge 10 commits intotrunkfrom
Draft
[WIP] Block Supports: Relocate text and bg color controls to Typography and Background panels#77279aaronrobertshaw wants to merge 10 commits intotrunkfrom
aaronrobertshaw wants to merge 10 commits intotrunkfrom
Conversation
Pull the ColorPanelDropdown component and its supporting LabeledColorIndicators/ColorPanelTab/popoverProps helpers out of color-panel.js into a standalone module so Background, Typography, and Color panels can all render color/gradient ToolsPanelItems consistently without duplicating the dropdown/tabs/reset boilerplate. Pure refactor. No UI change.
Render Color (solid, writes to color.background) and, for blocks that have color panel gradient support but haven't adopted the newer background.gradient block support, a legacy Gradient (writes to color.gradient). The existing background.gradient item remains as the primary gradient surface for blocks that use the newer support. useHasBackgroundPanel now also returns true when a block has color panel background support, so the panel surfaces for blocks that previously only rendered background controls inside the Color panel. resetAllFilter is extended to clear color.background and/or color.gradient when the panel owns those items. color-panel.js still renders its own top-level Background item at this point; that will be removed in a follow-up commit.
Render a Text color item at the top of the Typography panel, before Font Family. Writes to color.text (unchanged storage path). Gated on useHasTextPanel, which already checks settings.color.text plus color availability, so any block that currently exposes text color in the Color panel will expose it here. useHasTypographyPanel now also returns true when text color is enabled, so the panel surfaces for blocks that only have text color support and no other typography features. resetAllFilter is extended to clear color.text when the text color control is shown. Text color renders at all scopes (root global styles, per-block, and per-element typography screens) because TypographyPanel is the same component in each context. color-panel.js still renders its own top-level Text item at this point; removal comes in a follow-up commit.
Complete the relocation of top-level text and background controls. ColorPanel now contains only link and element (heading, button, caption, h1–h6) items; top-level text color lives in TypographyPanel and top-level background color (plus gradient) lives in BackgroundPanel. Changes: * Remove showTextPanel, showBackgroundPanel, and all their supporting state, setters, and item definitions. * Remove the hasBackgroundGradientSupport / showGradientColors gating since the Color panel no longer renders a background item that could overlap with background.gradient. * Remove the "text color syncs link color when they match" convenience that previously fired from setTextColor. TypographyPanel does not carry this sync behavior; link color is set independently. * Update useHasColorPanel to return true only when link or element controls are enabled. * Update resetAllFilter to reset only link and element colors, no longer wiping the entire color object. color.text and color.background are now owned by the Typography and Background panels' reset-all, respectively. * Trim DEFAULT_CONTROLS to link/heading/button/caption. useHasTextPanel and useHasBackgroundColorPanel remain exported from this module because Typography and Background panels consume them as visibility gates.
Adds visibility hook coverage for the color/background/typography panel restructure: `useHasColorPanel` now only reflects link and element controls, `useHasTypographyPanel` opens on text color alone, and the existing `useHasTextPanel` / `useHasBackgroundColorPanel` gates continue to work for the panels that now consume them.
aaronrobertshaw
added
[Type] Enhancement
Contributor
Author
|
@jameskoster I took a quick run at what an interim step might look like in terms of relocating the text color control under the Typography panel, and the background color control under the Background panel. Note that the "element" colors like for Link, Heading, Buttons etc. are all still under optional controls on the Color panel at the moment until we work out a drill down approach or similar. An additional step in this exploration could be to add a new Elements panel that behaves as the Color panel does now for the Group block. That is, all the elements are optional controls that can be toggled on and each has a popover containing text, background etc tabs. Not ideal but a reasonable step until we have the ability to drill down and style more than just colors. We'd keep the current Colors panel so that if blocks add ad hoc color controls into that panel they still show as expected. If there's nothing in the Colors panel it wouldn't render at all. Let me know if you think there might be something here we can pursue in the short term. |
|
Size Change: +736 B (+0.01%) Total Size: 7.75 MB 📦 View Changed
ℹ️ View Unchanged
|
Member
|
Thanks for getting this PR up for consideration, and allowing folks to play around with it. It's working for me as described.
I can't shake the feeling our labels are working against us, and it's for this reason we're having to make some awkward shuffling around of properties. Typography, at least for me, is about how text is shaped and arranged, so we have font family, size, weight, spacing, line height, text transform etc, while color has always been a surface treatment. BUT the user's mental model isn't CSS properties so my thinking here is inappropriate. I don't know how many folks outside this repo say "Oh, I need to set my color and font size" but instead "this text needs to be bigger and bolder and should stand out more" 😄 Is being prescriptive based on CSS taxonomy instead of user tasks working against us here? So in the context of this PR, I see some reason in dropping technical terms and mirroring CSS. "Text" or "Text Style" makes more sense to me when I test out the controls here. Anyway, these are just my initial thoughts. I don't know if there's a perfect solution here at all (is there ever?), but I appreciate the compromises and ideas folks have arrived at to help us decide. |
Contributor
This would effectively mean the existing Color panel is hidden most of the time, right? If so I think that might be good to include in this PR. Relatedly I'd consider giving the new Elements panel less prominence in the UI, maybe by positioning it at the bottom of the inspector. |
Contributor
Author
|
Thanks for the direction @jameskoster 👍 I was already working towards both including the elements panel as well as pushing it further down the sidebar. As soon as I have something more functional. I'll demo again. |
Contributor
Author
|
This is early days and still buggy but here's a quick glimpse of the elements panel approach discussed. The first pass at this was pushed in 9853127 Screen.Recording.2026-04-16.at.5.54.32.pm.mp4 |
Contributor
|
Neat, that looks pretty good to me. Time to rope in @WordPress/gutenberg-design for some wider feedback. The only quirk I noticed is the placement of the contrast warning. If that appears due to changing the Text color the placement is a bit unexpected. I wonder if we should move that warning to the color popover. That way it'll appear contextually whether you're currently modifying the background or the text color. Additionally it won't clutter the Inspector in situations where users legitimately want low contrast styling. |
Contributor
Author
|
Thanks for taking another look at this one 🙇
Good idea. I like it 👍 I'll find some time and make it happen on this PR. |
Contributor
Author
|
Here's a demo of a quick hack at getting the contrast checker warning within the color popovers. I think we might need to put a little thought into how we could present this better to avoid scrollbar within the popover, the popover extending beyond the bottom of the page, or even just the significant layout jump that it causes. Happy to try out any ideas you might have: Screen.Recording.2026-04-18.at.8.00.06.pm.mp4 |
Contributor
Author
|
Here's a quick mockup of potentially adding a warning icon and tooltip/popover to the color popover when the contrast is too low. We could also display it in color control in the panel as well if we can find a way that it doesn't look too bad beside existing color swatches and the reset button within the control. For now though maybe this will spark further ideas: Screen.Recording.2026-04-19.at.11.46.28.am.mp4 |
Contributor
|
Yeah that works a bit better. I wonder if we could use a 
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
See:
This PR is a proof of concept that explores improving the information architecture of the block inspector and global styles sidebars by relocating the root-level text and background color controls to the panels they most naturally belong with:
Why?
Today, every color-related control lives under a single Color panel, regardless of whether the user is thinking about typography, background styling, or element-specific treatments. Grouping controls by the style aspect they affect (typography, background, etc.) should make the sidebars easier to reason about and bring related controls closer to where users are already working.
This PR is deliberately an interim step. The element-level color controls (Links, Headings, Buttons, Captions, etc.) remain under the Color panel because moving those properly is a larger IA question: ideally each element would be presented as a drill-down into its full set of styles (typography, color, spacing, etc.) as a cohesive unit, rather than splitting a single element's controls across multiple top-level panels. That exploration is out of scope here and is best tackled as a follow-up once we have feedback on this simpler change.
The goal of landing this smaller step first is to validate the directional change on the two simplest cases (root text and root background) before committing to a larger restructuring.
How?
Color, Background, and Typography panels. The existing panel-specific classes (block-editor-tools-panel-color-gradient-settings__item,
block-editor-background-panel__item, block-editor-typography-panel__color-item) remain on the DOM for backward compatibility.
visible item in the Color panel when element-level controls were toggled on.
"Color" buttons now exist in the sidebar.
Testing Instructions
Screenshots or screencast
Screen.Recording.2026-04-14.at.11.46.01.am.mp4