Intent to Ship: OpaqueRange

635 views
Skip to first unread message

Stephanie Zhang

unread,
Apr 29, 2026, 3:12:53 PMApr 29
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.
 

Alex Russell

unread,
May 4, 2026, 2:42:08 PMMay 4
to blink-dev, Stephanie Zhang
Hey Stephanie (et al.),

Excited about this feature. Am I right in assuming that nobody has been able to provide OT feedback yet? If there has been feedback, can you summarize it here?

Best,

Alex

On Wednesday, April 29, 2026 at 12:12:53 PM UTC-7 Stephanie Zhang wrote:

Rick Byers

unread,
May 6, 2026, 9:54:43 AMMay 6
to Alex Russell, blink-dev, Stephanie Zhang
It would be nice to hear more about OT feedback, but knowing that the Microsoft Editor SDK has validated the design and plans to adopt it meets my bar for developer feedback on a relatively small feature like this. So LGTM1 from me.

It's nice to see the WPT suite very green. Is someone looking at why a few tests appear to be passing in Edge but failing in Chrome?

Rick

On Mon, May 4, 2026 at 2:42 PM Alex Russell <sligh...@chromium.org> wrote:
Hey Stephanie (et al.),

Excited about this feature. Am I right in assuming that nobody has been able to provide OT feedback yet? If there has been feedback, can you summarize it here?

Best,

Alex

On Wednesday, April 29, 2026 at 12:12:53 PM UTC-7 Stephanie Zhang wrote:

--
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/ae385e61-f3a0-4381-9a0e-2a891581c327n%40chromium.org.

Philip Jägenstedt

unread,
May 6, 2026, 11:11:19 AMMay 6
to Rick Byers, Alex Russell, blink-dev, Stephanie Zhang
What are the remaining blockers to land https://github.com/whatwg/dom/pull/1404? All of the checkboxes are checked, is it a matter of editorial review now?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9ZwvD7mAdJwqQ33Xr4khFTjEo2O3TbeFocwjLJRNJ-_w%40mail.gmail.com.

Stephanie Zhang

unread,
May 18, 2026, 12:35:09 PMMay 18
to blink-dev, Philip Jägenstedt, Alex Russell, blink-dev, Stephanie Zhang, Rick Byers
Hi all, apologies for the delay. A few of the recent review comments on #1404 are on API shape rather than purely editorial, so we won't be shipping in 149. I'll follow up with the new release target once those are resolved.

Since the original intent:
  • Mozilla and WebKit: positive signals on standards-positions.
  • Alex: no external OT feedback yet beyond the Microsoft Editor SDK team, who plan to integrate ahead of ship.
  • Rick: looking into the Edge-vs-Chrome WPT diffs; will follow up.
  • Philip: the open API-shape comments on #1404 are the remaining blocker.
Thanks for the patience.

Alex Russell

unread,
May 26, 2026, 2:38:12 PMMay 26
to blink-dev, Stephanie Zhang, Philip Jägenstedt, Alex Russell, blink-dev, Rick Byers
LGTM2; great to hear the Editor team is on board.

On the ongoing API shape issues, please feel confident to ship the things customers tell us they really need, even if that's a superset of what other vendors (belatedly, without customer feedback) think is needed. Just know that we will look askance at future requests to deprecate and remove parts of what you ship now.

Best,

Alex

Daniel Bratell

unread,
Jun 3, 2026, 10:22:55 AMJun 3
to Stephanie Zhang, blink-dev, Philip Jägenstedt, Alex Russell, Rick Byers

Do you have an update on the #1404 changes? I took a quick look at the issue but could not determine the current state of it.

/Daniel

Stephanie Zhang

unread,
Jun 5, 2026, 7:07:30 PMJun 5
to blink-dev, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers, Stephanie Zhang
Hi all, quick update:
 
 The remaining API-shape work from #1404 has moved into two focused threads, and both need to be finalized before we ship:
Chromium implementation CLs for both are in process and will be gated on the existing OpaqueRange runtime flag (plus an inverse LegacyAbstractRange flag for the NodeRange migration). 
 
Our current shipping target is M153.

Stephanie Zhang

unread,
Jun 5, 2026, 7:09:44 PMJun 5
to blink-dev, Stephanie Zhang, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers
I'll update the ChromeStatus descriptions and explainers with the new shape once the spec discussions settle -- wanted to give an early heads-up here.

