[Minutes] Editing WG - 2024-8-8

08:02 <whsieh> johanneswilm: https://github.com/w3c/input-events/issues/156
08:04 <whsieh> johanneswilm: for input/textarea, there's currently nothing defined for beforeinput events.
08:04 <whsieh> johanneswilm: should the default behavior be updating the value?
08:04 <whsieh> johanneswilm: so preventDefault updates the value
08:05 <whsieh> smaug: what does chrome do..
08:05 <whsieh> (FWIW Safari/WebKit prevents default in textarea)
08:05 <whsieh> I mean, prevents editing if you prevent default
08:06 <whsieh> whsieh: WebKit will prevent editing if you preventDefault() on insert, delete etc.
08:06 <whsieh> whsieh: ...in a textarea/input element
08:07 <whsieh> johanneswilm: seems reasonable to align behavior of textarea/input to contentEditable
08:07 <whsieh> smaug: form submission is blocked if you preventDefault beforeinput
08:09 <whsieh> whsieh: pressing enter submits the form in WK (even if before input is prevented)
08:09 <whsieh> johanneswilm: first, it sounds like no one is for default value being "nothing"
08:10 <whsieh> johanneswilm: next question, should Enter have a default behavior of form submission in input?
08:11 <whsieh> whsieh: (to clarify, this is about input (not textarea since enter inserts a newline))
08:11 <whsieh> smaug: also what happens with other key combinations like enter+arrow
08:11 <whsieh> sanketj_: default action of beforeinput/input events should not be related to form submission
08:11 <whsieh> sanketj_: that's the behavior of WK/FF
08:12 <whsieh> johanneswilm: can we resolve: we want default behavior to be "changing of the value" in input/textarea?
08:12 <whsieh> johanneswilm: then we have a second question to follow up on: "how do we treat default behavior w.r.t form submission"
08:13 <whsieh> johanneswilm: yeah we should just update spec to reflect what all implementations are doing already
08:14 <whsieh> johanneswilm: maybe we should do more research, to include other key combinations that could be relevant to beforeinput/input
08:14 <whsieh> whsieh: (arrow key probably isn't relevant here because it's not input event)
08:14 <whsieh> sanketj_: sgtm
08:15 <whsieh> johanneswilm: next issue: https://github.com/w3c/input-events/issues/146
08:15 <whsieh> should be good to know how CKEditor deals with results of getTargetRanges()
08:16 <whsieh> ^ smaug
08:16 <whsieh> comandeer: we use it to work around some behaviors in FF (?)
08:17 <whsieh> smaug: there are some known cases where Chrome/Safari do something different, maybe FF is even more different..
08:17 <whsieh> smaug: curious to know what MS might use this for
08:18 <whsieh> johanneswilm: I found that getTargetRanges() are outside of the editable element (seems like a bug)
08:18 <whsieh> johanneswilm: we should probably have some test for that, which applies across all browsers
08:18 <whsieh> johanneswilm: e.g. range that encompasses entire document, both head and body,
08:18 <whsieh> johanneswilm: looked up some of the other things that were mentioned too — CodeMirror and TipTap
08:19 <whsieh> johanneswilm: CM/PM mentioned they're against using beforeinput/input because Android and IME compat
08:19 <whsieh> johanneswilm: that's because everything is composition, and you end up getting all input events in batchces
08:19 <whsieh> *batches
08:20 <whsieh> johanneswilm: beforeinput event also doesn't sufficiently describe everything that's changing
08:20 <whsieh> johanneswilm: all of these issues are specific to contentEditable. but they may not apply to EC
08:20 <whsieh> johanneswilm: found a place where CM/PM uses gTR() in edit context
08:20 <whsieh> johanneswilm: it's disabled until this issue is resolved though
08:21 <whsieh> johanneswilm: would be really good to get this resolved or have a special meeting
08:21 <whsieh> johanneswilm: (...to get it resolved), since it's blocking prime use cases of EC
08:21 <whsieh> smaug: there's also the testing part of this (WPT?) since it's all platform specific
08:22 <whsieh> smaug: we should figure out what to do there, otherwise it'll be difficult to recommend as candidate
08:22 <whsieh> johanneswilm: let's start with simple test cases to verify that gTR doesn't escape editable root
08:23 <whsieh> johanneswilm: while this is a tricky process to improve situation for editors, we don't have a good reason to halt progress because of testing difficulties and gTR
08:24 <whsieh> smaug: do MS folks know about gTR() and how to test?
08:24 <whsieh> (know about whether MS will use gTR that is)
08:24 <whsieh> sanketj_: haven't heard anything about gTR usage. raises confidence in me that it's unlikely to be a source of compat issues.
08:24 <whsieh> dandclark: same
08:25 <whsieh> smaug: will discuss with Masayuki
08:25 <whsieh> johanneswilm: resolve — gTR should never be outside editable container
08:26 <whsieh> johanneswilm: action item to add such tests
08:26 <whsieh> comandeer: will follow up next mtg
08:28 <whsieh> whsieh: re: testing, can we write tests in a more generic way? not specific to DOM
08:29 <whsieh> johanneswilm: some behaviors are completely browser or platform-specific
08:29 <whsieh> johanneswilm: paragraph splitting for instance
08:32 <whsieh> johanneswilm: next issue: https://github.com/w3c/edit-context/issues/103
08:32 <whsieh> johanneswilm: this is dandclark and comandeer
08:32 <whsieh> comandeer: we've started to experiment with EC in CKE. we have nested editable roots
08:33 <whsieh> comandeer: we want to use EC there, with nesting..
08:34 <whsieh> dandclark: we picked a non-arbitrary list based on Shadow DOM UA, since there's precedent
08:34 <whsieh> dandclark: however, figcaption seems reasonable to deploy EC inside of
08:34 <whsieh> dandclark: can we go the other way — start with all elements and subtract away a subset?
08:35 <whsieh> dandclark: no script elements, some form controls, object/iframe for example
08:35 <whsieh> dandclark: next thing — do exercise of coming up with comprehensive list
08:35 <whsieh> dandclark: easy to expand, not easy to claw back. we should be sure
08:36 <whsieh> johanneswilm: w.r.t. this nested editing behavior... there's two ways of doing this with EC
08:36 <whsieh> johanneswilm: either multiple nested EC, or have a single EC but preventDefault() (or equivalent thereof) on the fly
08:37 <whsieh> comandeer: we currently use multiple EC, multiple levels
08:38 <whsieh> johanneswilm: (are these the only two options? should we recommend one or the other?)
08:38 <whsieh> johanneswilm: would it be worth having an explanatory note in the spec, to clarify this?
08:38 <whsieh> dandclark: having separate EC instances seems like the natural way to go about this
08:39 <whsieh> dandclark: there's separate editable fields and they logically have different text content
08:39 <whsieh> dandclark: as long as they're actual separate fields where you can't delete and delete text in another field, they should probably be separate contexts too
08:39 <whsieh> dandclark: ...but both are reasonable, ultimately
08:40 <whsieh> johanneswilm: dandclark will come up with comprehensive list next mtg
08:40 <whsieh> johanneswilm: next issue: https://github.com/w3c/edit-context/pull/100
08:41 <whsieh> johanneswilm: makes it easier to track down changes
08:42 <whsieh> johanneswilm: resolution!
08:42 <whsieh> next issue: https://github.com/w3c/selection-api/issues/176
08:43 <whsieh> sanketj_: main thing — gCR is supposed to take a list of shadow roots that are allowed
08:43 <whsieh> sanketj_: dictionary of options
08:44 <whsieh> sanketj_: selection API uses rest param syntax. unfortunately, means we can't augment without breaking compat
08:45 <whsieh> sanketj_: can we instead make it take optional argument dictionary? so we can augment it easily later
08:45 <whsieh> whsieh: I'll bring it up with rniwa and see. seems reasonable though
08:50 <whsieh> sanketj_: should we include the template as well here?
08:51 <whsieh> sanketj_: Chromium, WK, FF all have active work in this space
08:51 <whsieh> sanketj_: might be a good pilot for the new PR template
08:52 <whsieh> smaug: note — there's also https://github.com/w3c/selection-api/issues/168
08:53 <whsieh> johanneswilm: action item on whsieh — talk to https://github.com/w3c/edit-context/pull/100, to consider using the new PR template here