Intent to Ship: Clip Text overflow on user interaction

38 views
Skip to first unread message

Shweta Bindal

unread,
10:06 AM (7 hours ago) 10:06 AM
to blin...@chromium.org, Clipboard and Editing (Edge IDC)
Contact emails
Specification
Summary
When a user interacts (editing or caret navigation) with text which has ‘text-overflow: ellipsis’ set, the text switches temporarily from ellipsis to clip allowing the user to see and interact with the hidden overflow content. This feature applies to all editable and non-editable elements. For form controls (textarea, input), the behavior is already supported.

Blink component
Web Feature ID
Motivation
When a text container uses CSS property text-overflow: ellipsis to truncate overflowing content, users editing that text need to see the actual content rather than “...”. This feature ensures that whenever there is a active selection focus (i.e., the user is editing or navigating), the ellipsis is temporarily replaced with clipped text, allowing the user to see and edit the whole text content. Chrome currently implements it only for text control elements (<input>, <textarea>), so in other elements the text is rendered as ellipsis while editing as well. Example: Currently, users cannot navigate beyond the ellipses or type anything. The caret and new characters are hidden behind the ellipsis.*
┌─────────────────────────────────┐
│ This is a long text that ge... │ ← User is typing here but can't see it!
└─────────────────────────────────┘
New behavior: This implementation extends the same capability to all HTML elements. With the fix, when a user types in an ellipsed region, the container scrolls to reveal the caret and the newly inserted text.

Initial public proposal
No information provided

TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
No information provided

Gecko: Shipped/Shipping

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/624)

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?
No information provided


Debuggability
No information provided

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

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


Flag name on about://flags
No information provided

Finch feature name
TextOverflowClipWithSelection

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
Estimated milestones
Shipping on desktop
148
DevTrial on desktop
147
Shipping on Android
148
DevTrial on Android
147
Shipping on WebView
148
Shipping on iOS
148
DevTrial on iOS
147


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
This intent message was generated by Chrome Platform Status.

Vladimir Levin

unread,
10:45 AM (7 hours ago) 10:45 AM
to Shweta Bindal, blin...@chromium.org, Clipboard and Editing (Edge IDC)
On Mon, Mar 9, 2026 at 10:06 AM 'Shweta Bindal' via blink-dev <blin...@chromium.org> wrote:
Contact emails
Specification
Summary
When a user interacts (editing or caret navigation) with text which has ‘text-overflow: ellipsis’ set, the text switches temporarily from ellipsis to clip allowing the user to see and interact with the hidden overflow content. This feature applies to all editable and non-editable elements. For form controls (textarea, input), the behavior is already supported.

Blink component
Web Feature ID
Motivation
When a text container uses CSS property text-overflow: ellipsis to truncate overflowing content, users editing that text need to see the actual content rather than “...”. This feature ensures that whenever there is a active selection focus (i.e., the user is editing or navigating), the ellipsis is temporarily replaced with clipped text, allowing the user to see and edit the whole text content. Chrome currently implements it only for text control elements (<input>, <textarea>), so in other elements the text is rendered as ellipsis while editing as well. Example: Currently, users cannot navigate beyond the ellipses or type anything. The caret and new characters are hidden behind the ellipsis.*
┌─────────────────────────────────┐
│ This is a long text that ge... │ ← User is typing here but can't see it!
└─────────────────────────────────┘
New behavior: This implementation extends the same capability to all HTML elements. With the fix, when a user types in an ellipsed region, the container scrolls to reveal the caret and the newly inserted text.

This looks pretty useful!

I'd like to clarify the behavior change: it's not just that the ellipsis becomes a clip, but also that the text content is "scrolled" so that the caret and the insertion point are visible. Is that correct? Is that also the case for something like a <div contenteditable> that would not otherwise be a scroller (ie overflow: clip; text-overflow: ellipsis)? The reason I'm curious about this is that the contenteditable div can contain content other than text, not sure if there are some layout implications because of that.

Also I assume this new change would be web observable, is that right? 

Thanks!
Vlad

--
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/JH0P153MB1062119E5D93C999CA69CE75D179A%40JH0P153MB1062.APCP153.PROD.OUTLOOK.COM.
Reply all
Reply to author
Forward
0 new messages