UI Button: Optimize overflow styles#78300
Merged
Merged
Conversation
|
Size Change: +49 B (0%) Total Size: 7.97 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 74b2721. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25927455362
|
mirka
commented
May 14, 2026
| text-align: center; | ||
| text-decoration: none; | ||
| color: var(--wp-ui-button-foreground-color); | ||
| overflow-wrap: anywhere; |
Member
Author
There was a problem hiding this comment.
This is the most contentious line. I think our choices are:
anywhere— This will break long words, but the downside is that it will shrink down the button width inmin-contentsituations. See the min-content example in the e2e Storybook, or the change we'd have to make inpackages/ui/src/button/stories/index.story.tsx.normal(i.e. we don't set an explicitoverflow-wrap) — This will leave long words unbroken, and the text will overflow.
(break-word is not really a choice because it behaves the same as normal in our case, since the button being an inline-flex makes the break-word irrelevant for min-width calculations.)
Member
Author
There was a problem hiding this comment.
At the moment I'm leaning towards anywhere, because it will immediately surface any layout issues (like the interaction with min-content containers) in an obvious way. Whereas normal will not surface line break issues until someone that happens to see long strings (arbitrary or translations) in the UI reports an overflow.
Contributor
There was a problem hiding this comment.
Feels like something that @WordPress/gutenberg-design should also check
Contributor
There was a problem hiding this comment.
Through process of elimination anywhere seems like the only option, assuming we want to avoid words overflowing the button boundary 👍
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ciampo
approved these changes
May 14, 2026
Contributor
There was a problem hiding this comment.
I personally like this approach.
Basically, out of the box, Button prioritizes content accessibility and is not afraid of getting taller, making sure that text is always visible.
Consumers of Button are in charge of picking a reasonable string of text given the width of the button. Or make layout changes to accommodate a longer string of text. If they want, they can also implement custom truncation (although we'd discourage that).
Let's see what design folks think, too.
Contributor
|
A couple of small design considerations:
|
Member
Author
We generally can't do this with library components because there are strings that should never be hyphenated (e.g. product names, slugs, ids, etc).
I added a 4px "courtesy" padding (except for in
|
Contributor
Makes sense, but the legibility of broken long words suffers quite a bit. Should it be a prop? 🤔 |
Member
Author
|
I'd say it's fine to leave as something a consumer could write CSS for if they want that behavior. Wrapped button labels are usually going to be something that people want to fix, rather than make legible. |
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?
Updates the
@wordpress/uiButton styles so long labels degrade more gracefully in constrained layouts.Why?
Button labels are important for usability, so when labels are longer than expected, for example due to translations or unbroken words, the component should preserve readable text instead of overflowing its container.
Buttonin@wordpress/componentshad inconsistent and suboptimal default wrapping issues which we tried to fix (#73711 #76071), but basically had to give up due to breakage risk. Given the high usage of this component, even in the@wordpress/uiwhere back compat is not a must, we should try to set a robust default before starting widespread adoption.How?
min-heightso wrapped labels can increase the button height.max-width: 100%so it respects constrained containers.overflow-wrap: anywhereso long unbroken labels can wrap instead of overflowing.Testing Instructions
npm run storybook:e2e:dev.Design System/Components/Button/Text Overflow.Screenshots or screencast