Update ToggleGroupControl visual design

[jameskoster]

What?

Updates the visual design of ToggleGroupControl to be less visually prominent.

Why?

See #64439

How?

The implementation replaces the scaleX transform with direct CSS properties and adds conditional visibility:

1. Replaced transform-based scaling with direct width/height properties: Removed the scaleX() transform that scaled a fixed-width element (100px via --antialiasing-factor). The indicator now uses width and height directly from --selected-width and --selected-height, with 2px added to account for borders. This fixed an issue where scale was affecting the border width as the indicator elongated.

2. Simplified border-radius calculation: Removed the dynamic border-radius that compensated for scaleX. Now uses a static CONFIG.radiusSmall value since scaling is no longer applied.

3. Adjusted positioning: Changed left from -1px to -2px and added top: -1px and bottom: -1px to properly position the border around the selected option.

4. Added conditional visibility: Implemented an opacity calculation using CSS min() and max() functions to hide the indicator when both --selected-width and --selected-height are unset (defaulting to 0). The indicator is visible when either dimension is greater than 0. This is necessary because otherwise – due to the new border – the indicator was visible when no item was selected.

5. Updated visual styling: Reduced overall visual prominence.

6. Refined focus styles: Replaced the box-shadow focus indicator with a more accessible outline using CONFIG.borderWidthFocus and adjusted the outline-offset to 1px for better visibility. This is more aligned with the direction @wordpress/ui is headed.

7. Removed unnecessary properties: Eliminated transform-origin (no longer needed without scaling) and removed padding from the size variants that was causing layout issues.

Testing Instructions

1. npm run storybook and visit http://localhost:50240/?path=/docs/components-togglegroupcontrol--docs
2. Test the different variants
3. Smoke test the editor

Before

After

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 0b90a38.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20430333984
📝 Reported issues:

• [Flaky Test] should open and edit templates correctly when active_templates experiment is disabled #73743 in /test/e2e/specs/site-editor/template-id-format.spec.js

[t-hamano]

Thanks for the PR!

I wasn't involved in the discussions about redesigning this component, but to be honest, my first impression of the new UI was that it was hard to tell what was selected. 😅 This is because the selected item is only indicated by a light background color and borders on either side.

I'm not sure if there are any clear accessibility guidelines for this type of UI, but maybe we should get feedback from the accessibility team.

[t-hamano]

Looking at the latest proposed design, the borders on the item wrappers appear to be a little lighter in color. This makes it easier to visually identify selected items.

Note that this screenshot was captured on Windows OS, so the button text weights will be different than those on macOS.

[jameskoster]

Thanks for the feedback @t-hamano!

The control border is actually a point I meant to bring up. I agree the lighter border helps clarify the selected item. But I wasn't sure whether the control border also needs to meet contrast against the background. Let's wait and see the a11y feedback.

[mirka]

there can be some visual artifacts caused by border overlaps

• Pushed a fix for this in f708ede.
• Also pushed a fix for the 36px icon button case in 6e4cdd1.
• I confirmed that the component is usable in forced-colors mode.

---

In general I'm ok to ship these changes as an iteration, but we'll soon need to:

• Figure out how the colors play into the color token system in @wordpress/theme.
• Figure out how to show the entire component as disabled (#57862), while there is still a selection.

And these two things don't seem to be easily reconcilable with this gray-ish design 🥲 I hope we can find some solutions.

[jameskoster]

Thanks @mirka :) I think we'll need to do a deeper dive on a design spec for this when we come to 'migrating' it to @wordpress/ui.

[jameskoster]

Pushed a fix for this

I'm still seeing this in Storybook:

🤔

[jameskoster]

@mirka I noticed one other small quirk; the icon version is now 42px tall instead of the intended 40px.

[jameskoster]

the icon version is now 42px tall instead of the intended 40px.

I fixed this in ed0f6a3 but I don't know if it's the best approach. Is there a reason we use min-height here?

[mirka]

I have no idea what's going on here because I rebooted Storybook and the width offset indeed broke. And I set the values back to the initial values where it was broken and now it works?? 🫠 Also the control sizes were still weird after ed0f6a3 so I pushed another tweak.

This is what it looks like after the two new commits and a fresh Storybook reboot. Hope it's not another mirage…

[jameskoster]

Hah! Whether it's "broken" or not seems to be a consequence of the control width, and the number of items inside. I guess it's because the indicator width is based on the corresponding item width, rounded up or down? Here's a good example from the DataViews config popover:

• In the Order control the button is 75px wide and the indicator is 77px wide ✅ (2px discrepancy to account for the border)
• In the Density control: 106px & 108px ✅
• In the Items per page control: 79.5px & 81px ❌

[jameskoster]

Ah, I see it's possible to disable rounding in useAnimatedOffsetRect which seems to fix:

I don't know if there are any significant consequences of doing that though...

[fabiankaegy]

Just want to say that the iteration you all have moved towards here is so much better than where it started :) Looking really nicely and balanced :)

[t-hamano]

When icons are deselectable, focusing an unselected icon causes the borders to overlap. Should we add space between the buttons?

[jameskoster]

I think a gap will cause layout issues in the Inspector. I tried an alternative in 0b90a38.

It's not an elegant solution, but it works.

We might want to revisit the deselect-able variant in the future as it's semantically conflicted with the others (radiogroup vs group).

[mirka]

I think we're ready to merge? 🚀

[t-hamano]

LGTM! Looks well in Windows high contrast mode.

Default	Windows High contrast mode

[tyxla]

So cool to see this land - thank you 👏

[hanneslsm]

I'm late to the party and I'm on a Mac, but solely judging from @t-hamano screenshot above, the slide in Line indent is not visible on the Windows High Contrast Mode. Has anyone noticed that yet, has it already been fixed or is there a issue or PR for it? (I couldn't find any when searching)

[ciampo]

I'm late to the party and I'm on a Mac, but solely judging from @t-hamano screenshot above, the slide in Line indent is not visible on the Windows High Contrast Mode. Has anyone noticed that yet, has it already been fixed or is there a issue or PR for it? (I couldn't find any when searching)

@hanneslsm I wrote a dedicated issue here, I'll work on a fix tomorrow.

[hanneslsm]

I wrote a dedicated issue #75146, I'll work on a fix tomorrow.

Thanks!