Selection API: getComposedRanges

[dizhang168]

WebKittens

@annevk @rniwa @whsieh

Title of the spec

Selection API: getComposedRanges()

URL to the spec

https://w3c.github.io/selection-api/#dom-selection-getcomposedranges

URL to the spec's repository

https://github.com/w3c/selection-api

Issue Tracker URL

No response

Explainer URL

https://github.com/mfreed7/shadow-dom-selection

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#1055

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=251997

Radar URL

No response

Description

Current getComposedRanges API has single shadowRoots parameter which is a rest parameter. We propose changing it to a dictionary that contains an array of shadow roots to be consistent with other shadow DOM API:

• getHTML()
• caretPositionFromPoint()

We would also like to add selectionRoot. This argument "scopes" the selection, so that the returned selection endpoints are always descendants of element.

Proposed change:

sequence<StaticRange> getComposedRanges(optional GetComposedRangesOptions options = {});

dictionary GetComposedRangesOptions {
  sequence<ShadowRoot> shadowRoots = [];
  Node? selectionRoot = null;
};

Further, we need to re-evaluate API changes for the Range and StaticRange interface, to support nodes in different tree. Either we need to update existing definitions or we might need to add new interfaces. Help us resolve these discussions.

See:
Changes to Range, StaticRange: w3c/selection-api#169
Change getComposedRanges’ parameter to a dictionary: w3c/selection-api#176
Change getComposedRanges to have selectionRoot parameter: w3c/selection-api#180
Main: w3c/selection-api#161

[rniwa]

Making getComposedRanges use a dictionary seems like a reasonable change but there is a possibility we'd hit a web compatibility issue given we've already shipped this API.

[annevk]

Given rniwa's feedback at TPAC I suggest we mark this as "position: support" one week from now.