[Minutes] Editing WG - 2025-10-09

08:04 <whsieh> issue: https://github.com/w3c/editing/issues/487
08:04 <whsieh> smaug: could we update this by next week?
08:05 <whsieh> johanneswilm: working with JS people to understand the places where input events are lacking
08:06 <whsieh> johanneswilm: let's say, we update the issue by 10/17
08:06 <whsieh> issue: https://github.com/w3c/editing/issues/488
08:07 <whsieh> johanneswilm: this document specifies behavior around editing that is not yet specified in any of the other specs, and not specific to cE or connected to execCommand. E.g. how does the caret move when you use the arrow keys
08:07 <whsieh> johanneswilm: if you have 2 inline images, is the caret supposed to go between them... etc.
08:08 <whsieh> annevk: isn't that related to execCommand? (to what extent should it be separate?)
08:08 <whsieh> johanneswilm: this also applies to edit context
08:09 <whsieh> johanneswilm: (some of the specific issues like `b` tags disappearing might be in cE…)
08:10 <whsieh> annevk: what we want is an algorithm that describes what happens when the user presses up/down/left/right in editable areas... I worry about this approach because it doesn't tell us what happens in the unified case (cE?)
08:11 <whsieh> johanneswilm: if you base things on top of EC you should not have to consult the execCommand or cE specs
08:13 <whsieh> annevk: I agree we should specify a lot of these behaviors, but a lot of these things depend on platform conventions
08:13 <whsieh> johanneswilm: (but not all behaviors) — there are some that would benefit from being defined everywhere. Like caret movement w.r.t. inline images
08:13 <whsieh> annevk: from my POV we should name this document whatever we want right now and we figure out what makes sense as it takes shape
08:14 <whsieh> smaug: there is also now the focus group proposal...
08:14 <whsieh> issue: https://github.com/w3c/editing/issues/490
08:19 <whsieh> whsieh: (we're testing some of these behaviors out)
08:19 <whsieh> whsieh: WebKit will split the inner div into 2 divs, both contentEditable
08:19 <whsieh> smaug: so does FF
08:20 <whsieh> "<body><div contenteditable=\"\">foo <div contenteditable=\"\">b</div><div contenteditable=\"\">ar</div></div></body>"
08:20 <whsieh> issue: https://github.com/w3c/input-events/issues/176
08:21 <whsieh> johanneswilm: they receive 2 insertCompositionText events. one is committing, the other is just the initial text insertion
08:21 <whsieh> johanneswilm: hard to differentiate between the two
08:21 *** anne (~anne@6b13c2d6.publics.cloak) has joined the channel 
08:22 <whsieh> johanneswilm: "is the user still composing? or is this going in the DOM for good"
08:22 <whsieh> johanneswilm: currently, the only way to figure that out is to listen for the end of composition and remember what was last inserted before that
08:23 <whsieh> johanneswilm: the way we originally had it all planned was that we have events that bookend the composition process
08:23 <whsieh> johanneswilm: but that was removed due to implementation challenges in Android
08:24 <whsieh> johanneswilm: that was why EdiContext exists (at least, part of the reason)
08:25 <whsieh> smaug: how is this different from https://github.com/w3c/uievents/issues/394?
08:26 <whsieh> johanneswilm: seems like the same (same person who xposted)
08:29 <whsieh> whsieh: it seems like #394 is more prescriptive — suggests that `isComposing := false` on the last event
08:30 <whsieh> johanneswilm: we should understand (1) what happens when committing part of an IME string (JP live conversion) and (2) whether that works in all IMEs
08:30 <whsieh> anne: would be good to have Masayuki's input
08:31 <whsieh> johanneswilm: let's add a note to the input events spec, so that authors understand there are limits to how much control they have over IME
08:31 <whsieh> johanneswilm: currently not super clear from the spec
08:32 <whsieh> anne: seems like we should just make it work? weird to have an entire stack of events where we're saying they're not useful
08:33 <whsieh> johanneswilm: not that it's useless, but that it's not as powerful for some use cases. only solution for IME is that it allows authors to fix up after the fact
08:33 <whsieh> anne: might be part of interop effort?
08:34 <whsieh> johanneswilm: as it turns out, Chromium did end up implementing almost all of level 2
08:35 <whsieh> johanneswilm: there's just a tiny piece of missing support which is this corner case here
08:35 <whsieh> anne: how much time has passed? maybe we ... try again
08:36 <whsieh> johanneswilm: should we put this on the agenda for TPAC?
08:37 <whsieh> (yes)

Received on Thursday, 9 October 2025 15:39:34 UTC