[Minutes] Editing WG - 2024-12-12

08:03 <whsieh> issue: https://github.com/w3c/input-events/issues/171
08:04 <dandclark> present+
08:04 <whsieh> johanneswilm: is the fact that the input event doesn't fire on password management extensions a bug? or expected behavior
08:05 <whsieh> johanneswilm: (rather beforeinput event)
08:05 <whsieh> johanneswilm: I argue there's no significant privacy risk, nor is this behavior a protection against websites that try to interfere with user input in pw fields
08:06 <whsieh> smaug: probably just a legacy behavior related to when input events fire in PW fields. likely unintentional
08:07 <whsieh> johanneswilm: if there's privacy risk, we should mention it in the spec. if not, then probably it's not worth mentioning in the spec
08:07 <whsieh> smaug: someone from WK or blink should take a look at why beforeinput isn't dispatched
08:08 <whsieh> dandclark: (and we should file an impl. bug)
08:09 <whsieh> johanneswilm: let's resolve for now — just bug in the implementation
08:09 <whsieh> johanneswilm: (no privacy risk — WK and blink will investigate if this is intentional and file bugs if needed)
08:11 <whsieh> issue: https://github.com/w3c/input-events/issues/162
08:12 <whsieh> smaug: still curious about behavior in Blink... otherwise no updates
08:12 <whsieh> issue: https://github.com/w3c/input-events/issues/161
<whsieh3> whsieh: couple of notes — 1. not an issue with EditContext
08:19 *** whsieh (~whsieh@dd4fe3a2.publics.cloak) has quit (whsieh)
08:19 <whsieh3> whsieh3: (2) also maybe not an issue on iOS, where we just listen for two space key presses
08:19 <whsieh3> issue: https://github.com/w3c/input-events/issues/156
08:20 <whsieh3> whsieh3: browsers all fire beforeinput in text controls right now
08:20 <whsieh3> (^ smaug rather)
08:21 <whsieh3> smaug: but should preventDefault on Return cancel form submission
08:21 <whsieh3> johanneswilm: we have a definite list: text, search, tel, url, email, password and number
08:22 <whsieh3> whsieh3: Safari fires beforeinput in all the above (consistent with other engines)
08:23 <whsieh3> smaug: we should say in the spec — if control type is a text control or search control, fire beforeinput
08:23 <whsieh3> johanneswilm: let's resolve — these above types + `textarea` should be mentioned as receiving beforeinput in the spec
08:24 <whsieh3> next issue: https://github.com/w3c/edit-context/issues/111
08:25 <whsieh3> dandclark: 2 parts — selection offset is not updated when text updates; also, if there's an active composition there's no selection change when composition changes
08:25 <whsieh3> dandclark: composition case seems less tenable because there's no API to change selection within a composed range
08:26 <whsieh3> dandclark: cases that could break include co-editing scenarios
08:26 <whsieh3> dandclark: composition range could fall out of sync if someone else is editing in the same place
08:26 <whsieh3> dandclark: seems difficult for authors to work around this..
08:27 <whsieh3> dandclark: when updateSelection is called, that should close the composition
08:28 <whsieh3> dandclark: difficult to change at this point since it shipped, but we might be able to do slow rollout
08:28 <whsieh3> johanneswilm: proposal sounds good to me
08:29 <whsieh3> johanneswilm: the current behavior is strange, doesn't give you a sensible result in most cases
08:30 <whsieh3> dandclark: the risk is that someone is already working around this existing behavior
08:30 <whsieh3> dandclark: difficult to maintain backwards compat
08:30 <whsieh3> johanneswilm: risk is fairly limited, but definitely nonzero
08:31 <whsieh3> johanneswilm: what's the resolution?
08:31 <whsieh3> dandclark: we write up changes to the spec, and then put up a spec PR
08:32 <whsieh3> johanneswilm: dandclark to add a non-normative note to the spec noting that changes may be coming to selection offset update behavior
08:32 <whsieh3> johanneswilm: ..with link to this issue
08:33 <whsieh3> issue: https://github.com/w3c/editing/issues/350
08:34 <whsieh3> johanneswilm: old issue, recently bumped
08:34 <whsieh3> johanneswilm: last time I researched this, there's no platform emoji picker on Linux/GTK
08:35 <whsieh3> smaug: I wonder what the API should look like.. `input type=emoji`?
08:36 <whsieh3> smaug: or alternately, on a contentEditable, make it possible trigger emoji picker using JS API?
08:36 <whsieh3> dandclark: maybe we could use a similar model as VK API
08:37 <whsieh3> dandclark: (also need a way to know if the underlying platform support is present)
08:37 <whsieh3> dandclark: someone needs to put together an explainer going through existing platform support, alternatives, etc.
08:38 <whsieh3> johanneswilm: adding input type=emoji is insufficient for some use cases
08:38 <whsieh3> johanneswilm: ideally would work in contentEditable
08:38 <whsieh3> smaug: ..as well as different OS
08:40 <whsieh3> whsieh3: VK is probably good to take inspiration from but seems weird to tie it *explicitly* to VK API, especially on platforms that don't support VK
08:41 <whsieh3> dandclark: it could probably work with EditContext too
08:42 <whsieh3> johanneswilm: resolution — we're willing to analyze a proposal that satisfies the criteria: works cross-platform, reasonable behavior when platform doesn't support it
08:42 <whsieh3> johanneswilm: …and works for contentEditable and EditContext
08:42 <whsieh3> johanneswilm: ...as well as input type, textarea