Contact emails t-andre...@microsoft.com<mailto:t-andre...@microsoft.com>, ansol...@microsoft.com<mailto:ansol...@microsoft.com>, leo...@microsoft.com<mailto:leo...@microsoft.com>, mjack...@microsoft.com<mailto:mjack...@microsoft.com>
Explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/GetSelectionBoundingClientRect/explainer.md 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 Blink>Editing>Selection<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EEditing%3ESelection%22> 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 https://github.com/whatwg/html/issues/10614 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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? 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 https://issues.chromium.org/issues/421421332 Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6315564452282368?gate=5155359647596544 -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PR2101MB09222727A956427F09B985AC8070A%40MW2PR2101MB0922.namprd21.prod.outlook.com.