#694: Modification of selection APIs to account for shadow dom

Visit on Github.

Opened Dec 3, 2021

Braw mornin' TAG!

I'm requesting a TAG review of modifying the selection APIs to account for shadow dom.

Shadow DOM (v1) is now supported by all evergreen rendering engines. However, the user selection APIs are not well supported for the case that the user selection crosses shadow boundaries. The existing Selection API specifies that there is only a single selection in a document and the selection is bound to a single Range, which means that it cannot represent a range over the composed tree. Said another way, if the selection crosses shadow boundaries, the existing API cannot represent this situation correctly. For backwards compatibility, we also can't update the Range API to support ranges that cross shadow boundaries, because that could break existing assumptions about ranges.

This proposal suggests a new API that lets web authors control and query selections in the composed tree.

  • Explainer¹: https://github.com/mfreed7/shadow-dom-selection#readme
  • User research: Discussion on the issue thread, starting roughly here. Plus I directly solicited feedback from three editor builders: [1] [2] [3]
  • Security and Privacy self-review²: None
  • Primary contacts (and their relationship to the specification):
    • Mason Freed (@mfreed7), Google
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://crbug.com/762799

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
  • Existing major pieces of multi-stakeholder review or discussion of this design: discussion
  • Major unresolved issues with or opposition to this design: None that I know of
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mfreed7

Discussions

2022-02-07

Minutes

Left questions about shape of API, overall looks reasonable so far.

2022-06-06

Minutes

Dan: does Mason's comment from 29th answer your question?

Lea: i think it makes sense.

Dan: can we close this issue?

Lea: I'd be fine closing.

Rossen: reading his last reply - he acknowledges the proposal started with closed shadow roots. .. after some discussions added .. "we added the selection root argument" ... so.. if I'm within a component, and I call the selection.getcomposedrange and pass my root as the selection root argument by default - that guarantees I don't get out of my component.

Lea: I think so.

Rossen: so.. what's the expected behavior if I have a sibling container as the shadow root? Something iffy here... I think we need to revisit it further.. This is one of those APIs I don't want to mess it up..

we take 5 minutes to review

Rossen: I think this will work well... Not caught up on all the issues but the proposed API for the use cases they stated - is a good approach. The consideration of the getRangeAt and changes to getRangeAt ... 'The primary selection API use cases SHOULD not be adversely effected"... it's a loose statement. This is the part where I don't have a strong opinion.... If they're willing to go and try it out it would be great to see how it works in reality. Otherwise from the API shape... it's what I would expect. A lot of use cases they show is where selection crosses into an open component.. you start selection in the div and the selection ends in the middle of that component... The end is the other shadow root... it's going to work... not sure what that means when you cross many roots..

Lea: have the roots been passed in?

Rossen: no this is when you call getComposedRange..

Lea: it cannot return offsets ... that's my understanding...

Lea: points to here

Rossen: to me that means you're going to start selecting and the selection will run forward...

Lea: the use cases they study don't want to span shadow roots...

Rossen: puts the work to the author... but as long as that's the case that's OK.

Lea: also this new getComposedRange becomes a replacement for getRangeAt... if you don't pass any shadow roots then it does the same job... so i wonder if it would make sense to give it a more generic name? Should it have a more generic name like getRange.

Dan: impact of the authoring of content in the future...

Rossen: to me it feels more constructy...

Dan: Maybe makes sense to leave this feedback in the context of a closing comment.

Rossen: I'm happy to close it.

Lea: writes closing comment

closed