Re: [whatwg/dom] Add OpaqueRange interface (PR #1404)

@annevk commented on this pull request.



> @@ -8694,6 +8694,11 @@ interface AbstractRange {
 <dfn export id=concept-range-end-offset for=range>end offset</dfn> is its <a for=range>end</a>'s
 <a for="boundary point">offset</a>.
 
+<p>A <a>range</a> has an associated <dfn export for=range id=concept-range-is-opaque>is opaque</dfn>

associated boolean*

We don't want flags anymore.

> +flag, initially false. When true, the {{AbstractRange/startContainer}} and
+{{AbstractRange/endContainer}} getters return null. Only {{OpaqueRange}} objects have this flag set
+to true.

This second bit should probably be in a note.

> @@ -8669,9 +8669,9 @@ be between 0 and the <a>boundary point</a>'s <a for="boundary point">node</a>'s
 <pre class=idl>
 [Exposed=Window]
 interface AbstractRange {
-  readonly attribute Node startContainer;
+  readonly attribute Node? startContainer;
   readonly attribute unsigned long startOffset;

Does it make sense to expose startOffset and endOffset if this range potentially spans multiple nodes? They will not have meaningful values I think for opaque ranges.

> @@ -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

I thought we would have a constructor so people can create these for custom elements?

> +<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
+elements that <a>support opaque ranges</a>.
+
+<p>An {{OpaqueRange}} has an
+<dfn export for=OpaqueRange>associated element</dfn> (an {{Element}} or null), initially null. It is
+set by the specification that creates the {{OpaqueRange}}.

Why do we need this and `disconnect()`? Can't that be with the APIs that vend `OpaqueRange` objects? It's also a bit unclear what disconnecting means beyond that, maybe in part because this doesn't actually integrate with the tree mutation algorithms yet.

> +  </ol>
+
+ <li><p>Set <a>this</a>'s <a for=range>start offset</a> to 0.
+
+ <li><p>Set <a>this</a>'s <a for=range>end offset</a> to 0.
+</ol>
+</div>
+
+<p>The {{OpaqueRange/getClientRects()}} and {{OpaqueRange/getBoundingClientRect()}} methods are
+defined in [[CSSOM-VIEW]].
+
+<p>An {{OpaqueRange}} is a <a>range</a> whose <a for=range>is opaque</a> flag is true.
+
+<p>An {{Element}}
+<dfn export id=supports-opaque-range>supports opaque ranges</dfn> if its specification defines that
+it does. In HTML, this includes certain {{HTMLInputElement}} types and {{HTMLTextAreaElement}}.

I'm not sure why we need this concept.

> + <li><p>Set <a>this</a>'s <a for=range>end offset</a> to 0.
+</ol>
+</div>
+
+<p>The {{OpaqueRange/getClientRects()}} and {{OpaqueRange/getBoundingClientRect()}} methods are
+defined in [[CSSOM-VIEW]].
+
+<p>An {{OpaqueRange}} is a <a>range</a> whose <a for=range>is opaque</a> flag is true.
+
+<p>An {{Element}}
+<dfn export id=supports-opaque-range>supports opaque ranges</dfn> if its specification defines that
+it does. In HTML, this includes certain {{HTMLInputElement}} types and {{HTMLTextAreaElement}}.
+
+<p class=note>Other specifications can designate additional elements, including custom elements.
+
+<p>An {{OpaqueRange}} is live, meaning its offsets are automatically updated when the underlying

I think we should define this very differently. We should define opaque ranges the same way we define live ranges. And then in HTML we should say that these elements have some kind of underlying `Text` node that this opaque range "exposes".

The reason for that is because we want opaque ranges to be a generic container. And the way you have specified them they are still very much restricted to specific elements.

> @@ -9981,6 +9988,61 @@ 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 {
+  DOMRectList getClientRects();
+  DOMRect getBoundingClientRect();
+};

I think we actually don't want to expose the offsets as per my other comment. I'm not sure if we want to expose collapsed. Perhaps it should just be separate from `AbstractRange`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1404#pullrequestreview-4251280258
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1404/review/4251280258@github.com>