Hi @Vladimir Levin<mailto:[email protected]> 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 <[email protected]> Sent: Monday, March 9, 2026 8:15 PM To: Shweta Bindal <[email protected]> Cc: [email protected] <[email protected]>; Clipboard and Editing (Edge IDC) <[email protected]> Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clip Text overflow on user interaction You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> On Mon, Mar 9, 2026 at 10:06 AM 'Shweta Bindal' via blink-dev <[email protected]<mailto:[email protected]>> wrote: Contact emails [email protected]<mailto:[email protected]> Specification https://www.w3.org/TR/css-overflow-3/#ellipsis-interaction 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 Blink<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> Web Feature ID custom-ellipses<https://webstatus.dev/features/custom-ellipses> 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 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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? 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 https://issues.chromium.org/issues/40731275 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 https://chromestatus.com/feature/5146265241387008?gate=6526353862164480 This intent message was generated by Chrome Platform Status<https://chromestatus.com/>. -- 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 [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/JH0P153MB1062119E5D93C999CA69CE75D179A%40JH0P153MB1062.APCP153.PROD.OUTLOOK.COM<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/JH0P153MB1062119E5D93C999CA69CE75D179A%40JH0P153MB1062.APCP153.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/JH0P153MB106219311492B03473883814D146A%40JH0P153MB1062.APCP153.PROD.OUTLOOK.COM.
