Re: [whatwg/dom] Add definition for composed selection range (PR #1342)

@domfarolino commented on this pull request.



> @@ -8265,6 +8282,12 @@ steps:
  <a>boundary point</a>
  (<var>node</var>, <var>offset</var>).
 
+ <li>If <var>range</var> is the <a for="composed selection range">legacy selection range</a> of a

Could you add a clarification to the algorithm declaration of "start the set|start the end" to give the "range" parameter a type? I think the intention is that this algorithm should only ever be called on "live range" objects, and never a "composed selection range", so let's give it a "live range" type if you believe that's accurate.

>       to <var>bp</var>.
 
+     <li>Otherwise, if <var>bp</var> is
+     <a for="boundary point">after</a> the
+     <var>range</var>'s <a for=range>end</a>, then:
+      <ol>
+       <li>Set <var>range</var>'s <a for=range>end</a>
+       to <var>bp</var>.
+
+       <li>If <var>selection range</var> is not null,
+       set <var>selection range</var>’s
+       <a for="range">end</a> to <var>bp</var>.

At first I thought we wouldn't want to unconditionally collapse the associated `composed selection range` if, while we're "setting the start", we discover that the proposed start _bp_ is actually after the end. I thought we wouldn't want to do this because we need to be able to support case like `setBaseAndExtent()` where the selection would end up with the ["backwards" direction](https://developer.mozilla.org/en-US/docs/Web/API/Selection/direction). But then I realized in that case, the Selection API spec just calls this DOM algorithm with the start/end nodes inverted so that it doesn't collapse like this—so basically it's the Selection API's responsibility for handling that.

So yeah I think I agree there's a problem here. Specifically, if we end up calling `getSelectionRange.getRangeAt(0).setStart(nodeAfterCurrentEnd, 0)`, then we will correctly collapse the `composed selection range`'s "legacy live range", but not the `composed selection range` itself.

Maybe we should be collapsing the composed selection range in this case, unless the current spec prose is intentional to support some use case I'm not thinking of. WDYT @dizhang168?

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

Message ID: <whatwg/dom/pull/1342/review/2642374107@github.com>