Re: [whatwg/dom] Introduce `moveBefore()` state-preserving atomic move API (PR #1307)

@smaug---- commented on this pull request.



> + <li><p>Let <var>oldParent</var> be <var>node</var>'s <a for=tree>parent</a>.
+
+ <li><p><a>Assert</a>: <var>oldParent</var> is non-null.
+
+ <li><p>Let <var>index</var> be <var>node</var>'s <a for=tree>index</a>.
+
+ <li>
+  <p>For each <a>live range</a> whose <a for=range>start node</a> is <var>parent</var> and
+  <a for=range>start offset</a> is greater than <var>index</var>, decrease its
+  <a for=range>start offset</a> by 1.</p>
+
+  <p class="note">Note that unlike the traditional <a for=/ lt="remove">removal</a> case, we do not
+  need to update <a>live range</a> state when their <a for=range>start node</a> or
+  <a for=range>end node</a> is an <a>inclusive descendant</a> of the <var>node</var>. This is
+  because said <a>nodes</a> do not get removed from their <a>tree</a>, so ranges associated with
+  them stay intact.</p>

Container approach (not modifying the range if full contained) would be still problematic if the container was moved from light dom to shadow dom, and the range was a range which one can access from selection.getRangeAt().  Selection should not reveal nodes in shadow dom.
Also it might be a bit surprising if selection is preserved in some cases but not in others.

Maybe, unrelated to moveBefore, there should be some helper methods to create a StaticRange from Range, and then update selection later, if/when needed, using that StaticRange. Hmm, though StaticRange isn't quite enough, since one needs also direction.

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

Message ID: <whatwg/dom/pull/1307/review/2430638075@github.com>