[Minutes] Editing WG - 2024-12-09

08:02 *** whsieh (~whsieh@9d40a032.publics.cloak) has joined the channel 
08:02 <whsieh> present+
08:02 <comandeer> present+
08:03 <whsieh> di: let's discuss selection APIs during TPAC
08:03 <whsieh> issue: https://github.com/w3c/edit-context/issues/103
08:04 <whsieh> smaug: why did we limit element types in the first place?
08:04 <whsieh> sanket: support canvas, otherwise just match contenteditable
08:05 *** sanketj_ (~uid392014@2bef0590.public.cloak) has joined the channel 
08:06 <whsieh> dandclark: proposed element list includes things like area, map, dialog, html
08:06 <whsieh> (https://github.com/w3c/edit-context/issues/103#issuecomment-2344923844)
08:06 *** johanneswilm (~johannes@2bef0590.public.cloak) has joined the channel 
08:06 <whsieh> dandclark: you can set cE on any of these elements today, and browsers *try* to do reasonable things. behavior is inconsistent though (e.g. setting cE on iframe element)
08:08 <whsieh> dandclark: two paths — use original list in comment #103, or do more conservative approach of limiting EC to smaller subset
08:09 <whsieh> johanneswilm: if we keep them supported on an element, do we expect it to be effectively usable? (e.g. EC on slot or HTML)
08:09 <whsieh> dandclark: probably do something reasonable — slot for instance may not become editable, HTML might result in same behavior as cE on HTML
08:10 <whsieh> smaug: we should consider custom elements
08:10 <whsieh> dandclark: we already allow those
08:10 <whsieh> smaug: what about cE/EC to table?
08:12 <whsieh> johanneswilm: there's a risk where if we enable it on certain "stranger" elements, people might find esoteric use cases. e.g. being able to modify a visible display: block; style element to drive live style updates in the page
08:13 *** Di (~Di@9d40a032.publics.cloak) has joined the channel 
08:13 <whsieh> johanneswilm / dandclark: proposal is to go with the list in https://github.com/w3c/edit-context/issues/103#issuecomment-2344923844, and remove some subset of elements that just don't make sense. consider adding head/style to that list
08:14 <whsieh> dandclark: let's find others that should be excluded, and err on the side of caution 
08:14 <whsieh> • issue — https://github.com/w3c/edit-context/issues/96
08:16 <whsieh> dandclark: the problem is that updateCharBounds requires editor to provide bounds per character in the string, but what happens for a grapheme cluster that spans multiple characters in the string?
08:17 <whsieh> dandclark: e.g. 👨🏻‍⚕️would require >2 (4?) characters in the string, what does it mean to ask for bounds of [0, 1] in the string
08:17 <whsieh> dandclark: should we make the ranges based on grapheme cluster instead?
08:18 <whsieh> dandclark: proposal: can we keep it how it is today? web devs don't need to generally worry about grapheme clusters directly today — authors generally work in terms of JS string indices
08:19 <whsieh> smaug: would be good to get more feedback from web devs
08:20 <whsieh> dandclark: what I read is, we could ask for the ranges in grapheme clusters but the author would need to then worry about grapheme clusters anyways
08:20 <whsieh> q+
08:21 <whsieh> dandclark: is grapheme cluster even consistent across browsers/platforms? would web dev need to worry about this
08:23 <whsieh> dandclark: right now, things tend to Just Work because the string indices line up with the backing store indices. because the backing store is a string..
08:24 <whsieh> dandclark: ...but let's get more dev feedback.
08:24 <whsieh> possible we're missing a nuance
08:27 <whsieh> whsieh: can we bake the contract of "UA never asks for range that starts/stops in the middle of a grapheme cluster" into the spec?
08:27 <whsieh> dandclark: seems like a bug if a browser were to do that. not sure whether that would be a normative note
08:28 <whsieh> dandclark: (maybe a non-normative note)
08:28 <whsieh> dandclark: we'll need to be careful about terminology here
08:29 <whsieh> johanneswilm: browser knows internally where grapheme clusters start/end
08:30 <whsieh> dandclark: oh, wait — author might have a way of segmenting code points that disagrees with the browser/platform
08:30 <whsieh> dandclark: e.g. fully canvas-driven text rendering in JS
08:31 <whsieh> dandclark: maybe the browser shouldn't (generally) have an opinion about this
08:32 <whsieh> • issue — https://github.com/w3c/input-events/issues/156
08:34 <whsieh> smaug: in Gecko, form submission isn't a part of the text input stack — text input basically cedes control to form submission
08:35 <whsieh> smaug: also what about arrow key + select elements?
08:35 <whsieh> smaug: input type=number as well. lots of corner cases where input values change but beforeinput/input event behavior is not well defined
08:36 <whsieh> smaug: back to the original issue though, pressing Enter to submit — not actually entering any text, so it seems really weird to fire input events
08:36 <whsieh> sanketj_: as an aside, someone is working on rewriting UI events spec
08:36 <whsieh> (maybe garykac?)
08:37 <whsieh> johanneswilm: .....has been an ongoing effort for many years
08:38 <whsieh> sanketj_: DOM changing for input/textarea so probably should fire input/beforeinput. not sure about select..
08:38 <whsieh> sanketj_: behavior is probably *largely* aligned among browsers
08:39 <whsieh> smaug: Enter on form submission feels like a different thing altogether
08:41 <whsieh> johanneswilm: let's circle back on what preventDefault on beforeinput should do
08:42 <whsieh> johanneswilm: does not seem correct that stopping beforeinput stops form submission
08:43 <whsieh> sanketj_: beforeinput should be fired in tandem with DOM mutations
08:44 <whsieh> smaug: would need to define ordering of submit and input events
08:45 <whsieh> smaug: we all agree that this is supported for text fields, textarea. not the other use cases that don't involve text fields
08:46 <whsieh> dandclark: what about date picker, which is comprised of several text fields?
08:46 <whsieh> sanketj_: should fire anytime you're changing UA shadow dom
08:46 <whsieh> smaug: ...but UA shadow dom isn't defiend
08:46 <whsieh> *defined
08:46 <whsieh> q+
08:48 <whsieh> whsieh: shouldn't we align to what all browsers already agree on
08:49 <whsieh> johanneswilm: unless there's a compelling use case?
08:49 <whsieh> sanketj_: let's scope to input types that are editable fields
08:49 <whsieh> sanketj_: text, search, number, password, email, url, …
08:49 <whsieh> sanketj_: let's exclude pickers, checkbox, range, radio
08:50 <whsieh> q+
08:50 <whsieh> johanneswilm: date picker is hard-coded to browser's localization
08:50 <whsieh> johanneswilm: probably may not be compelling use case for htat
08:51 <whsieh> q-
08:52 <whsieh> smaug: let's split out the enter key form submission problem into a separate issue
08:53 <whsieh> smaug: let's all ponder https://github.com/w3c/input-events/issues/158 ahead of TPAC