LGTM3 On Thu, Jul 9, 2026 at 7:40 AM Vladimir Levin <[email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2ModTcYtu5JHqzVtzvJCjoCmr0q-G_paYmMWS814Z%2B1EA%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/CAOMQ%2Bw9%3DoSCAaMOawVrqgQEXtHsn8Mg%3DScNgpdd%2B-YbB-V0yOg%40mail.gmail.com.
