Skip to content

Integrate OpaqueRange hooks into text controls (input/textarea)#11741

Open
stephanieyzhang wants to merge 21 commits into
whatwg:mainfrom
stephanieyzhang:stzhang-addfcr
Open

Integrate OpaqueRange hooks into text controls (input/textarea)#11741
stephanieyzhang wants to merge 21 commits into
whatwg:mainfrom
stephanieyzhang:stzhang-addfcr

Conversation

@stephanieyzhang
Copy link
Copy Markdown

@stephanieyzhang stephanieyzhang commented Oct 2, 2025

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.

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


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

@stephanieyzhang stephanieyzhang changed the title Add FormControlRange hooks [DO NOT REVIEW] FormControlRange hooks Oct 2, 2025
@stephanieyzhang stephanieyzhang changed the title [DO NOT REVIEW] FormControlRange hooks Integrate FormControlRange hooks into text controls (input/textarea) Oct 9, 2025
@stephanieyzhang stephanieyzhang changed the title Integrate FormControlRange hooks into text controls (input/textarea) Integrate PlainTextRange hooks into text controls (input/textarea) Dec 4, 2025
@stephanieyzhang stephanieyzhang changed the title Integrate PlainTextRange hooks into text controls (input/textarea) Integrate OpaqueRange hooks into text controls (input/textarea) Jan 14, 2026
Copy link
Copy Markdown
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is "supports opaque ranges" defined?

Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
Comment thread source Outdated
@stephanieyzhang
Copy link
Copy Markdown
Author

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.

Comment thread source Outdated
Comment thread source Outdated
@annevk annevk linked an issue Feb 12, 2026 that may be closed by this pull request
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 26, 2026
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 26, 2026
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
beckysiegel pushed a commit to chromium/chromium that referenced this pull request Feb 26, 2026
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 26, 2026
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 26, 2026
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}
lando-worker Bot pushed a commit to mozilla-firefox/firefox that referenced this pull request Mar 4, 2026
…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
@stephanieyzhang stephanieyzhang marked this pull request as ready for review April 23, 2026 15:57
Comment thread source Outdated
Comment thread source Outdated
Comment thread source
Comment thread source Outdated
Comment thread source Outdated
Comment thread source
Comment thread source
@jnjaeschke
Copy link
Copy Markdown

jnjaeschke commented May 6, 2026

What is supposed to happen to OpaqueRanges when the text control element becomes display: none? Should the ranges survive a display:none roundtrip, or are they disconnected?
And does creating a range (createValueRange()) on a display:none element even make sense?

@annevk
Copy link
Copy Markdown
Member

annevk commented May 6, 2026

I think display: none shouldn't impact a range? No other range is impacted by styling, why would this one be?

@jnjaeschke
Copy link
Copy Markdown

(speaking with an implementers hat on) it has implications to implementations if the frame gets destroyed (and re-created), if destroying the frame implicitly destroys the internal text node that is referred to in the opaque range.
My interpretation would be that it's implicitly expected that the range survives, but I wonder if this should be written somewhere explicitly.

@annevk
Copy link
Copy Markdown
Member

annevk commented May 8, 2026

I see. I think we should make sure that the specification doesn't have such assumptions anywhere and then just add explicit test coverage.

@stephanieyzhang
Copy link
Copy Markdown
Author

Good call on display:none. Will add WPT coverage for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

OpaqueRange Interface

6 participants