Modification of selection APIs to account for shadow dom

[mfreed7]

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

[plinss]

Took a look at this today with @LeaVerou and @maxpassion, we were wondering what the purpose was of adding getComposedRange vs overloading getRangeAt to accept the ComposedRangeOptions. As far as we could tell the only apparent difference is the result of a live Range vs a StaticRange, which seems like an orthogonal issue.

[mfreed7]

Thanks for the review and the question. (And sorry for the delay replying!)

So I think the main reason for the new function, vs. re-using the old getRangeAt(), is backwards compatibility. This is mentioned a few places in the explainer, but the thought is that we would likely break sites if we just change getRangeAt() to return a StaticRange (rather than a live Range) that also crosses shadow bounds. Perhaps you were implying that if the developer passed a ComposedRangeOptions to getRangeAt(), you'd get the new behavior? The problem there is that the ComposedRangeOptions is optional, so a call like getRangeAt() (with no arguments) would now get the new behavior. That's likely ok compat-wise, since the existing behavior is to throw an exception with no arguments. However, in all current rendering engines, getSelection().getRangeAt({}) currently returns the live Range. So there's the possibility of compat problems if existing sites are using getRangeAt({}) for whatever reason.

Overall, I think the motivation for a new API was that we're rather-significantly changing the selection API, and beyond the calling syntax, developers will have to understand more about shadow DOM and how this new API works. Giving it a fresh/different function name helps (in my opinion) them understand that there's a difference.

I'm open to suggestions, of course.