Intent to Ship: CSS text-overflow: <string> value

[Chromestatus]

Contact emails

jja0...@gmail.com

Explainer

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/text-overflow#string

Specification

https://drafts.csswg.org/css-overflow-4/#text-overflow

Summary

Adds a <string> value to the text-overflow property. This allows web authors to specify a custom string (e.g., "(more)") to indicate that text has been clipped. This provides more design flexibility and can be used to create more user-friendly and context-aware overflow indicators.

Blink component

Blink>CSS

Web Feature ID

custom-ellipses

Motivation

Chromium's text-overflow implementation only supports the clip and ellipsis keywords, so authors who want a different truncation indicator must truncate the text themselves in JavaScript or overlay a positioned pseudo-element on the end of the line. Supporting the specified <string> value lets the browser truncate the text and render the author's chosen indicator together.

Initial public proposal

No information provided

Search tags

text-overflow

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=312156) Some of the new WPTs are broken because of two cases. - Clipping the rendering of the ellipsis itself if there is insufficient space for the ellipsis. https://www.w3.org/TR/css-overflow-4/#ellipsing-details - Suppressing line breaks as Ruby. https://github.com/w3c/csswg-drafts/issues/12557

WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/72631) The PR has been merged but it's not released yet.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None. This is a support CSS value; it does not deprecate or change the behavior of any existing API, so it poses no WebView compatibility risk.

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
`text-overflow-string-*` files in https://wpt.fyi/results/css?label=master&label=experimental&aligned&q=text-overflow-string Note that there is tentatives for "[css-text-3] Discarding Line Breaks Adjacent to Ambiguous Characters". https://github.com/w3c/csswg-drafts/issues/5017

Flag name on about://flags

enable-experimental-web-platform-features

Finch feature name

TextOverflowString

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/41492459

Estimated milestones

Shipping on desktop	156
Shipping on Android	156
Shipping on WebView	156

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6294595288825856?gate=5598631104217088

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a8d82fa.f0bac957.7b6f1.0e10.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Dan Clark]

LGTM1

[Alex Russell]

LGTM2

[Ian Kilpatrick]

What is the interaction with -webkit-line-clamp that is expected? And what have the other browsers implemented with respect to this? (Are there going to be compat issue if something changes later).

Does enabling this feature work with the CSSLineClampLineBreakingEllipsis flag enabled? (How does it handle the BiDi issues in particular?)

Ian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c41567f-0abf-42b0-bd58-3809824afd09n%40chromium.org.

[Minseong Kim]

The expected behavior is that text-overflow: <string> applies to inline overflow inside the clamp container, while -webkit-line-clamp still uses its own default ellipsis.

This follows CSSWG #10823. Regarding Chromium CLs are #6470150 and #6845961.

In the experimental-browser WPT results, all four browsers pass line-clamp-with-text-overflow-string-001/002.

Chromium and Safari also pass 003, but Firefox clips the inline overflow instead of showing the custom string (Bugzilla #2057345, CSSWG #10823)

I also checked with CSSLineClampLineBreakingEllipsis enabled, the new interaction tests pass on locally and wpt.fyi.

For BiDi, CSSWG #12617 resolved that both ellipses are isolates and take their direction from the paragraph. This includes the resolved paragraph direction with unicode-bidi: plaintext.

All four browsers pass text-overflow-string-005/006/007, but Firefox and Safari currently fail the plaintext case in 008.

I have added new WPT tests covering the combined behavior in https://chromium-review.googlesource.com/c/chromium/src/+/8439836.

Thank you for your review.
Minseong

2026년 9월 22일 화요일 오전 3시 54분 25초 UTC+9에 ikilp...@chromium.org님이 작성:

[Rick Byers]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8fa9e623-6fb6-40d2-b770-f1a4f6e98b76n%40chromium.org.