Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add definition for composed selection range #1342

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

dizhang168
Copy link

@dizhang168 dizhang168 commented Dec 17, 2024

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

01/28/2025 Edit: Changed naming to Composed Selection Range.

(See WHATWG Working Mode: Changes for more details.)


Preview | Diff

@domfarolino domfarolino self-requested a review December 19, 2024 18:40
@domfarolino domfarolino added the agenda+ To be discussed at a triage meeting label Jan 16, 2025
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@dizhang168
Copy link
Author

I have opened the draft PR for Selection API to use the definition described here, to help visualize:
w3c/selection-api#345

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}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Jan 28, 2025
…dateSelectionIfAddedToSelection, a=testonly

Automatic update from web-platform-tests
Add UpdateSelectionBehavior to Range::UpdateSelectionIfAddedToSelection

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}

--

wpt-commits: e679be39aa83e65a06627a8a5b911648f5312f13
wpt-pr: 50283
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this pull request Jan 28, 2025
…dateSelectionIfAddedToSelection, a=testonly

Automatic update from web-platform-tests
Add UpdateSelectionBehavior to Range::UpdateSelectionIfAddedToSelection

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}

--

wpt-commits: e679be39aa83e65a06627a8a5b911648f5312f13
wpt-pr: 50283
@dizhang168 dizhang168 changed the title Add definition for composed live range Add definition for composed selection range Jan 28, 2025
@past past removed the agenda+ To be discussed at a triage meeting label Jan 30, 2025
dom.bs Outdated

<p>A <dfn export id=concept-composed-selection-range>composed selection range</dfn> is a
<a>live range</a> that has an associated {{Range}} object, a
<dfn export id=concept-legacy-selection-range for="composed selection range">legacy selection range</dfn>.</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, I don't like calling the normal Range as legacy. Nothing really legacy there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not the Range object that's legacy, it's having to keep around a pretend range for the purposes of the selection API as it was designed pre-shadow-trees that's kinda legacy.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but I don't still like it. It is not legacy, in the sense that there would be some better thing to replace it or so (in case of light dom). "Legacy" doesn't explain what the range is for.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would you propose?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe the legacy selection range could be same-tree selection range, and composed selection range could be composed-tree selection range?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same-tree selection range sounds kinda nice. I personally think "composed selection range" is fine as-is.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listing the naming options:

  1. "composed live range" and "cached live range"
  2. "composed selection range" and "legacy selection range"
  3. "composed-tree selection range" and "same-tree selection range"
  4. "composed selection range" and "same-tree selection range"
  5. "composed selection range" and "selection range"

All these names seem ok to me, I will let the majority decide.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on an email conversation I'm a bit less sure what the semantics of this range are. Say you have an element with a shadow root that contains the word "Test". The end user selects "es". getSelection() should not provide access to this shadow root, but apparently the set of changes proposed here do not enforce that. Or am I misunderstanding something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

6 participants