Track: Selection API for Shadow DOM

[johanneswilm]

There is an effort underway to modify the way selections work to accommodate Shadow DOMs [1].

This will have a direct impact on JavaScript editors, whether they make use of the shadow DOM or not. See for example the part of the proposal to replace getRangeAt():

I believe getComposedRange() should be usable for all use cases, including any covered by getRangeAt(). Perhaps we should rename and deprecate as they recommend?

[1] WICG/webcomponents#79 (comment)

[travisleithead]

@mfreed7 may be available at our August 2022 meeting to give us an overview of the proposal and solution space.

[css-meeting-bot]

The Web Editing Working Group just discussed selection API.

The full IRC log of that discussion

<Travis> topic: selection API
<Travis> github: https://github.com//issues/403
<Travis> johanneswilm: We've invited folks who are working on this to come and present to us in a month!
<Travis> .. if folks would like to follow along, please checkout the links in the issue.

[smaug----]

I'd be interested in to participate too, but I don't know when the meeting will occur.

[mfreed7]

Just to confirm - I do plan to attend this Thursday's meeting, and I've put together a very small handful of slides to review the Shadow Selection API Proposal. I will share the slides a bit closer to the date, but is this issue the appropriate place to share them? Or is there an agenda issue or something somewhere?

I believe getComposedRange() should be usable for all use cases, including any covered by getRangeAt(). Perhaps we should rename and deprecate as they recommend?

[1] WICG/webcomponents#79 (comment)

Side note on this point - @smaug---- rightly pointed out that because the new proposal returns a StaticRange, it can't do some of the convenient mutation things that a live Range can do. So I think we should keep with the existing proposal, which leaves getRangeAt() functionally the same.

[mfreed7]

(Short!) presentation for today:

https://docs.google.com/presentation/d/1GuO7zQlyZ3HN-tR8-qMOorukGAgLBf0MdQmaiWdfFEU/edit#slide=id.g14500d5ed18_1_28

[travisleithead]

Thanks @mfreed7 for today's presentation and to the WG for the good discussion (see minutes).

If folks want to take more time to ponder the proposal and have additional feedback, please comment on the primary issue over at: WICG/webcomponents#79

[css-meeting-bot]

The Web Editing Working Group just discussed Selection API for Shadow DOM.

The full IRC log of that discussion

<Travis> Topic: Selection API for Shadow DOM
<Travis> github: https://github.com//issues/403
<Travis> masonf: Hi folks! I'm masonf, TL at Google.
<masonf> https://docs.google.com/presentation/d/1GuO7zQlyZ3HN-tR8-qMOorukGAgLBf0MdQmaiWdfFEU/edit#slide=id.p
<Travis> .. (presenting slides)
<Travis> .. Selection API has no idea about ShadowDOM. Things don't work so well when selection crosses the boundary.
<Travis> .. window.getSelection does different things depending on browsers, and things are somewhat inconsistent.
<Travis> .. we need to add some info to selection API so it knows what to do in these cases.
<Travis> .. note: getRangeAt returns a Range which has to be in one tree.
<Travis> .. BTW, had a big discussion on this last year. TAG reviewed and was OK with it.
<Travis> .. Proposal: new API getComposedRange.
<Travis> .. returns a StaticRange.
<Travis> .. takes options: list of shadow roots
<Travis> .. (so that it knows that the author knows about them)
<Travis> .. another option: selection root. (Enables easy to scope scenarios)
<Travis> .. Proposal pt. 2. Other stuff in the Selection API that needs to be rationalized with the new changes.
<Travis> .. define a "true range". Platform will know the real end-points, and can adapt what it returns to conform.
<Travis> .. other APIs (setBaseAndExtent) can be adjusted to accept Nodes from different trees.
<Travis> .. (we hope that will be web-compatible)
<Travis> .. Presentation includes a few follow-up links at the end.
<Travis> Travis: what is desired from this group?
<Travis> masonf: Editing WG has lots of good knowledge here. Would love your feedback.
<Travis> .. chromium is interested in implementing.
<Travis> .. also, if we have volunteers to write PRs, that would be awesome.
<Travis> whsieh: The selection root, is it a convenience?
<Travis> masonf: Yes, essentially.
<Travis> .. must pass in (at least) your own ShadowRoot. But also, you may want to "chop off" parts of the range out of your component. So it can handle both cases.
<Travis> whsieh: Selection is scoped to editable regions (when it starts in an editing range)...
<Travis> masonf: I believe "it depends".
<Travis> whsieh: Silly little demo: http://whsieh.github.io/examples/contenteditable
<Travis> .. can't seem to make the selection cross boundaries.
<Travis> Megan: can select outside-in, but not vice-versa.
<Travis> smaug: In Firefox, highlight can be partial.
<Travis> snianu: Isn't that a problem with execCommands?
<Travis> .. e.g., delete? I guess there must be smarts to find the deletable content.
<Travis> smaug: How does that work in other browsers?
<Travis> snianu: Just the whole editing sub-component is selected (no partial selection inside) so we side-step the problem.
<Travis> .. behavior was different in old Edge/IE
<Travis> .. (Travis didn't catch the full details)
<Travis> .. the algorithm for adjusting the DOM is complicated.
<Travis> whsieh: if selection contains any non-editable ranges, then the entire thing is non-editable (presumed Firefox behavior).
<Travis> masonf: So is the implication that the selection root isn't necessary because it doesn't happen in practice?
<Travis> whsieh: The case for scoping to editable roots is a less interesting case (because all browsers already do that). There are other use cases, perhaps, where it would be useful.
<Travis> .. e.g., scoping to certain regions in an editor?
<Travis> Megan: Why StaticRange?
<Travis> masonf: from my POV, it was "Live Ranges" are icky.
<Travis> smaug: I don't think Live Ranges can have selections between different trees. This may be why.
<Travis> masonf: Was looking for that, but didn't find that restriction..?
<Travis> smaug: Well, Static Ranges may also be limited -- that part of the spec may have to change.
<Travis> whsieh: Another motivator is Performance.
<Travis> smaug: Depending on implementation, Perf may not be that significant (internal mechanism may not be able to avoid tracking logic used in live ranges)
<Travis> whsieh: As the number of live regions scale up, you could be in perf trouble.
<Travis> megan: anything we'll loose by not having live ranges?
<Travis> masonf: TAG said let's deprecate the old getRangeAt... but there were some unique use cases that would be lost.
<Travis> .. we're not losing anything by having both.
<Travis> masonf: Please file comments/feedback in the related issue (linked from the end of the slide).
<Travis> zakim, please end the meeting
<Zakim> As of this point the attendees have been masonf, Travis, comandeer, dandclark, snianu, smaug
<Zakim> RRSAgent, please draft minutes v2
<RRSAgent> I have made the request to generate https://www.w3.org/2022/08/11-editing-minutes.html Zakim
<Zakim> I am happy to have been of service, Travis; please remember to excuse RRSAgent. Goodbye
<Travis> rrsagent, make logs public
<RRSAgent> I have made the request, Travis
<Travis> regrets: johanneswilm
<Travis> present: whsieh
<Travis> present: Megan
<Travis> rrsagent, draft the minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/08/11-editing-minutes.html Travis
<Travis> present: Megan, whsieh, alexk, comandeer, dandclark, smaug, snianu, Travis, masonf
<Travis> chair: Travis
<Travis> rrsagent, draft the minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/08/11-editing-minutes.html Travis