Buttons with long text should cut them off

[yannikmesserli]

Actual Behavior

When an unbreakable text is set to a button which is longer that what the button's width is capable of handling, the text overflow and break the button's layout.

Expected Behavior

The text should be cut-off.

Reproduction Sample

https://codepen.io/yannikm/pen/xxzGPRE?editors=100

Reproduction Steps

Check the codepen's sample above.

Reproduction Version

beta.97

Relevant Info

No response

Regression?

No response

Esri team

ArcGIS Scene Viewer

[alisonailea]

We have had some conflicting requests for the right resolution to text overflows in components. We may need to provide an optional prop or find another solution per designer's recommendations. @SkyeSeitz @ashetland

[SkyeSeitz]

Thanks, @alisonailea. Let's connect on all the text overflow requests as a collection.

@yannikmesserli do either of these examples below demonstrate the expected behavior you are describing?

[ashetland]

The truncated version feels like the best failure state in the case. @alisonailea, we should sync up on other components where this occurs. Hopefully a similar strategy will work kit-wide. 🤞

[jcfranco]

Hopefully, we can arrive at a single way of handling this to avoid props if possible. Some additional things to consider:

1. slotted content – depending on the slotted HTML, it won't be possible for us to handle truncation via CSS
2. translations/overrides (near future) – different languages may have strings that impact the original component layout, these can also be overridden by users, which seems closer to this issue
3. a11y – we should be fine here as long as truncation is handled at a visual level and not by manipulating text content

cc @geospatialem @annierm18

[yannikmesserli]

The truncated version feels like the best failure state in the case. @alisonailea, we should sync up on other components where this occurs. Hopefully a similar strategy will work kit-wide. 🤞

Agreed 🪁

We may need to provide an optional prop or find another solution per designer's recommendations.

It probably makes sense to have an optional prop (truncated?). There are probably good uses cases that embed html element that needs to be on the edge, e.g. thumbs, so truncated inline element will break their design.

[geospatialem]

cc fix from #5683 (comment)

[jcfranco]

@ashetland @SkyeSeitz #5683 (comment) addressed this problem in a separate component and its wrapping vs what's proposed above. Should this adopt the same approach? If not, can you chime in on guidelines for dealing with long text?

[SkyeSeitz]

@ashetland @SkyeSeitz #5683 (comment) addressed this problem in a separate component and its wrapping vs what's proposed above. Should this adopt the same approach? If not, can you chime in on guidelines for dealing with long text?

Thanks, Franco. The guideline here would be to truncate long text on fixed width components that should not grow in height, such as the Button discussed above. This is to avoid oversized buttons and/or misalignment as seen below:

Instead, visually truncated text is the preferred failure state.

For components that are meant to grow in height, such as Accordion, the guideline would be to wrap text as seen #5683.

[ashetland]

Summary of discussion about the best way to display the full text:

Preference is for truncated buttons to use html label to display the full text. This would leave calcite-tooltip available for additional context and configurations.

[Elijbet]

Summary of discussion about the best way to display the full text:

Preference is for truncated buttons to use html label to display the full text. This would leave calcite-tooltip available for additional context and configurations.

This comment in a related issue has some details of the implementation #5903 (comment) The image attached here shows how the tooltip and html label would work together in terms of layout, and how the button with those would work in slotted contexts.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified in 1.3.0-next.6.