Thank you for the analysis. I agree that this should be fine to ship without additional bindings work.
LGTM2 Thanks, Vlad On Wed, Jul 8, 2026 at 5:33 PM 'Stephanie Zhang' via blink-dev < [email protected]> wrote: > I searched GitHub for exact prototype-chain checks and prototype rewrites > involving Range/StaticRange and AbstractRange. The broad query returned > 80 files > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3D%252F%255Cb%2528%253F%253A%2528%253F%253AStaticRange%257CRange%2529%255C.prototype%255C.__proto__%255Cs*%2528%253F%253A%253D%253D%253D%257C%253D%253D%257C%253D%2529%255Cs*AbstractRange%255C.prototype%257C%2528%253F%253AObject%257CReflect%2529%255C.getPrototypeOf%255C%2528%255Cs*%2528%253F%253AStaticRange%257CRange%2529%255C.prototype%255Cs*%255C%2529%255Cs*%2528%253F%253A%253D%253D%253D%257C%253D%253D%2529%255Cs*AbstractRange%255C.prototype%257CObject%255C.setPrototypeOf%255C%2528%255Cs*%2528%253F%253AStaticRange%257CRange%2529%255C.prototype%255Cs*%252C%255Cs*AbstractRange%255C.prototype%255Cs*%255C%2529%257C%2528%253F%253AStaticRange%257CRange%2529%255C.prototype%255Cs*%253D%255Cs*Object%255C.create%255C%2528%255Cs*AbstractRange%255C.prototype%255Cs*%255C%2529%2529%252F%26type%3Dcode%26p%3D1&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C99b8de6fbaad4980925e08dedd298099%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639191367499644017%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Sn82fiTgOEcq9nsJ9No1JJMAzUTPDiDkf2TPALmNw6M%3D&reserved=0> > 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 > <https://github.com/search?q=%22Range.prototype.__proto__%22+OR+%22StaticRange.prototype.__proto__%22&type=code> > 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) > > On Wednesday, July 8, 2026 at 8:19:30 AM UTC-7 Vladimir Levin wrote: > >> 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 >> >> On Wednesday, July 8, 2026 at 10:59:20 AM UTC-4 Daniel Bratell wrote: >> >>> 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 >>> On 2026-07-07 00:24, 'Stephanie Zhang' via blink-dev wrote: >>> >>> One clarification on the NodeRange CL >>> <https://chromium-review.googlesource.com/c/chromium/src/+/7904930>: >>> it includes a web-exposed inheritance change. It implements the version of >>> `OpaqueRange` agreed upon in WHATWG discussions >>> <https://github.com/whatwg/html/issues/11478#issuecomment-4622847878>, >>> 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? >>> >>> On Thursday, July 2, 2026 at 3:11:57 PM UTC-7 Stephanie Zhang wrote: >>> >>>> One additional update: the WPT dashboard now shows all tests >>>> <https://wpt.fyi/results/dom/ranges/tentative?label=experimental&label=master&aligned> >>>> 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 >>>> <https://chromium-review.googlesource.com/c/chromium/src/+/7904930>, >>>> 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 >>>> <https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/OpaqueRange/explainer.md#extending-to-custom-elements> >>>> and is not part of this ChromeStatus feature. >>>> >>>> On Wednesday, July 1, 2026 at 8:23:08 AM UTC-7 Stephanie Zhang wrote: >>>> >>>>> 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 >>>>> On Tuesday, June 9, 2026 at 9:25:40 AM UTC-7 Daniel Bratell wrote: >>>>> >>>>>> Thanks for the update. Looks like it is close to complete. >>>>>> >>>>>> /Daniel >>>>>> On 2026-06-06 01:09, 'Stephanie Zhang' via blink-dev wrote: >>>>>> >>>>>> 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. >>>>>> On Friday, June 5, 2026 at 4:07:30 PM UTC-7 Stephanie Zhang wrote: >>>>>> >>>>>>> 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: >>>>>>> >>>>>>> - >>>>>>> https://github.com/whatwg/html/issues/11478#issuecomment-4622847878 >>>>>>> - Introduces a new NodeRange interface between AbstractRange >>>>>>> and Range/StaticRange, so startContainer/endContainer live on >>>>>>> NodeRange >>>>>>> instead of AbstractRange. This was something that Apple has been >>>>>>> pushing >>>>>>> for, and they will be driving the spec changes for NodeRange >>>>>>> (slightly out >>>>>>> of date spec draft: Add a BoundaryPointsRange mixin by annevk >>>>>>> · Pull Request #1469 · whatwg/dom >>>>>>> <https://github.com/whatwg/dom/pull/1469>) >>>>>>> - >>>>>>> https://github.com/whatwg/html/issues/11478#issuecomment-4560745107 >>>>>>> - Introduces OpaqueRangeController, so custom elements can >>>>>>> create and mutate an OpaqueRange. Mirrors >>>>>>> AbortController/AbortSignal: >>>>>>> controller mutates, range is read-only. Apple also asked for this >>>>>>> to >>>>>>> support custom elements. >>>>>>> >>>>>>> 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. >>>>>>> On Wednesday, June 3, 2026 at 7:22:55 AM UTC-7 Daniel Bratell wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> On 2026-05-18 18:35, 'Stephanie Zhang' via blink-dev wrote: >>>>>>>> >>>>>>>> Hi all, apologies for the delay. A few of the recent review >>>>>>>> comments on #1404 <https://github.com/whatwg/dom/pull/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. >>>>>>>> >>>>>>>> On Wednesday, May 6, 2026 at 8:11:19 AM UTC-7 Philip Jägenstedt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> On Wed, May 6, 2026 at 3:54 PM Rick Byers <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> <https://wpt.fyi/results/dom/ranges/tentative?label=experimental&label=master&aligned> >>>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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: >>>>>>>>>>> >>>>>>>>>>>> *Contact emails* >>>>>>>>>>>> *[email protected]*, *[email protected]*, >>>>>>>>>>>> *[email protected]*, *[email protected]* >>>>>>>>>>>> *Explainer* >>>>>>>>>>>> >>>>>>>>>>>> *https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/OpaqueRange/explainer.md* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FOpaqueRange%2Fexplainer.md&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872058065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qHzQqtSg2jDdVrEVcd3ms2PDr8nwb5KbNq7s8Z1%2Fpcc%3D&reserved=0> >>>>>>>>>>>> *Specification* >>>>>>>>>>>> *https://github.com/whatwg/dom/pull/1404* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwhatwg%2Fdom%2Fpull%2F1404&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872070768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KkvkSV5EI8Y%2Bo6vEs0kjkkP7xU6ydqCCH2yb5Zbpsy8%3D&reserved=0> >>>>>>>>>>>> *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* >>>>>>>>>>>> *Blink>DOM* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.chromium.org%2Fissues%3Fq%3Dcustomfield1222907%3A%2522Blink%253EDOM%2522&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872081509%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HPwyv0vG7LVjeVQhvsiKMdcyxJaqervtEOH6YqMUYTg%3D&reserved=0> >>>>>>>>>>>> *Web Feature ID* >>>>>>>>>>>> Missing feature >>>>>>>>>>>> *New feature ID for OpaqueRange · Issue #3863 · >>>>>>>>>>>> web-platform-dx/web-features* >>>>>>>>>>>> <https://github.com/web-platform-dx/web-features/issues/3863> >>>>>>>>>>>> >>>>>>>>>>>> *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* >>>>>>>>>>>> *https://github.com/whatwg/html/issues/10614* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwhatwg%2Fhtml%2Fissues%2F10614&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872101415%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BKt7yavrtM8tgFneyHXhDqJCNVLuxh8wPpTh5eh%2FppQ%3D&reserved=0> >>>>>>>>>>>> *TAG review* >>>>>>>>>>>> *https://github.com/w3ctag/design-reviews/issues/1206* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F1206&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872111131%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r2iH%2BQ9l72LwxV2s69aeHlP2E9m8iXutC25JNdF594c%3D&reserved=0> >>>>>>>>>>>> *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* >>>>>>>>>>>> *https://www.youtube.com/watch?v=Sp9C68TZXiE* >>>>>>>>>>>> <https://www.youtube.com/watch?v=Sp9C68TZXiE> >>>>>>>>>>>> *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* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F1289&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872120773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QHBPgBumqgNIEJ%2B3RCSizi6y%2BYqCC6BOQZgacx0ZyEM%3D&reserved=0> >>>>>>>>>>>> ) >>>>>>>>>>>> >>>>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>>>> *https://github.com/WebKit/standards-positions/issues/541* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWebKit%2Fstandards-positions%2Fissues%2F541&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872130815%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d4mAnntEEzmtFS294m9idCHVZOx5CuunvtSl%2FHaHYUE%3D&reserved=0> >>>>>>>>>>>> ) >>>>>>>>>>>> >>>>>>>>>>>> *Web developers*: Positive >>>>>>>>>>>> *https://github.com/w3c/csswg-drafts/issues/4603* >>>>>>>>>>>> <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* >>>>>>>>>>>> <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* >>>>>>>>>>>> <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* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmain%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872169769%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7gMJYElkxzN5Bs5Hnns%2BTpasHNu3e974vzsod5Nw%2FYM%3D&reserved=0> >>>>>>>>>>>> *?* >>>>>>>>>>>> Yes >>>>>>>>>>>> >>>>>>>>>>>> *https://wpt.fyi/results/dom/ranges/tentative?label=experimental&label=master&aligned* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwpt.fyi%2Fresults%2Fdom%2Franges%2Ftentative%3Flabel%3Dexperimental%26label%3Dmaster%26aligned&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872179399%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BoQHWaf8mMxkz6HDuaRR4L%2FEmba7AAaeNFmOj%2Bncggo%3D&reserved=0> >>>>>>>>>>>> *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* >>>>>>>>>>>> *https://issues.chromium.org/issues/421421332* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.chromium.org%2Fissues%2F421421332&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872189082%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bJL4Ql41Aj%2Bg3mB2XJfgclU%2BgkK8mud%2BrkgFiS3ZwkY%3D&reserved=0> >>>>>>>>>>>> *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* >>>>>>>>>>>> >>>>>>>>>>>> *https://chromestatus.com/feature/6297362687066112?gate=6322608320282624* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeature%2F6297362687066112%3Fgate%3D6322608320282624&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872199016%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PS%2F6dCcXujSjM5wRJeg4PQItZOUtpR10DiUmSM0kkKU%3D&reserved=0> >>>>>>>>>>>> *Links to previous Intent discussions* >>>>>>>>>>>> Intent to Prototype: >>>>>>>>>>>> *https://groups.google.com/a/chromium.org/d/msgid/blink-dev/LV9PR21MB5189A114B34C8A3685A3C4A4805CA%40LV9PR21MB5189.namprd21.prod.outlook.com* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FLV9PR21MB5189A114B34C8A3685A3C4A4805CA%2540LV9PR21MB5189.namprd21.prod.outlook.com&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872209532%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0R0lijpaaqqU98Cy4%2BMUKZFvSS98%2BLEX%2BgxN%2F97mUhw%3D&reserved=0> >>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>> *https://groups.google.com/a/chromium.org/g/blink-dev/c/jrIXiBUbQm0* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fg%2Fblink-dev%2Fc%2FjrIXiBUbQm0&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872219502%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WIBn3BC8npIdGiIZMXRihFMpjRK1XX%2BCB1Kj8iiOr8g%3D&reserved=0> >>>>>>>>>>>> This intent message was generated by *Chrome Platform Status* >>>>>>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2F&data=05%7C02%7Cstephanie.zhang%40microsoft.com%7C81a0a04d7bb341a3e49408dea5563241%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639129986872230077%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N%2BjycMAQH6qmt4FMWiMCB1Az2XDQURi0edef9DX6AMg%3D&reserved=0> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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/ae385e61-f3a0-4381-9a0e-2a891581c327n%40chromium.org >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ae385e61-f3a0-4381-9a0e-2a891581c327n%40chromium.org?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/CAFUtAY9ZwvD7mAdJwqQ33Xr4khFTjEo2O3TbeFocwjLJRNJ-_w%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9ZwvD7mAdJwqQ33Xr4khFTjEo2O3TbeFocwjLJRNJ-_w%40mail.gmail.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/2cd4ddfe-cb82-4288-a309-d129f94227fan%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cd4ddfe-cb82-4288-a309-d129f94227fan%40chromium.org?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/c06e60a4-63f8-4c4a-b2a3-e14774a708dan%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c06e60a4-63f8-4c4a-b2a3-e14774a708dan%40chromium.org?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/c17e8239-d9b2-4b90-9e5b-1c40efaafa91n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c17e8239-d9b2-4b90-9e5b-1c40efaafa91n%40chromium.org?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/6f6322be-aebc-454b-bd68-0f3589414264n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6f6322be-aebc-454b-bd68-0f3589414264n%40chromium.org?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/CADsXd2ModTcYtu5JHqzVtzvJCjoCmr0q-G_paYmMWS814Z%2B1EA%40mail.gmail.com.
