Integrate OpaqueRange hooks into text controls (input/textarea) by stephanieyzhang · Pull Request #11741 · whatwg/html

stephanieyzhang · 2025-10-02T20:26:35Z

OpaqueRange is a specialized, live AbstractRange subtype whose boundary points reference internal nodes within host-defined elements (e.g., <input>/<textarea> today, with a path to custom elements in the future). It enables range-based operations over encapsulated content while avoiding exposure of internal DOM nodes.

Explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/OpaqueRange/explainer.md
WhatWG discussion: OpaqueRange Interface #11478
Corresponding DOM Spec PR: Add OpaqueRange interface dom#1404
Corresponding CSSOM PR: [cssom-view-1] Define OpaqueRange geometry APIs (getClientRects/getBoundingClientRect) w3c/csswg-drafts#12904
At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/dom/ranges/tentative?label=master&label=experimental&aligned
- PR to make tests non-tentative: Coming soon
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/421421332
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1990256
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=299375
Corresponding HTML AAM & ARIA in HTML issues & PRs:
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )

annevk

Where is "supports opaque ranges" defined?

stephanieyzhang · 2026-02-09T08:15:07Z

Where is "supports opaque ranges" defined?

Whoops, forgot to define that 🤦. Added it to the "APIs for the text control selections" section. Let me know if you'd prefer it placed elsewhere as I wasn't sure where the best spot for it was.

The new name makes it explicitly clear that a new range is created each time, as suggested in HTML spec PR discussion: whatwg/html#11741 (comment) Updates the OpaqueRangeCreation mixin and IDL, all implementing classes (TextControlElement, HTMLInputElement), and test files. Low-Coverage-Reason: COVERAGE_UNDERREPORTED Bug: 421421332 Change-Id: Iec9572c470443e85d2a38ecd978bd7c78e8c5a86

The new name makes it explicitly clear that a new range is created each time, as suggested in HTML spec PR discussion: whatwg/html#11741 (comment) Updates the OpaqueRangeCreation mixin and IDL, all implementing classes (TextControlElement, HTMLInputElement), and test files. Low-Coverage-Reason: COVERAGE_UNDERREPORTED Bug: 421421332 Change-Id: Iec9572c470443e85d2a38ecd978bd7c78e8c5a86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7595653 Reviewed-by: Dan Clark <daniec@microsoft.com> Commit-Queue: Stephanie Zhang <stephanie.zhang@microsoft.com> Reviewed-by: Mason Freed <masonf@chromium.org> Reviewed-by: Ana Sollano Kim <ansollan@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1591036}

…eateValueRange(), a=testonly Automatic update from web-platform-tests Rename OpaqueRange getValueRange() to createValueRange() The new name makes it explicitly clear that a new range is created each time, as suggested in HTML spec PR discussion: whatwg/html#11741 (comment) Updates the OpaqueRangeCreation mixin and IDL, all implementing classes (TextControlElement, HTMLInputElement), and test files. Low-Coverage-Reason: COVERAGE_UNDERREPORTED Bug: 421421332 Change-Id: Iec9572c470443e85d2a38ecd978bd7c78e8c5a86 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7595653 Reviewed-by: Dan Clark <daniec@microsoft.com> Commit-Queue: Stephanie Zhang <stephanie.zhang@microsoft.com> Reviewed-by: Mason Freed <masonf@chromium.org> Reviewed-by: Ana Sollano Kim <ansollan@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1591036} -- wpt-commits: 4c5d702b40927803c1024376687a6ca84e877720 wpt-pr: 58079

keithamus · 2026-04-30T08:45:01Z

+  <p>Before queuing that task, if the element <span>supports opaque ranges</span>, then run the
+  <span>opaque range replacement steps</span> with the element, the edit's code unit offset, the
+  number of code units removed, and the number of code units inserted.</p>


"Before queuing that task" doesn't seem right.

I think this requires more substantial editing to ensure the steps are in order, so it goes:

Any time the user causes change...

Update opaque ranges

Queue a task.

It might be worth breaking this out into an algorithm so it's easier to follow, rather than a dense paragraph though.

This says to run opaque range replacement steps, and then queue a task to fire the input event. Is that correct? Or should the checking of "supports opaque ranges" and running "opaque range replacement steps" happen in the same task as firing the input event?

keithamus · 2026-04-30T08:46:30Z

  interaction before queuing the task; for example, a user agent could wait for the user to have not
  hit a key for 100ms, so as to only fire the event when the user pauses, instead of continuously
  for each keystroke.</p>
+  <p>Before queuing that task, if the element <span>supports opaque ranges</span>, then run the


Same here, these steps should be in order.

keithamus · 2026-04-30T08:52:22Z

+  <p>A <code>textarea</code> element, or an <code>input</code> element whose <code
+  data-x="attr-input-type">type</code> attribute is in the <span
+  data-x="attr-input-type-text">Text</span>, <span data-x="attr-input-type-search">Search</span>,
+  <span data-x="attr-input-type-tel">Telephone</span>, <span
+  data-x="attr-input-type-url">URL</span>, or <span
+  data-x="attr-input-type-password">Password</span> state, <span>supports opaque ranges</span>.</p>


Why not input type="number"? Seems like it could be useful there too. I guess because setRangeText doesn't apply... which is a much bigger change. Worth thinking about perhaps?

keithamus · 2026-04-30T08:53:55Z

+  data-x="concept-textarea-raw-value">raw value</span>, and the element <span>supports opaque
+  ranges</span>, then run the <span>opaque range full replacement steps</span> with the element,


