Intent to Ship: OpaqueRange

Skip to first unread message

Stephanie Zhang

unread,
3:12 PM (5 hours ago) 3:12 PM
to blin...@chromium.org
Contact emails
Explainer
Specification
Summary
`OpaqueRange` represents a live span of text within a form control’s value, such as a `<textarea>` or text-based `<input>`, so developers can work with value text using range-like APIs. It enables operations such as `getBoundingClientRect()`, `getClientRects()`, and integration with the CSS Custom Highlight API for UI such as inline suggestions, highlights, and anchored popovers. It preserves encapsulation by exposing only value offsets while returning `null` for `startContainer` and `endContainer`, so DOM endpoints and internal structure are not exposed.
Blink component
Web Feature ID­­
Missing feature
 
Motivation
Currently, developers can’t get accurate text geometry or apply the CSS Custom Highlight API to text inside native `<textarea>` and text-based `<input>` controls. As a result, they often avoid native form controls and build editable `<div>`-based workarounds to anchor UI, such as autocomplete popovers, or to highlight matches. These workarounds require reimplementing native editing behavior and can have accessibility gaps. `OpaqueRange` enables range-based operations on the control’s value text, so developers can measure text geometry and build text-anchored UI directly in native controls.
Initial public proposal
TAG review
TAG review status
Pending
Origin Trial Name
OpaqueRange
Goals for experimentation
Validate API design and gather developer feedback on whether the API meets their needs.
Chromium Trial Name
OpaqueRange
Origin Trial documentation link
WebFeature UseCounter name
kOpaqueRange
Risks
 
Interoperability and Compatibility
`OpaqueRange` adds new methods, such as `createValueRange()`, to `<textarea>` and supported text-based `<input>` elements so authors can create ranges over value text. It does not change existing editing or selection behavior, so the risk to existing sites is low. The main interoperability risk is lack of implementation across engines, which could make text-anchored UI or highlights inside native controls work in only some browsers.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1289)

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

Web developers: Positive 
https://github.com/w3c/csswg-drafts/issues/4603: request for ranges inside `<textarea>`/`<input>` to support spellchecking/grammar highlights.
https://github.com/w3c/csswg-drafts/issues/10346: request for selection/caret geometry in `<textarea>`/`<input>` to anchor autocomplete popovers and similar UI. https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1104: developer feedback that `OpaqueRange` (previously `FormControlRange`) would be useful because existing overlay workarounds are hard to keep in sync and can visibly lag.


Other signals:
Ergonomics
`OpaqueRange` is typically used with selection offsets and with geometry/highlighting APIs. The geometry calls are synchronous and can trigger layout, similar to existing `Range` geometry methods. Since the range is live, offsets are updated as the control’s value is edited.
Activation
Moderate. Developers need to learn the value-offset model and how it differs from `Range` (there are no DOM endpoints).
Security
No new data exposure beyond existing access to form control values and selection. Exposes only value offsets and geometry and does not expose internal DOM (`startContainer`/`endContainer` are `null`).
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?
Low. `OpaqueRange` adds a new method to `<textarea>` and supported text-based `<input>` elements, but does not change or deprecate any existing behavior.
 
Debuggability
No DevTools changes required.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Works on all platforms that support `<input>` and `<textarea>` elements.
Is this feature fully tested by web-platform-tests?
Flag name on about://flags
No information provided
Finch feature name
OpaqueRange
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
False
Tracking bug
Measurement
UseCounter `OpaqueRange` measures successful creation of `OpaqueRange` objects on `<textarea>` and text-based `<input>` elements.
Availability expectation
Feature is available only in Chromium browsers for the foreseeable future. `OpaqueRange` is at WHATWG Stage 2 with informal approval of the current spec direction from Mozilla and WebKit reviewers and is moving toward Stage 3. We are continuing to seek official standards positions from Mozilla and WebKit.
Adoption expectation
Feature is expected to be used by specific partner(s) within 12 months of launch in Chrome. The Microsoft Editor SDK team has confirmed plans to adopt the feature and intends to land integration behind a switch ahead of ship.
Adoption plan
Stay engaged with Microsoft Editor SDK on rollout. Continue WHATWG work toward Stage 3; seek formal Firefox/WebKit positions. Monitor use counter and bug reports post-ship. Developer outreach already underway on Mastodon, Bluesky, YouTube, LinkedIn.
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
No
Estimated milestones
Shipping on desktop 149
Origin trial desktop first 148
Origin trial desktop last 150
DevTrial on desktop 148
Shipping on Android 149
Origin trial Android first 148
Origin trial Android last 150
DevTrial on Android 148
Shipping on WebView 149
Origin trial WebView first 148
Origin trial WebView last 150
 
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 known non-backward-compatible spec changes are expected. The spec PRs are under active review, and any remaining feedback is expected to be editorial or otherwise backward-compatible.
Link to entry on the Chrome Platform Status
Links to previous Intent discussions
This intent message was generated by Chrome Platform Status.
 
Reply all
Reply to author
Forward
0 new messages