Closed dizhang168 closed 2 weeks 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.
Given rniwa's feedback at TPAC I suggest we mark this as "position: support" one week from now.
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:
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