All textareas seem to support opaque ranges so this if seems unnecessary.

keithamus · 2026-04-30T08:54:32Z

+  content</span>. If this changes the element's <span data-x="concept-fe-api-value">API
+  value</span>, and the element <span>supports opaque ranges</span>, then run the <span>opaque


Likewise here; textareas support opaque ranges so this seems unnecessary.

keithamus · 2026-04-30T08:54:53Z

-   true.</p></li>
+   <li><p>Set this element's <span data-x="concept-fe-dirty">dirty value flag</span> to true.</p></li>
+
+   <li><p>If this changes the element's <span data-x="concept-fe-api-value">API value</span>,


And again here; textareas support opaque ranges so this seems unnecessary.

keithamus · 2026-04-30T08:59:57Z

+  <p>A <code>textarea</code> element, or an <code>input</code> element whose <code
+  data-x="attr-input-type">type</code> attribute is in the <span
+  data-x="attr-input-type-text">Text</span>, <span data-x="attr-input-type-search">Search</span>,
+  <span data-x="attr-input-type-tel">Telephone</span>, <span
+  data-x="attr-input-type-url">URL</span>, or <span
+  data-x="attr-input-type-password">Password</span> state, <span>supports opaque ranges</span>.</p>


Given this is always true for textarea, this could be a concept of input elements only, and perhaps could be a flag (or algo) on input elements. It seems input elements have this concept twice: They have "supports opaque ranges" and also "createValueRange() does not apply" - AIUI these are the same concept?

Unless I'm mistaken in the belief that textareas always support opaque ranges?

stephanieyzhang added 2 commits October 2, 2025 15:25

very rough draft

bd9b54e

undo whitespace

accbe23

stephanieyzhang changed the title ~~Add FormControlRange hooks~~ [DO NOT REVIEW] FormControlRange hooks Oct 2, 2025

additional hooks

4fbc254

stephanieyzhang changed the title ~~[DO NOT REVIEW] FormControlRange hooks~~ Integrate FormControlRange hooks into text controls (input/textarea) Oct 9, 2025

This was referenced Oct 9, 2025

[cssom-view-1] Define OpaqueRange geometry APIs (getClientRects/getBoundingClientRect) w3c/csswg-drafts#12904

Draft

Add OpaqueRange interface whatwg/dom#1404

Open

stephanieyzhang mentioned this pull request Oct 16, 2025

OpaqueRange Interface #11478

Open

stephanieyzhang added 4 commits October 16, 2025 15:47

keep original formatting

96d51de

cleaning up textarea hooks

3155a15

remove unnecessary text control block

90163c4

update mutation alg

7ed3fb7

leotlee mentioned this pull request Nov 6, 2025

WHATUP at TPAC 2025: agenda suggestions #11711

Closed

stephanieyzhang changed the title ~~Integrate FormControlRange hooks into text controls (input/textarea)~~ Integrate PlainTextRange hooks into text controls (input/textarea) Dec 4, 2025

stephanieyzhang added 4 commits December 4, 2025 08:38

rename to PlainTextRange + tpac changes pt 1

202f881

rename to PlainTextRange + tpac changes pt 2

dfe8b08

updated to OpaqueRange + moved update range steps from dom spec

2eef616

Merge branch 'whatwg:main' into stzhang-addfcr

0cf1cbf

stephanieyzhang changed the title ~~Integrate PlainTextRange hooks into text controls (input/textarea)~~ Integrate OpaqueRange hooks into text controls (input/textarea) Jan 14, 2026

stephanieyzhang added 2 commits January 14, 2026 13:04

Add getValueRange

5aa605f

specify supported input types

6b6108c

annevk reviewed Jan 15, 2026

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

add supports opaque range def + reword of range updates

e772b1a

annevk reviewed Feb 9, 2026

View reviewed changes

Comment thread source Outdated

update to use internal containers instead of opaque range string

568cff3

smaug---- reviewed Feb 10, 2026

View reviewed changes

Comment thread source Outdated

annevk linked an issue Feb 12, 2026 that may be closed by this pull request

OpaqueRange Interface #11478

Open

rename getValueRange to createValueRange

580e13e

chromium-wpt-export-bot mentioned this pull request Feb 26, 2026

Rename OpaqueRange getValueRange() to createValueRange() web-platform-tests/wpt#58079

Merged

This was referenced Mar 13, 2026

New feature ID for OpaqueRange web-platform-dx/web-features#3863

Closed

Other Spec Review: OpaqueRange w3ctag/design-reviews#1206

Open

stephanieyzhang marked this pull request as ready for review April 23, 2026 15:57

Add auto-disconnect for input and textarea

7ceff82

stephanieyzhang mentioned this pull request Apr 28, 2026

Add disconnect() method MicrosoftEdge/MSEdgeExplainers#1310

Merged

keithamus suggested changes Apr 30, 2026

View reviewed changes

		data-x="concept-textarea-raw-value">raw value</span>, and the element <span>supports opaque
		ranges</span>, then run the <span>opaque range full replacement steps</span> with the element,

		content</span>. If this changes the element's <span data-x="concept-fe-api-value">API
		value</span>, and the element <span>supports opaque ranges</span>, then run the <span>opaque

Conversation

stephanieyzhang commented Oct 2, 2025 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stephanieyzhang commented Feb 9, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

stephanieyzhang commented Oct 2, 2025 •

edited by pr-preview Bot

Loading