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

@annevk commented on this pull request.

@smaug---- you should review this as well in due course. And @rniwa too I suspect.

> + <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>).

This will need to be rebased once we land `moveBefore()`.

However, I also think this needs to be reconciled with the "for each live range" above as we don't want to do duplicate work.

> +{{Range}} <a>live range</a> with (<a>this</a>, 0) as its <a for=range>start</a> and <a
+for=range>end</a>.

I would say "Range object" here. We also don't wrap in phrasing elements.

> @@ -7878,11 +7889,11 @@ range.setEnd(secondText, 4)
 <a>node tree</a> above cannot be represented by a <a>range</a>. <a>Ranges</a> are only useful for
 <a for=/>nodes</a>.
 
-<p>{{Range}} objects, unlike {{StaticRange}} objects, are affected by mutations to the
-<a>node tree</a>. Therefore they are also known as <a>live ranges</a>. Such mutations will not
-invalidate them and will try to ensure that it still represents the same piece of content.
-Necessarily, a <a>live range</a> might itself be modified as part of the mutation to the
-<a>node tree</a> when, e.g., part of the content it represents is mutated.
+<p>{{Range}} objects, unlike {{StaticRange}} objects, are affected by mutations to the <a>node

No wrapping in phrasing elements. (Please check the rest of the diff yourself for this.)

>  
 <p class=note>Algorithms that modify a <a>tree</a> (in particular the <a for=/>insert</a>,
 <a for=/>remove</a>, <a>replace data</a>, and <a lt="split a Text node">split</a> algorithms) modify
-<a>live ranges</a> associated with that <a>tree</a>.
+<a>live ranges</a> associated with that <a>tree</a>.</p>
+
+<p>A <dfn export id=concept-composed-live-range>composed live range</dfn> is a <a>live range</a>
+that has one associated {{Range}} object - <dfn export

This needs to use "—".

> @@ -8544,8 +8573,8 @@ method steps are:
  (<var>new node</var>, <var>new offset</var>).
 </ol>
 
-<p>To <dfn export id=concept-range-extract for="live range">extract</dfn> a <a>live range</a>
-<var>range</var>, run these steps:
+<p>To <dfn export id=concept-range-extract for="live range">extract</dfn> a {{Range}} <a>live
+range</a> <var>range</var>, run these steps:

I would use Range object again here.

>  
 <p class=note>Algorithms that modify a <a>tree</a> (in particular the <a for=/>insert</a>,
 <a for=/>remove</a>, <a>replace data</a>, and <a lt="split a Text node">split</a> algorithms) modify
-<a>live ranges</a> associated with that <a>tree</a>.
+<a>live ranges</a> associated with that <a>tree</a>.</p>
+
+<p>A <dfn export id=concept-composed-live-range>composed live range</dfn> is a <a>live range</a>
+that has one associated {{Range}} object - <dfn export
+id=concept-composed-live-range-cached-live-range for="composed live range">cached live
+range</dfn>.</p>

Why is this called cached live range?

> + <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>).

Shouldn't this update the cached live range as well?

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

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

Received on Friday, 17 January 2025 09:16:50 UTC