Intent to Ship: Clip Text overflow on user interaction

157 views
Skip to first unread message

Shweta Bindal

unread,
Mar 9, 2026, 10:06:42 AM (7 days ago)  Mar 9
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,
Mar 9, 2026, 10:45:44 AM (7 days ago)  Mar 9
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 .

Shweta Bindal

unread,
Mar 10, 2026, 6:52:42 AM (7 days ago)  Mar 10
to Vladimir Levin, blin...@chromium.org, Clipboard and Editing (Edge IDC)
When focus/selection is inside the text-overflow owner, ellipsis suppression applies (clip-like behavior). Actual scrolling still depends on overflow semantics (e.g., overflow: clip vs hidden).
So, for overflow:clip the container won't scroll. And yes it will be web observable.

Regards,
Shweta
From: Vladimir Levin < vmp...@chromium.org >
Sent: Monday, March 9, 2026 8:15 PM
To: Shweta Bindal < shweta...@microsoft.com >
Cc: blin...@chromium.org < blin...@chromium.org >; Clipboard and Editing (Edge IDC) < pixel...@microsoft.com >
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clip Text overflow on user interaction
You don't often get email from vmp...@chromium.org . Learn why this is important

Vladimir Levin

unread,
Mar 10, 2026, 2:54:48 PM (6 days ago)  Mar 10
to Shweta Bindal, blin...@chromium.org, Clipboard and Editing (Edge IDC)
Thank you for your responses. I will note that although selection switches to clip-like behavior, it seems like cmd-a (on mac) to select all does not seem to switch the ellipsis to a clip-like behavior, not sure if that's intentional.

I don't know if there's interop between browsers, since I could spot a few differences between how Firefox and Chrome (with the flag) work, but I think the spec allows for both behaviors.

LGTM1

Thanks,
Vlad

Alex Russell

unread,
Mar 10, 2026, 6:16:32 PM (6 days ago)  Mar 10
to blink-dev, Vladimir Levin, blin...@chromium.org, Clipboard and Editing (Edge IDC), Shweta Bindal
I'm slightly concerned that we don't have any signals from web developers, and I note that there's also no explainer. It would be great if we could enunciate the problem we're solving, why it matters to developers, and get them to weigh in on the value of the feature.

If you're already working with partners that are looking forward to this change, are you able to get them to weigh in here, or proxy their needs in a summary of some sort?

Thanks,

Alex



To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org .
--
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+unsubscribe@chromium.org .

Yoav Weiss (@Shopify)

unread,
Mar 11, 2026, 1:56:48 AM (6 days ago)  Mar 11
to Shweta Bindal, blin...@chromium.org, Clipboard and Editing (Edge IDC)
Links to relevant bugs/tests?

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

Why not? Which ones are not supported? 

Is this feature fully tested by web-platform-tests ?
No
Can you add tests?
--
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 .

Alex Russell

unread,
Mar 11, 2026, 11:25:14 AM (5 days ago)  Mar 11
to blink-dev, Yoav Weiss, blin...@chromium.org, Clipboard and Editing (Edge IDC), Shweta Bindal
Vlad was kind enough to demo both behaviours for API OWNERS this morning, and this feels like a straight-up bugfix.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org .

Philip Jägenstedt

unread,
Mar 11, 2026, 11:43:41 AM (5 days ago)  Mar 11
to Alex Russell, blink-dev, Yoav Weiss, Clipboard and Editing (Edge IDC), Shweta Bindal
LGTM3 with the condition that some tests are added. This ought to be testable in WPT, possibly using testdriver.js is placing the caret with JS APIs isn't possible.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org .
--
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/c9a5a2f4-162d-40de-86af-54ccb336d73en%40chromium.org .

Shweta Bindal

unread,
Mar 12, 2026, 8:02:58 AM (4 days ago)  Mar 12
to Philip Jägenstedt, yoav...@chromium.org, blink-dev, Yoav Weiss, Clipboard and Editing (Edge IDC)
Hi Philip and Yoav,
I have written the wpts. And it is supported on all platforms. Sorry, I missed to update those entries earlier. I have updated the entries yesterday. 
From:  Philip Jägenstedt < foo...@chromium.org >
Sent:  Wednesday, March 11, 2026 9:13 PM
To:  Alex Russell < sligh...@chromium.org >
Cc:  blink-dev < blin...@chromium.org >; Yoav Weiss < yoav...@chromium.org >; Clipboard and Editing (Edge IDC) < pixel...@microsoft.com >; Shweta Bindal < shweta...@microsoft.com >

Subject:  [EXTERNAL] Re: [blink-dev] Intent to Ship: Clip Text overflow on user interaction
You don't often get email from foo...@chromium.org . Learn why this is important
Reply all
Reply to author
Forward
0 new messages