- From: Stephanie Zhang <notifications@github.com>
- Date: Tue, 19 May 2026 17:51:03 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/1404/review/4324428589@github.com>
@stephanieyzhang commented on this pull request.
> @@ -9981,6 +9988,96 @@ and {{Range/getBoundingClientRect()}} methods are defined in other specification
[[CSSOM-VIEW]]
+<h3 id=interface-opaquerange>Interface {{OpaqueRange}}</h3>
+
+<pre class=idl>
+[Exposed=Window]
+interface OpaqueRange : AbstractRange {
+ undefined disconnect();
+ DOMRectList getClientRects();
+ DOMRect getBoundingClientRect();
+};
+</pre>
+
+<p>Objects implementing the {{OpaqueRange}} interface are known as {{OpaqueRange}} objects.
+{{OpaqueRange}} objects cannot be constructed directly; they are created by specifications defining
To make sure I'm understanding things correctly and that we're aligned:
1. Are we keeping `createValueRange()` on `<input>` and `<textarea>` as the vending API for form controls?
2. And then adding `new OpaqueRange({startContainer: node, ...})` as a separate constructor for custom elements?
3. Where does `ElementInternals.createOpaqueRange(...)` fit, if at all? Or do authors just use the constructor directly for custom-elements?
4. For `<input>`/`<textarea>` specifically, which API would devs be expected to use: `createValueRange()` or the constructor?
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1404#discussion_r3270600154
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/dom/pull/1404/review/4324428589@github.com>
Received on Wednesday, 20 May 2026 00:51:07 UTC