- From: Anne van Kesteren <notifications@github.com>
- Date: Wed, 20 May 2026 01:13:19 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/1404/review/4326463230@github.com>
@annevk 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
1. Yes, that makes sense to me.
2. Yes.
3. We should not need anything on `ElementInternals`. Web developers can use the constructor and expose APIs such as `createValueRange()` on their elements as they see fit. Including the more complicated ranges that expose more than just a (conceptual) `Text` node.
4. They can't use the constructor because they don't have access to the conceptual `Text` node. Only `input` and `textarea` have access to that information and can thus create the range. As such web developers will have to go through `createValueRange()`.
--
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1404#discussion_r3272268069
You are receiving this because you are subscribed to this thread.
Message ID: <whatwg/dom/pull/1404/review/4326463230@github.com>
Received on Wednesday, 20 May 2026 08:13:23 UTC