[Minutes] Editing WG - 2026-03-12

08:03 <whsieh> issue: https://github.com/w3c/editing/issues/529
08:03 <dandclark> present+
08:03 <whsieh> johanneswilm: Rakesh, what is the status of this document?
08:04 <whsieh> Rakesh: will get something out early next week
08:04 <whsieh> Rakesh: also working on bidi support
08:04 <whsieh> Rakesh: will sync separately, because I have some questions related to previous material around caret mvmt
08:04 <whsieh> johanneswilm: explainer is just describing what to cover — doesn't require same level of alignment
08:05 <whsieh> issue: https://github.com/w3c/editing/issues/527
08:05 <whsieh> xiaoqian: the group needs to make a decision on VK API
08:06 <whsieh> xiaoqian: (and spellchecker API)
08:06 <whsieh> issue: https://github.com/w3c/editing/issues/528
08:08 <whsieh> michael_aufreiter: most RTE use this approach. this proposes a standard for this behavior
08:08 <whsieh> michael_aufreiter: several issues reported earlier w.r.t. rendering caret on top of empty element with placeholder
08:09 <whsieh> q+
08:09 <whsieh> johanneswilm: looking for initial input on this?
08:09 <whsieh> michael_aufreiter: yes
08:10 <whsieh> whsieh: what exactly is a placeholder?
08:10 <whsieh> michael_aufreiter: ::before pseudo-element for instance
08:10 <whsieh> michael_aufreiter: (that's actually the most non-invasive way)
08:10 <whsieh> michael_aufreiter: we could come up with other ideas though
08:11 <whsieh> michael_aufreiter: want to have empty placeholders in the DOM that would be laid out in the same way as a real DOM element. and then once the caret moves into the placeholder the placeholder would disappear
08:11 <whsieh> michael_aufreiter: in my case we don't remove the placeholders when we go there
08:11 <whsieh> michael_aufreiter: but it depends on the use case
08:12 <whsieh> johanneswilm: would make elements generally addressible
08:12 <whsieh> johanneswilm: feels slightly hacky to put a random element in there
08:12 *** ragoulik (~ragoulik@b6520e17.publics.cloak) has quit (ragoulik)
08:13 <whsieh> michael_aufreiter: for me, what often happens is I have an empty div that I make non-editable, inside an editable container
08:13 <whsieh> johanneswilm: this is about automatic placement of the caret in empty placeholder elements
08:14 <whsieh> Rakesh: we experimented with defining default height for such elements
08:14 <whsieh> Rakesh: the issue is that you can't otherwise click (hit-test) an empty placeholder
08:15 <whsieh> michael_aufreiter: good point, that's actually the reason for the BR — you really want the line-height there but keep it empty still
08:15 <whsieh> Rakesh: also we noticed this already works in FF
08:16 <whsieh> Rakesh: ...talking about bug we observed (not GH issue tho)
08:17 <whsieh> johanneswilm: maybe another concrete example: empty <i> or <b> where you don't want certain elements to be addressable, and that's why we would want that distinction
08:18 <whsieh> https://github.com/w3c/editing/issues/497
08:19 <whsieh> michael_aufreiter: (instead of agenda+, look for priority flag)
08:19 <whsieh> other 2 are 505 and 496
08:19 <whsieh> https://github.com/w3c/editing/issues/493
08:20 <whsieh> michael_aufreiter: why are these inconsistent? (semantic difference?)
08:20 <whsieh> smaug: would like to see some more testing…
08:21 <whsieh> smaug: in more complicated scenarios, curious if they are still consistent in WK/blink
08:21 *** ragoulik (~ragoulik@b6520e17.publics.cloak) has joined the channel 
08:21 <whsieh> smaug: one possibly interesting difference is that FF supports multiple ranges!
08:22 <whsieh> michael_aufreiter: let's keep it paused until I have clearer picture
08:23 <whsieh> issue: https://github.com/w3c/input-events/issues/177
08:23 <whsieh> Rakesh: this is the one about WPT?
08:24 <whsieh> Rakesh: context — made the change that was requested for the WPT, and update should have landed by now
08:25 <whsieh> Rakesh: (utpathak made the update ^)
08:25 <whsieh> annevk: don't see recent updates to the test…
08:26 <whsieh> annevk: I see update in https://github.com/web-platform-tests/wpt/pull/58390
08:26 <whsieh> johanneswilm: all in agreement that it's resolved?
08:26 <whsieh> smaug: masayuki to confirm but seems so
08:27 <whsieh> next issue: https://github.com/w3c/input-events/issues/176
08:28 <whsieh> smaug: basically what masayuki said: spec has been documenting Chrome's behavior. IE (pre-blink) and FF were aligned
08:28 <whsieh> smaug: the bookended isComposing := false makes it easier for developers to know when it ends w/o compositionend
08:29 <whsieh> smaug: let's hear from web devs (Michael?)
08:29 <whsieh> johanneswilm: back when we discussed years ago, desire was for the event before the end to be cancelable
08:30 <whsieh> johanneswilm: in practice, developers probably better off waiting for the isComposing false and then cleaning up after
08:31 <whsieh> michael_aufreiter: there is a trick to cancel — remove focus temporarily on compositionstart
08:32 <whsieh> johanneswilm: from the perspective of a JS developer either approach seems reasonable
08:32 <whsieh> johanneswilm: is there any reason other browsers don't implement this?
08:32 <whsieh> smaug: …in any case, there is going to be *some* web compat risk
08:33 <whsieh> smaug: but I suppose something is broken today anyways
08:33 <whsieh> whsieh: seems reasonable at a glance, we'll want to discuss internally (WebKit)
08:34 <whsieh> whsieh: just to verify, they aren't mutually exclusive?
08:34 <whsieh> johanneswilm: correct
08:35 <whsieh> smaug: though you'd get 2 input events with isComposing = false (tiny bit weird, not that weird)
08:35 <whsieh> johanneswilm: so we need feedback from WebKit/Chromium?
08:35 <whsieh> (yes)
08:35 <whsieh> johanneswilm: and would FF be open to adopting level 2 input event spec behavior?
08:35 <whsieh> smaug: FF would be open to it, but let's hear from developers what they prefer
08:36 <whsieh> johanneswilm: many of the developers are in this call!
08:37 <whsieh> smaug: true, but it would be good to have input from people solving these issues at Google Docs/Office
08:37 <whsieh> Rakesh: office web apps have started using these events
08:37 <whsieh> Rakesh: need to look into it more before I comment…
08:38 <whsieh> xiaoqian: wondering if we want to use AI for scribing?
08:38 <whsieh> xiaoqian: (we'd switch over to Google Meet for that)
08:39 <whsieh> johanneswilm: sure, as long as it works for people on various platforms
08:40 <whsieh> michael_aufreiter: circling back to caret movement spec — what are the next steps?
08:40 <whsieh> johanneswilm: we've been collecting various issues regarding caret movement, and MS also is investigating bidi text
08:41 <whsieh> johanneswilm: the reason we need an explainer now is because we added this to the charter
08:42 <whsieh> johanneswilm: (and we were asked to provide explainer for this caret movement spec)
08:42 <whsieh> michael_aufreiter: another thing that might be interesting — overlay that follows the caret (?)
08:45 <whsieh> michael_aufreiter: (this is about potentially moving caret based purely on screen position rather than DOM order)
08:46 <whsieh> might be interesting to spec
08:49 <whsieh> whsieh: need to consider corner cases like moving caret in bidi text
08:50 <whsieh> johanneswilm: even if it doesn't describe the behavior everyone wants, behaviors like this should become standard
08:51 <ragoulik> mac has introduced the capability to control caret navigation https://support.apple.com/en-euro/guide/mac-help/mh21243/mac does safari plan to support these?08:54 <whsieh> it is possible to right click > Paragraph Direction > (RTL|LTR) in Safari, yes