Add definition for composed live range #1342
Open
+70
−27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
annevk
reviewed
Jan 17, 2025
There was a problem hiding this comment.
@smaug---- you should review this as well in due course. And @rniwa too I suspect.
dom.bs
Outdated
Comment on lines
3032
to
3045
| <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>). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Shouldn't this update the cached live range as well?
There was a problem hiding this comment.
The cached live range is covered by the existing "For each live range ..." rules. The cached live range is not composed and hence shouldn't consider for shadow-including inclusive descendant.
There was a problem hiding this comment.
Good call on the cached live range. But don't the existing rules also update the "composed live range" (because a composed live range is a live range)?
There was a problem hiding this comment.
Yes, the rule will be applied twice. I think that's the expected behavior. This will help to keep mutation results consistent, especially when we are not crossing shadow boundaries.
dom.bs
Outdated
| <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> |
There was a problem hiding this comment.
Why is this called cached live range?
There was a problem hiding this comment.
I wanted to give it a name so it doesn't get confusion between the "composed" live range and its associated "live range". Further, it is cached within the composed live range. I am open to naming suggestions.
dizhang168
force-pushed
the
composed-live-range
branch
from
54e6984 to
487cac0
Compare
8 tasks
|
I have opened the draft PR for Selection API to use the definition described here, to help visualize: |
aarongable
pushed a commit
to chromium/chromium
that referenced
this pull request
Jan 24, 2025
When a live range attached to a document is modified, this change is upstreamed to the FrameSelection. New spec [1] says to only update the composed live range (frame selection)'s start position if setStart is called and only update end position if setEnd is called: whatwg/dom#1342 This is the proposal (B) discussed here: whatwg/dom#772 (comment) To do this, we define enum UpdateSelectionIfAddedToSelection to have three possible update selection behavior: 1. kAll, set selection to have the same start and end as range. --> Default case, when both setStart, setEnd are called. 2. kStartOnly, set selection to have the same start as range only. --> When only setStart is called. 3. kEndOnly, set selection to have the same end as range only. --> When only setEnd is called. We add a WPT test for this new behavior, which only affects the output of getComposedRanges() as it is the only API that accesses the frame selection's endpoints directly. Change-Id: I51ea53fe6156164ba3fbe38b14bc47ff502633b1 Bug: 40286116 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6188157 Reviewed-by: Siye Liu <[email protected]> Commit-Queue: Di Zhang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1411209}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jan 25, 2025
When a live range attached to a document is modified, this change is upstreamed to the FrameSelection. New spec [1] says to only update the composed live range (frame selection)'s start position if setStart is called and only update end position if setEnd is called: whatwg/dom#1342 This is the proposal (B) discussed here: whatwg/dom#772 (comment) To do this, we define enum UpdateSelectionIfAddedToSelection to have three possible update selection behavior: 1. kAll, set selection to have the same start and end as range. --> Default case, when both setStart, setEnd are called. 2. kStartOnly, set selection to have the same start as range only. --> When only setStart is called. 3. kEndOnly, set selection to have the same end as range only. --> When only setEnd is called. We add a WPT test for this new behavior, which only affects the output of getComposedRanges() as it is the only API that accesses the frame selection's endpoints directly. Change-Id: I51ea53fe6156164ba3fbe38b14bc47ff502633b1 Bug: 40286116 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6188157 Reviewed-by: Siye Liu <[email protected]> Commit-Queue: Di Zhang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1411209}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Jan 25, 2025
When a live range attached to a document is modified, this change is upstreamed to the FrameSelection. New spec [1] says to only update the composed live range (frame selection)'s start position if setStart is called and only update end position if setEnd is called: whatwg/dom#1342 This is the proposal (B) discussed here: whatwg/dom#772 (comment) To do this, we define enum UpdateSelectionIfAddedToSelection to have three possible update selection behavior: 1. kAll, set selection to have the same start and end as range. --> Default case, when both setStart, setEnd are called. 2. kStartOnly, set selection to have the same start as range only. --> When only setStart is called. 3. kEndOnly, set selection to have the same end as range only. --> When only setEnd is called. We add a WPT test for this new behavior, which only affects the output of getComposedRanges() as it is the only API that accesses the frame selection's endpoints directly. Change-Id: I51ea53fe6156164ba3fbe38b14bc47ff502633b1 Bug: 40286116 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6188157 Reviewed-by: Siye Liu <[email protected]> Commit-Queue: Di Zhang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1411209}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed at TPAC 2024, the specification for the new getComposedRanges() API need the introduction of the new definition "Composed live range" [1], which should react to mutations. This PR attempts to define that new concept. Once landed, we will add the spec language that uses composed live range in the Selection API. An overview of the spec changes necessary can be found at [2].
[1] w3c/selection-api#2 (comment)
[2] https://github.com/dizhang168/shadow-dom-selection/blob/main/selection-api-spec-changes.md
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff