WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
241 stars 19 forks source link

Selection API: getComposedRanges #376

Open dizhang168 opened 2 months ago

dizhang168 commented 2 months ago

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

https://github.com/mozilla/standards-positions/issues/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:

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: https://github.com/w3c/selection-api/issues/169 Change getComposedRanges’ parameter to a dictionary: https://github.com/w3c/selection-api/issues/176 Change getComposedRanges to have selectionRoot parameter: https://github.com/w3c/selection-api/issues/180 Main: https://github.com/w3c/selection-api/issues/161

rniwa commented 5 days ago

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.