[Minutes] Editing WG - 2024-11-14

08:03 <whsieh> https://github.com/w3c/selection-api/issues/336
08:04 <whsieh> Di: circled back with Chromium folks, good with using the composed tree
08:04 <whsieh> Di: okay with keeping the current model
08:05 <whsieh> https://github.com/w3c/selection-api/issues/2
08:05 <whsieh> Di: discussed at TPAC, we should have a new composed range concept in the spec. unclear how to track selection endpoints in different trees
08:06 <Di> https://github.com/dizhang168/shadow-dom-selection/blob/main/Selection%20API%20-%20composed%20range.pdf
08:06 <whsieh> Di: 1. want to define what a composed range is (defn. in slide above)
08:07 <whsieh> Di: could make it inherit from live range but that runs into other issues
08:07 <whsieh> Di: 2. define association between live range and selection
08:08 <whsieh> Di: (see above slides for more details on updates to getRangeAt and setBaseAndExtent)
08:09 <whsieh> johanneswilm: does this mean you always have live range in composed range? or only 1
08:10 <whsieh> Di: live range implies existence of composed range (?)
08:11 <whsieh> mfreed: both are implementable, yes?
08:11 <whsieh> Di: yes

08:15 <whsieh> mfreed: preference?
08:15 <whsieh> Di: option 1 might be more straightforward to implement
08:15 <whsieh> johanneswilm: impact on JS devs?
08:15 <whsieh> Di: in practice, JS developers shouldn't need to care
08:15 <whsieh> Di: more browser-internal. but it should be in the spec, since it's useful for defining other algorithms
08:15 <whsieh> johanneswilm: sounds like this is just an implementation detail
08:16 <whsieh> mfreed: also my comment earlier — seems like this can be implemented by a browser engine either way. this is essentially a way to rigorously define what happens when we say "composed range from the selection", etc.
08:16 <whsieh> Di: advantage is that this would allow us to define editing operations
08:17 <whsieh> dandclark: can you remind me of the current state of the spec?
08:17 <whsieh> Di: selection can have a range, range is anything that implements abstract range
08:17 <whsieh> Di: browsers implement live range
08:17 <whsieh> dandclark: gut reaction — easier to think about the version where there's the 1 range. we compute composed ranges on the fly
08:18 <masonf> +1 my vote is option 1
08:18 <whsieh> dandclark: probably easier to have the spec that way (maps to option 1)
08:18 <whsieh> whsieh: same
08:19 <whsieh> resolution: lets' go with option 1
08:20 <whsieh> (would be good to confirm with Sanket et al.)
08:20 <whsieh> next issue: https://github.com/w3c/selection-api/issues/168
08:21 <whsieh> Di: how do DOM mutations affect compose ranges? see slide 6 above
08:22 <whsieh> Di: if we use current definition in the DOM spec, there would not be any change in the live range
08:22 <whsieh> Di: however, if we were to use composed ranges, it would need to change
08:22 <whsieh> Di: both blink and gecko don't care about shadow inclusiveness
08:23 <whsieh> dandclark: seems straightforward enough to patch the spec to be shadow inclusive
08:24 <whsieh> whsieh what about multi-range selections?
08:25 <whsieh> Di: generalizes to multiple ranges
08:25 <whsieh> resolve: define composed range mutations in the DOM spec
08:26 <whsieh> Di: check with other folks how are not in the meeting (sanket + smaug)
08:27 <whsieh> mfreed: next step — make a spec PR?
08:28 <whsieh> next issue: https://github.com/w3c/editing/issues/468
08:29 <whsieh> discrepancy between browser internal typing style and input events
08:30 <whsieh> johanneswilm: masayuki proposes keeping the empty span/inline element
08:30 <whsieh> johanneswilm: moving arrow keys (changing selection) removes b tag
08:31 <whsieh> queue+
08:31 <whsieh> johanneswilm: editing behaviors could be unintuitive because you get a bunch of empty inline style tags
08:31 <whsieh> queue- (was going to same this same thing)
08:32 <whsieh> johanneswilm: for JS editors it could work but it would require sanitization, etc.
08:34 <whsieh> whsieh: what about text/html in DT?
08:37 <whsieh> johanneswilm: (insertText only has data, not dataTransfer)
08:40 <whsieh> johanneswilm: several ways to solve this. fine with Masayuki's proposal.
08:40 <whsieh> whsieh: let's keep this on the agenda. curious what smaug thinks
08:41 <whsieh> next issue: https://github.com/w3c/input-events/issues/162
08:41 <whsieh> johanneswilm: should there be access to HTML when pasting in plain text? (put in DT?)
08:42 <whsieh> johanneswilm: we don't currently have a way to denote "plain text only" in input events
08:46 <whsieh> whsieh: need more time to think about this
08:46 <whsieh> next: https://github.com/w3c/input-events/issues/161
08:46 <whsieh> johanneswilm: e.g. smart space insertion on Mac
08:48 <whsieh> johanneswilm: should we add something specific to EC to distinguish this
08:54 <whsieh> johanneswilm: is there any way to fix for contentEditable?
08:57 <whsieh> whsieh: seems like it's possible to make it work in cE, but JS editors need to be very careful with context text in the content editable container
08:57 <whsieh> Comandeer: planning to use EC for IME, but maybe not for general editing
08:57 <whsieh> (yet)
08:58 <whsieh> johanneswilm: wonder if this ends up being wish list item, especially if WebKit implements edit context

(Update corresponding Github issues, if needed)