Integrate OpaqueRange hooks into text controls (input/textarea)#11741
Integrate OpaqueRange hooks into text controls (input/textarea)#11741stephanieyzhang wants to merge 21 commits into
Conversation
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
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}
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}
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
|
What is supposed to happen to |
|
I think |
|
(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. |
|
I see. I think we should make sure that the specification doesn't have such assumptions anywhere and then just add explicit test coverage. |
|
Good call on |
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 PRs:
At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
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 )