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