Daniel Bratell

unread,
Jun 9, 2026, 12:25:40 PMJun 9
to Stephanie Zhang, blink-dev, Philip Jägenstedt, Alex Russell, Rick Byers

Thanks for the update. Looks like it is close to complete.

/Daniel

Stephanie Zhang

unread,
Jul 1, 2026, 11:23:08 AMJul 1
to blink-dev, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers, Stephanie Zhang
Hi all, quick update on OpaqueRange.

The remaining API-shape discussion is about custom-element-created OpaqueRanges, which were not part of the Origin Trial and are not needed for the original `<textarea>` / supported text-like `<input>` use cases.

For text controls, the API remains unchanged: `createValueRange()` creates OpaqueRanges over value text, usable with geometry APIs and Custom Highlight without exposing internal DOM. This is the surface Microsoft Editor SDK validated and plans to adopt.

The remaining ship blocker is the DOM hierarchy cleanup (`NodeRange` between `AbstractRange` and `Range`/`StaticRange`). This changes where Range/StaticRange container attributes live, but does not change OpaqueRange behavior:
DOM Spec PR for NodeRange (driven by WebKit): https://github.com/whatwg/dom/pull/1470
CL for NodeRange: https://chromium-review.googlesource.com/c/chromium/src/+/7904930

I’ll continue the custom-element discussion separately: https://github.com/whatwg/html/issues/11478
Message has been deleted

Stephanie Zhang

unread,
Jul 2, 2026, 6:11:57 PMJul 2
to blink-dev, Stephanie Zhang, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers
One additional update: the WPT dashboard now shows all tests passing in both Chrome and Edge. I did not make any related changes, however when I investigated back in May, it appeared likely to be due to platform differences between Chrome’s Linux runs and Edge’s Windows runs. So, I believe the WPT discrepancy is resolved.

The remaining DOM spec changes are editorial. The last blocker to shipping is the NodeRange implementation CL, which I hope to land by the end of next week.

We are aiming to ship OpaqueRange in M152. Custom-elements support is considered future work and is not part of this ChromeStatus feature.
Screenshot 2026-07-02 151109.png

Stephanie Zhang

unread,
Jul 6, 2026, 6:24:35 PM (13 days ago) Jul 6
to blink-dev, Stephanie Zhang, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers
One clarification on the NodeRange CL: it includes a web-exposed inheritance change. It implements the version of `OpaqueRange` agreed upon in WHATWG discussions, which has support from both WebKit and Gecko reviewers:

Current shape:
AbstractRange
  -> Range
  -> StaticRange

New shape:
AbstractRange
  -> NodeRange
     --> Range
     --> StaticRange
  -> OpaqueRange

In the CL, `Range` and `StaticRange` now inherit from `NodeRange`, and `OpaqueRange` inherits directly from `AbstractRange`, so it can avoid exposing internal DOM containers (`startContainer` / `endContainer`).

Existing `Range` / `StaticRange` behavior should otherwise continue to work as before. The observable change is for code that checks the exact prototype chain. E.g.:

Object.getPrototypeOf(Range.prototype) === AbstractRange.prototype;
// Before: true. After this CL: false.

Object.getPrototypeOf(Object.getPrototypeOf(Range.prototype)) === AbstractRange.prototype;
// After this CL: true.

In the CL, `NodeRange`’s exposed interface/members are gated with the existing `OpaqueRange` flag. To preserve the current `AbstractRange` shape during the transition, the CL adds `LegacyAbstractRange` as an inverse flag of `OpaqueRange`, so that while `OpaqueRange` is disabled, `startContainer` / `endContainer` continue to be exposed on `AbstractRange`. However, the change to insert `NodeRange` into the inheritance hierarchy is not flagged as fully gating that part would require additional Blink bindings work.

Is it acceptable to proceed with this inheritance change as part of the `OpaqueRange` ship work, or would you prefer that we do the extra bindings work needed to keep the `NodeRange` inheritance change fully gated until `OpaqueRange` ships?
Message has been deleted

Daniel Bratell

unread,
Jul 8, 2026, 10:59:20 AM (11 days ago) Jul 8
to Stephanie Zhang, blink-dev, Philip Jägenstedt, Alex Russell, Rick Byers

LGTM1 shipping with or without the new hierarchy tree, which as I see it won't affect OpaqueRange by itself, but maybe you want to bundle it.

