[Minutes] Editing WG - 2025-01-09

08:02 <whsieh> issue https://github.com/w3c/editing/issues/468
08:03 <whsieh> johanneswilm: several proposed solutions in GH issue
08:06 <whsieh> johanneswilm: what if we removed empty bold tag if the selection was moved?
08:06 <whsieh> johanneswilm: but this is weird because changing selection could change the DOM
08:07 <whsieh> zcorpan: also DOM changes could affect layout which is not ideal when changing selection
08:07 <whsieh> zcorpan: and this only makes sense for bold, not all typing styles (font size, font family, etc.)
08:07 <whsieh> zcorpan: any other alternatives?
08:08 <whsieh> zcorpan: FWIW there's already document.queryCommandState
08:08 <whsieh> zcorpan: (though this only works for built-in editing commands like bold, not font size)
08:09 <zcorpan> https://w3c.github.io/editing/docs/execCommand/#querycommandstate()
08:09 <whsieh> johanneswilm: this is execCommand-adjacent, which we're trying to move away from
08:10 <whsieh> johanneswilm: we might even want to communicate other state like caret blinking, font info, etc.
08:10 <whsieh> johanneswilm: yet another approach was to have multiple input events (extra formatbold)
08:11 <whsieh> johanneswilm: ......or maybe a separate input type like `insertStyledText`
08:11 <whsieh> johanneswilm: going back to `queryCommandState`, I don't think it'll work with EditContext
08:11 <whsieh> dandclark: ones that are not rich text dependent will work
08:12 <whsieh> dandclark: automatic insertion of bold/other formatting does not apply to EditContext
08:13 <whsieh> johanneswilm: maybe we should invent something that makes sense for EditContext for consistency
08:13 <whsieh> zcorpan: new idea — can we use mutation observer to detect?
08:13 <whsieh> zcorpan: (rather, can the web dev use mutationobserver)
08:13 <whsieh> johanneswilm: idea of input events is that developer shouldn't need to do this
08:14 <whsieh> johanneswilm: but maybe solution is "we don't fix this since it's superseded by EditContext and developers make it mostly work already in cE using queryCommandState and/or mutation observers"
08:15 <whsieh> johanneswilm: there also isn't a really strong motivation for this (no project is asking for this)
08:15 <whsieh> dandclark: agree, compat risk may be more effort than it's worth
08:15 <whsieh> dandclark: recommend tabling
08:15 <whsieh> zcorpan: seems reasonable
08:15 <whsieh> zcorpan: ..especially if mutation observer is viable workaround
08:17 <whsieh> johanneswilm: so IIRC the motivation for this is that we should've standardized how input events happen in cE w.r.t. target ranges
08:19 <whsieh> johanneswilm: resolution (for time being) — table this issue, wait for FF (masayuki) to follow up
08:19 <whsieh> next issue: https://github.com/w3c/input-events/issues/162
08:21 <whsieh> johanneswilm: any updates?
08:22 <whsieh> johanneswilm: let's put an action item to move this forward
08:23 <whsieh> zcorpan: context — cE plaintext-only, paste/drop some rich text. what gets exposed on the DT?
08:24 <whsieh> johanneswilm: question for Blink is — is Blink following the spec? if not, why not?
08:24 <whsieh> dandclark: this is for drag/drop not plaintext paste?
08:25 <whsieh> johanneswilm: this is for paste _and_ drop into plain text areas
08:25 <whsieh> dandclark: I'll see if I can figure out our current behavior and untangle the history
08:26 <whsieh> next issue: https://github.com/w3c/input-events/issues/156
08:26 <whsieh> johanneswilm: smaug made a list of elements that should get beforeinput
08:26 <whsieh> johanneswilm: waiting for any other feedback on this…
08:27 <dandclark> https://github.com/w3c/clipboard-apis/issues/232
08:27 <whsieh> johanneswilm: (does not seem to be any feedback)
08:28 <whsieh> dandclark: wanted to know what folks think about #232 (clipboard APIs)
08:28 <whsieh> zcorpan: the ID is just a generated ID that's the same if content is the same?
08:28 <whsieh> dandclark: yes
08:29 <whsieh> zcorpan: we can have a look
08:30 <whsieh> johanneswilm: switching gears — trying to get input events through w3c…
08:30 <whsieh> johanneswilm: spec is a bit stagnant.. last issue was a potential privacy concern which turned out to be a bug (input events in PW?)
08:31 <whsieh> johanneswilm: also, do we need to renew execCommand, for rechartering?
08:32 <whsieh> zcorpan: haven't started working on it yet but I think we should include execCommand in charter
08:32 <whsieh> zcorpan: it's something browsers need to implement in practice, so we'd need to add it as a potential delivery
08:32 <whsieh> zcorpan: ig same for contentEditable
08:32 <whsieh> zcorpan: (currently under "archived", not deliverable)
08:34 <whsieh> johanneswilm: ah, I remember this. so contentEditable spec is something we worked on before we started input events/EC. idea at the time was that we wanted to give access to JS at different levels (cE vs. higher level input events) to handle IME and other workflows. We went back and forth and in the end we came up with EditContext which basically is the evolution of "contentEditable=events"
08:35 <whsieh> johanneswilm: so the archived document is basically a historical document. no longer really relevant
08:35 <whsieh> zcorpan: are true and plaintext-only cases defined in HTML spec?
08:35 <whsieh> johanneswilm: yes I think
08:36 <whsieh> johanneswilm: if you need a document that describes this further, you can take this document and update it to describe what's implemented nowadays
08:36 <whsieh> johanneswilm: this document was an old attempt to try and tackle this problem, which is now solved with EditContext
08:36 <whsieh> zcorpan: maybe this should be archived and/or removed
08:37 <whsieh> johanneswilm: I will take action item to get it removed there
08:37 <zcorpan> https://w3c.github.io/contentEditable/
08:37 <johanneswilm> https://github.com/w3c/contentEditable/blob/gh-pages/index.html