Intent to Prototype: getSelectionBoundingClientRect() for <textarea> and <input> elements

121 views
Skip to first unread message

Andres Regalado Rosas

unread,
Jun 17, 2025, 1:47:06 PMJun 17
to blin...@chromium.org, Leo Lee, Mike Jackson (EDGE), Daniel Clark, Ana Sollano Kim
Contact emails
Explainer
Specification
None

Summary
Implements retrieval of selection bounds within <textarea> and <input> elements of type text, email, number, password, search, tel, or url. The bounding rectangle is the caret rectangle if the selection is collapsed. If there is no selection in the <textarea> or <input>, it will return an empty rectangle.

Blink component
Motivation
While getBoundingClientRect() can already be used to obtain selection bounds in content-editable <div> elements, no equivalent exists for standard form input elements. As a result, developers must resort to workarounds involving <div> elements to simulate input behavior, which is both inefficient and unnecessarily complex. This is due to the fact that, unlike <textarea> and <input>, the <div> element isn’t designed for user input—it lacks built-in accessibility, native form behavior, and requires additional JavaScript to simulate basic input functionality. By contrast, getSelectionBoundingClientRect() provides a simpler and more intuitive solution for web developers. It allows them to work directly with standard form elements without needing to reimplement input behavior or manage accessibility concerns manually. This makes it a more robust and developer-friendly alternative for handling selection bounds in web applications.

Initial public proposal
TAG review
None

TAG review status
Pending

Risks

Interoperability and Compatibility
Low risk. WHATWG supports getSelectionBoundingClientRect() API: https://github.com/whatwg/html/issues/10614#issuecomment-2383760604

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1249) No official signal, but no objections shared in the discussion here https://github.com/whatwg/meta/issues/326#issuecomment-2377500295

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/512) Positive based on https://github.com/whatwg/meta/issues/326#issuecomment-2377500295

Web developers: Positive (https://github.com/web-platform-dx/developer-research/tree/main/mdn-short-surveys/2024-12-05-text-edit) Strong interest from web developers in a recent MDN short survey.

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

Debuggability
No specific DevTools changes required.

Is this feature fully tested by web-platform-tests?
Not currently tested, but tests will be added as part of feature development.

Flag name on about://flags
None

Finch feature name
Pending

Non-finch justification
A flag will be added as part of feature development.

Requires code in //chrome?
False

Tracking bug

Estimated milestones
No milestones specified

Link to entry on the Chrome Platform Status

Stephen Chenney

unread,
Jun 18, 2025, 1:05:25 PMJun 18
to Andres Regalado Rosas, blin...@chromium.org, Leo Lee, Mike Jackson (EDGE), Daniel Clark, Ana Sollano Kim
On Tue, Jun 17, 2025 at 1:47 PM 'Andres Regalado Rosas' via blink-dev <blin...@chromium.org> wrote:
Contact emails
Explainer
Specification
None

Summary
Implements retrieval of selection bounds within <textarea> and <input> elements of type text, email, number, password, search, tel, or url. The bounding rectangle is the caret rectangle if the selection is collapsed. If there is no selection in the <textarea> or <input>, it will return an empty rectangle.

Blink component
Motivation
While getBoundingClientRect() can already be used to obtain selection bounds in content-editable <div> elements, no equivalent exists for standard form input elements. As a result, developers must resort to workarounds involving <div> elements to simulate input behavior, which is both inefficient and unnecessarily complex. This is due to the fact that, unlike <textarea> and <input>, the <div> element isn’t designed for user input—it lacks built-in accessibility, native form behavior, and requires additional JavaScript to simulate basic input functionality. By contrast, getSelectionBoundingClientRect() provides a simpler and more intuitive solution for web developers. It allows them to work directly with standard form elements without needing to reimplement input behavior or manage accessibility concerns manually. This makes it a more robust and developer-friendly alternative for handling selection bounds in web applications.


When you say "selection bounds" do you mean the bounds of selected content, or do you mean the bounds of the rectangle that the browser would draw for the selection highlight were the text to be selected?

Could you give some use cases for the feature? When we proposed this for canvas text it was because the user must draw their own selection rect in that case, but in the DOM the selection rect is already drawn and styleable.
 

--
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/MW2PR2101MB09222727A956427F09B985AC8070A%40MW2PR2101MB0922.namprd21.prod.outlook.com.

Andres Regalado Rosas

unread,
Jul 22, 2025, 4:11:06 PMJul 22
to Stephen Chenney, blin...@chromium.org, Leo Lee, Mike Jackson (EDGE), Daniel Clark, Ana Sollano Kim
Based on feedback, we are now exploring a new direction, as getSelectionBoundingClientRect() didn't resolve other Range-based operations for <textarea> and <input> elements. Some of the use cases for this new feature are placing a popup near the caret when the user presses a certain key and marking syntax errors using the Custom Highlight API.

Our new proposal is being tracked under FormControlRange Interface. We also created a new I2P for this proposal, and the corresponding explainer can be found here.

Thanks,
Andrés.
From: Stephen Chenney <sche...@chromium.org>
Sent: Wednesday, June 18, 2025 10:05 AM
To: Andres Regalado Rosas <t-and...@microsoft.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Leo Lee <Leo...@microsoft.com>; Mike Jackson (EDGE) <mjac...@microsoft.com>; Daniel Clark <dan...@microsoft.com>; Ana Sollano Kim <Ana.S...@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Prototype: getSelectionBoundingClientRect() for <textarea> and <input> elements
 
You don't often get email from sche...@chromium.org. Learn why this is important
Reply all
Reply to author
Forward
0 new messages