UI: Add truncation support to Text component

[aduth]

What problem does this address?

The @wordpress/ui Text component doesn't provide any built-in support for truncation behavior, requiring developers to implement this themselves (e.g. #77012, #77372). From a design system perspective, we should seek to ensure consistency and provide baseline support for how content is truncated.

What is your proposed solution?

Add props for:

• Enabling truncation (e.g. truncate, a boolean)
• Controlling number of lines (e.g. numberOfLines or lineClamp, a number)

In adding support, we should also remove existing workarounds, like those in the pull requests referenced above (#77012, #77372).

We should be careful to consider scope creep and what's minimally necessary to provide baseline functionality and consistency for such a low-level component.

For background, the @wordpress/components Text component composes options from the Truncate component, which provides a lot of control over specific truncation behavior (ellipsis string, trimming behavior, character limit, line limit). Many of these are rarely (or never, in the case of ellipsis) used, and arguably could be counter-productive to the design system's intent of providing consistency.

truncate and numberOfLines are the most regularly used options today. Other component libraries like Chakra UI's Text component provide exactly this amount of customization as well.

Open question: Is this a good enough combination of (a) being commonly used, (b) being difficult to implement without, and (c) prone to being implemented inconsistency, in order to warrant the maintenance cost and scope inflation to implement baseline support?

[mirka]

I don't think it's a given that truncation features should be included in Text directly. At least when auditing the @wordpress/components for the current component recommendation statuses, we noted our impressions about the wp-components Text props being too bloated.

Considering how many of our (sub-)components will be text-based (e.g. Foo.Title or Foo.Heading), it might be better to just have a separate Truncate component to wrap arbitrary text-based components.

[aduth]

@mirka That seems like a feasible direction as well, especially if we're not shying away from @wordpress/ui containing low-level primitives. I also surfaced my own hesitations in the "Open question" of the original comment. I'd like to think we could limit our options to prevent too much "bloat", but I also acknowledge that's likely a common proclamation for every new component before it becomes bloated 😅

[ciampo]

Agree on exploring a separate Truncate component that can be easily composed with Text (or any other component) as needed.

[mirka]

I was looking into implementing this, but came to the conclusion that we probably don't need it 🤔

Here are the props for the current Truncate component in @wordpress/components:

• ellipsis (default: …) — It's unlikely that anything else should be used.
• ellipsizeMode (default: trims at the end) — There's no evidence in the repo that anyone ever wants to trim at the beginning or the middle.
• limit (default: 0) — Max number of characters to display. We shouldn't be using this anyway because "number of characters" is not a useful way to think in multilingual apps.
• numberOfLines (default: 0) — Fair, but only two instances in the repo are actually setting a line limit other than 1.

So basically what our redesigned Truncate component would look like is a utility for the standard text-overflow: ellipsis/overflow: hidden/white-space: nowrap combo. And maybe a utility for -webkit-line-clamp, which is a bit more complicated, but the need for multiline clamping is rather rare.

All in all, since there are no real consistency concerns here, and the styling is pretty straightforward, I would lean towards recommending CSS. Perhaps we could have a doc page on truncation styles with code snippets, but given that it will just be a generic set of snippets, it's possibly unnecessary now that agents can simply generate them when prompted.

[simison]

What would be helpful is truncate={ true | false} prop in Text, with common defaults (as noted above), so that folks avoid adding CSS each time for the most common case:

text-overflow: ellipsis;
white-space: nowrap;
overflow: hidden;

For anything more custom, they'd need to bring their own CSS, which seems fine.

[simison]

In practise, are there other uses of <Truncate> in DS than pairing it with <Text>? Just custom components from consumers come to mind.

[ciampo]

What would be helpful is truncate={ true | false} prop in Text, with common defaults (as noted above), so that folks avoid adding CSS each time for the most common case:
...
In practise, are there other uses of <Truncate> in DS than pairing it with <Text>?

A boolean truncate prop may work well enough for Text, but it won't compose as modularly when Text is used internally:

Considering how many of our (sub-)components will be text-based (e.g. Foo.Title or Foo.Heading), it might be better to just have a separate Truncate component to wrap arbitrary text-based components.

We would have to expose and forward truncate props on each of those components. In that sense, a separate <Truncate /> component may compose better.

@mirka another reason why we may want to have a dedicated Truncate component is to ensure consistent text truncation, assuming that a component will be used more reliably and consistently than a copy-paste CSS snippet?