/Daniel

Vladimir Levin

unread,
Jul 8, 2026, 11:19:30 AM (11 days ago) Jul 8
to blink-dev, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers, Stephanie Zhang
Hey, regarding the question of binding changes: can you do a search on github to see if there are any code that will potentially break due to the change in inheritance? One risk here is that if there is any checks for this type of inheritance in some library, then sites can be affected and break in subtle ways.

If there are no checks for this, then I'd be fine with approving without extra bindings work. However, if there is are a lot of these checks or checks in libraries, then we need to consider the risk more carefully.

Thanks,
Vlad

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

Stephanie Zhang

unread,
Jul 8, 2026, 5:33:23 PM (11 days ago) Jul 8
to blink-dev, Vladimir Levin, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers, Stephanie Zhang

I searched GitHub for exact prototype-chain checks and prototype rewrites involving Range/StaticRange and AbstractRange. The broad query returned 80 files and the hits were prototype rewrites like:
Range.prototype.__proto__ = AbstractRange.prototype
StaticRange.prototype.__proto__ = AbstractRange.prototype
Object.setPrototypeOf(StaticRange.prototype, AbstractRange.prototype)

I did not find exact prototype-chain checks like:
Object.getPrototypeOf(Range.prototype) === AbstractRange.prototype

The hits appear to be browser-environment emulation code for crawling/reverse-engineering, not production site code or published web libraries. For example, several results are in repos/directories named `WebCrawling`, `boda_jsEnv`, and the surrounding code defines browser-like globals/prototypes rather than application logic. Many results also appear to be forks or repeated copies of the same few codebases, so the 80 hit count does not represent 80 independent usages.

A broader search of  Range.prototype.__proto__  and   StaticRange.prototype.__proto__   didn't turn up anything additional of concern. It was mostly the same emulation code as stated above and some WebKit Web Inspector code that doesn't affect Chromium.

So, these results are relevant in that the code assumes the current direct Range/StaticRange -> AbstractRange relationship, but I don’t see any evidence that real sites or widely used frontend libraries depend on that old direct inheritance shape. Based on this, I think we’re okay to ship the inheritance change without doing the extra bindings work to fully gate it.


The Github regex query linked earlier covers the following cases (including whitespace variants):

Range.prototype.__proto__ = AbstractRange.prototype
Range.prototype.__proto__ == AbstractRange.prototype
Range.prototype.__proto__ === AbstractRange.prototype

StaticRange.prototype.__proto__ = AbstractRange.prototype
StaticRange.prototype.__proto__ == AbstractRange.prototype
StaticRange.prototype.__proto__ === AbstractRange.prototype

Object.getPrototypeOf(Range.prototype) == AbstractRange.prototype
Object.getPrototypeOf(Range.prototype) === AbstractRange.prototype
Object.getPrototypeOf(StaticRange.prototype) == AbstractRange.prototype
Object.getPrototypeOf(StaticRange.prototype) === AbstractRange.prototype
Reflect.getPrototypeOf(Range.prototype) == AbstractRange.prototype
Reflect.getPrototypeOf(Range.prototype) === AbstractRange.prototype
Reflect.getPrototypeOf(StaticRange.prototype) == AbstractRange.prototype
Reflect.getPrototypeOf(StaticRange.prototype) === AbstractRange.prototype
Object.setPrototypeOf(Range.prototype, AbstractRange.prototype)
Object.setPrototypeOf(StaticRange.prototype, AbstractRange.prototype)

Range.prototype = Object.create(AbstractRange.prototype)
StaticRange.prototype = Object.create(AbstractRange.prototype)

Vladimir Levin

unread,
Jul 9, 2026, 10:41:21 AM (10 days ago) Jul 9
to Stephanie Zhang, blink-dev, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers
Thank you for the analysis. I agree that this should be fine to ship without additional bindings work.

LGTM2

Thanks,
Vlad

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6f6322be-aebc-454b-bd68-0f3589414264n%40chromium.org.

Chris Harrelson

unread,
Jul 9, 2026, 11:44:07 AM (10 days ago) Jul 9
to Vladimir Levin, Stephanie Zhang, blink-dev, Daniel Bratell, Philip Jägenstedt, Alex Russell, Rick Byers
LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2ModTcYtu5JHqzVtzvJCjoCmr0q-G_paYmMWS814Z%2B1EA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages