[Minutes] Editing WG - 2024-10-10

08:05 <whsieh> https://github.com/w3c/editing/issues/468
08:05 <whsieh> discussed at TPAC — need to check with Chrome/WebKit
08:06 <johanneswilm> present+
08:07 <whsieh> (WebKit needs more time to discuss)
08:07 *** Di (~Di@9d40a032.publics.cloak) has joined the channel 
08:07 <whsieh> https://github.com/w3c/selection-api/issues/336
08:08 <whsieh> continuation from TPAC discussion (https://docs.google.com/document/d/1i3etKUH47bd5xhjN12XFHaMB0GyxirASuIX8F0QSg0k/edit?tab=t.0#heading=h.f535nruhursx)
08:09 <whsieh> Sean: what's the real issue of using flat vs. composed? (what's the motivation)
08:10 <whsieh> Sean: Ryosuke noted that this is going to affect the rendering of the selection. potential compat issues
08:10 <whsieh> sanketj: second part of the proposal was to change the selection API to also reflect flat tree
08:10 <whsieh> sanketj: (selection and range methods)
08:10 <whsieh> Di: that's accurate
08:11 <whsieh> Di: right now, API exposes endpoints that are not accessible to the user, could cause developer confusion
08:11 <whsieh> sanketj: compat risk is nontrivial
08:12 <whsieh> sanketj: (we probably shouldn't change existing behavior). if the actual selection is based on DOM but gCR is based on flat ranges, is that useful?
08:12 <whsieh> Di: yes, still useful. will help us handle slot cases
08:13 <whsieh> Di: (more concrete examples in issue)
08:13 <Di> https://github.com/dizhang168/shadow-dom-selection/blob/main/flat-tree-setBaseAndExtent.md
08:13 <whsieh> Sean: Di has a proposal (linked above) that allows you to set selection endpoints from flat tree
08:14 <whsieh> sanketj: Chromium just has one selection range rn, FF is the only browser that allows multiple. if we're sticking to single range selection and FF returns disjoint ranges, how do we make this useful without having to support multi select in Chromium
08:14 <whsieh> Sean: why would the selection be disjoint?
08:15 <whsieh> dandclark: it's possible to use slot to produce a disjoint selection in composed tree, but a contiguous selection in flat tree
08:15 <whsieh> dandclark: (could produce confusing visual rendering)
08:16 <whsieh> dandclark: agree with sanketj that this would require multiple selection ranges as a prerequisite to get this right
08:16 <whsieh> Sean: sounds like it'll be disjoint in composed tree but contiguous in flat tree
08:17 <whsieh> johanneswilm: does this mean you have two types of selections: contiguous flat tree selections and non-contiguous composed tree selections?
08:18 <whsieh> Sean: yeah, this would basically mean you have two different types of selections
08:19 <whsieh> we could still have the API set in flat tree, but then map into multiple ranges in composed tree
08:19 <whsieh> q+
08:20 <johanneswilm> q+
08:21 <whsieh> johanneswilm: you have one kind of selection at a time — either flat or composed. if the user selects text, what would you end up with?
08:21 <dandclark> q+
08:21 <whsieh> Sean: you'd get flat tree
08:22 <whsieh> dandclark: I think some more concrete examples would be helpful to make a decision
08:23 *** sefeng (~sefeng@9d40a032.publics.cloak) has joined the channel 
08:23 <whsieh> annevk: would be useful to have a writeup that summarizes all of these use cases
08:24 <whsieh> sanketj: ...would also like to second the second part of what dan said — decouple gCR from flat vs. composed
08:24 <whsieh> can always make a version of gCR in the future that works with flat tree
08:25 <whsieh> dandclark: e.g. getFlatTreeRanges() in the future
08:27 <whsieh> Di can leave more examples in https://github.com/w3c/selection-api/issues/336
08:27 <whsieh> johanneswilm: ...and then we'll continue discussion next month
08:27 <johanneswilm> people should look at: https://github.com/dizhang168/shadow-dom-selection/blob/main/flat-tree-setBaseAndExtent.md
08:27 <whsieh> * in https://github.com/dizhang168/shadow-dom-selection/blob/main/flat-tree-setBaseAndExtent.md
08:28 <whsieh> https://github.com/w3c/input-events/issues/162
08:28 <whsieh> johanneswilm: where should we put the information about a paste being plain text only?
08:29 <whsieh> q+
08:33 <whsieh> johanneswilm: this is about paste, not copy. if user pastes as plain text, how does the web app know?
08:33 <whsieh> annevk: in this case, user might not want to share that info with the page
08:34 <whsieh> johanneswilm: simplest way is to not hand page HTML if the user pastes as plain text
08:35 <whsieh> annevk: if it's important, website can suggest that the user should paste normally and not as plain text
08:35 <whsieh> johanneswilm: there may be cases where user pastes as plain text and the website still wants HTML rep. to deliver a more appropriate plain text rep.
08:37 <whsieh> johanneswilm: maybe we can add a new inputType, but there are compat issues now that there is adoption
08:38 <whsieh> johanneswilm: need more time to think about it, it sounds like
08:38 <whsieh> https://github.com/w3c/input-events/issues/161
08:39 <whsieh> johanneswilm: in cE, if you have beforeinput event and you cancel it, it means (a) web app handles the input, or (b) web app prevented the input
08:41 <whsieh> johanneswilm: a cheap answer is that this problem goes away with EditContext
08:41 <whsieh> johanneswilm: but is there some way to fix it for cE as well.....
08:46 <whsieh> dandclark: privacy implications here, since user-specific dictionary is exposed to web app
08:46 <whsieh> dandclark: need to not make this easier
08:48 <whsieh> johanneswilm: perhaps limit to corrections that do not have privacy implications (smart space -> period conversion for instance)
08:49 <whsieh> annevk: privacy implications seem same as before? could always attach mutation observer and detect all of this
08:51 <whsieh> johanneswilm: let's circle back to this next time. annevk and I to discuss with 