[Minutes] Editing WG - 2025-02-13

08:02 <whsieh> https://github.com/w3c/clipboard-apis/issues/232
08:03 *** Di (~Di@dd4fe3a2.publics.cloak) has joined the channel 
08:04 <whsieh> zgroza: this helps in the case where UA doesn't support persistent clipboard permissions
08:05 <whsieh> smaug: current proposal feels better than clipboardchange event
08:05 <whsieh> zgroza: from what I remember, MS is planning to implement clipboardchange only when website is focused
08:06 <whsieh> zgroza: in that case, shouldn't be that harmful (w.r.t. privacy)
08:07 <whsieh> smaug: ^ focus, or transient activation?
08:07 <whsieh> zgroza: it's focus
08:08 <whsieh> zgroza: same guard rails that make it where the webpage can read()
08:09 <whsieh> zgroza: would prefer contentsId to not require user activation
08:14 <whsieh> zgroza (et. al.): may return 0 until first user activation
08:15 <whsieh> ...to prevent websites from polling to figure out that the user has copied anywhere else
08:15 <whsieh> sanket: consolidate both approaches (content ID and event)
08:16 <whsieh> next issue: https://github.com/w3c/input-events/issues/162
08:17 <whsieh> dandclark: answer to what's current Chrome behavior: input event never has DT when pasting rich text into editable areas — just beforeinput
08:17 <whsieh> dandclark: for CTRL+Shift+V paste into rich text, we get DT with text/plain. for plain text editable we only get plain text (data)
08:17 <whsieh> dandclark: behavior goes pretty far back. not really a deliberate decision?
08:18 <whsieh> dandclark: maybe we have some flexibility about how to move forward..
08:20 <whsieh> dandclark / smaug: beforeinput behavior is consistent, but Chrome behavior is different — `input` lacks DT
08:21 <whsieh> dandclark: reasonable to add DT for paste into plaintext-only
08:21 <whsieh> dandclark: maybe drop text/html when pasting as plaintext
08:22 <whsieh> annevk: would expect plaintext-only to behave the same way as input
08:23 <whsieh> johanneswilm: proposal: add DT in all cases, but make "paste as plain text" only send DT with text/plain?
08:24 <whsieh> dandclark: paste into plaintext-only target will now have rich format on pasteboard
08:26 <johanneswilm> https://w3c.github.io/input-events/#interface-InputEvent-Attributes
08:27 <whsieh> dandclark: …maybe step 0 is have WPTs for this so we can survey existing behaviors
08:27 <whsieh> dandclark: …and then dig into spec
08:29 <whsieh> annevk: maybe start with comment describing state of all engines
08:29 <smaug> https://searchfox.org/mozilla-central/source/testing/web-platform/tests/editing/plaintext-only/paste.https.html
08:29 <smaug> Some related tests
08:29 <smaug> as an example
08:30 <whsieh> johanneswilm: notes will be left in the issue
08:30 <smaug> looks like masayuki wrote that test for " paste/drop things as plaintext when `contenteditable=plaintext-only`"
08:30 <whsieh> https://github.com/w3c/edit-context/issues/111
08:31 <whsieh> dandclark: let's make the proposed change... resolution from last time still stands
08:32 <whsieh> next: https://github.com/w3c/selection-api/issues/2
08:33 <whsieh> Di: add new def. in DOM side…
08:33 <whsieh> Di: from DOM side, we're changing live range to mean abstract range that reacts to mutations in the DOM
08:33 <whsieh> Di: define new ComposedLiveRange that allows traversal across shadow tree
08:34 <Di> https://github.com/w3c/selection-api/pull/345
08:35 *** sanketj (~uid392014@4f1164.public.cloak) has joined the channel 
08:35 <whsieh> annevk: wonder about whether live range already has tendencies outside the DOM, which may be impacted by changing the definition
08:36 <whsieh> annevk: CSS highlights and selection may be impacted: https://dontcallmedom.github.io/webdex/l.html#live%20ranges%40%40dom%25%25dfn
08:36 <whsieh> annevk: maybe instead of redefining live range, we can define live composed range as another kind of range
08:38 <whsieh> for a normal live range (which also ends up matching live compose range), it update the range only when it's in a single tree scope
08:39 <whsieh> Di: if you have a normal live range that doesn't cross tree boundaries, the live range updates by itself..
08:39 <whsieh> Di: our compose live range is attached to a (legacy) live range, which allows us to support all existing behaviors
08:40 <whsieh> annevk: but the current model updates both composed live range and legacy live range, but *then* updates the composed live range again?
08:40 <whsieh> annevk: may need to clarify this processing model
08:41 <whsieh> annevk: would help to work through concrete examples of range that spans across shadow trees
08:41 <whsieh> annevk: (examples should consider what happens when shadow tree changes)
08:41 <whsieh> johanneswilm/Di: maybe we should write WPT?
08:43 <whsieh> annevk: why would we first do the shadow-inclusive descendant check, and then later do the shadow inclusive check?
08:44 <whsieh> *ancestor inclusive check
08:44 <whsieh> annevk: since composed LR is also a LR, we potentially update its start and end twice
08:45 <whsieh> Di: not accurate, it would only be updated once
08:46 <Di> https://github.com/whatwg/dom/pull/1342
08:46 <whsieh> Di: the way the spec is written, we check shadow inclusive second, shadow inclusive ancestors first
08:48 <whsieh> johanneswilm: next step, Di, smaug and annevk discuss in GH issue and coordinate
08:49 <whsieh> smaug: actually, I just need to read this and make sure it meets all the constraints
08:49 <whsieh> last item: https://github.com/w3c/editing/issues/480
08:50 <whsieh> johanneswilm: florian suggested publishing as discontinued draft
08:50 <whsieh> johanneswilm: annevk said we should check if this is allowed