- From: Dominic Farolino <notifications@github.com>
- Date: Tue, 28 Jan 2025 08:48:00 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/1342/review/2578866338@github.com>
@domfarolino commented on this pull request. > + <li><p>For each <a>composed live range</a> whose <a for=range>start node</a> is a + <a>shadow-including inclusive descendant</a> of <var>node</var>, set its <a for=range>start</a> to + (<var>parent</var>, <var>index</var>). + + <li><p>For each <a>composed live range</a> whose <a for=range>end node</a> is an + <a>shadow-including inclusive descendant</a> of <var>node</var>, set its <a for=range>end</a> to + (<var>parent</var>, <var>index</var>). Note that the "set the start or end" algorithm is not invoked from #concept-node-remove at all, so it is unrelated. So with that out of the way, it seems that for all composed ranges that are ordinary inclusive descendants of the to-be-removed node, these composed ranges would get updated "twice" (idempotently): first by steps 4/5, second by steps 6/7. In the case where the composed range _is_ a shadow-inclusive descendant of the removed node but not an ordinary inclusive descendant, than only steps 6/7 will apply, and there's no redundancy. So it's inefficient as @annevk points out, but not broken. Should we fix this? Does it matter? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/pull/1342#discussion_r1932523229 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/pull/1342/review/2578866338@github.com>
Received on Tuesday, 28 January 2025 16:48:04 UTC