[Minutes] Editing WG - 2025-04-10

08:02 <whsieh> issue: https://github.com/w3c/clipboard-apis/issues/49
08:04 *** johanneswilm (~johannes@ecc4d82f.public.cloak) has joined the channel 
08:04 <whsieh> copying selected range: innerHTML vs. outerHTML? browsers disagree
08:04 <whsieh> edgar: would be ideal to have well-defined way of converting range to clipboard HTML
08:04 <whsieh> q+
08:05 <whsieh> johanneswilm: it's chrome/Safari with one behavior, FF with another. why not align FF to Chrome/Safari?
08:07 <whsieh> whsieh: not quite innerHTML — uses heuristic to sanitize visible content for pasteboard in WebKit
08:08 <whsieh> zcorpan: kind of like innerText which is specified
08:08 <whsieh> johanneswilm: also, innerHTML/outerHTML only makes sense for single element. but we need something for DOM ranges
08:09 <whsieh> edgar: in FF, if you select all content under a container, we'll include the container node itself in the copied range
08:09 <whsieh> johanneswilm: so this is really about whether the outer node should be included in this case
08:10 <whsieh> edgar: also depends on how the range is specified..
08:10 <whsieh> dandclark: for Chrome, it's also more complicated than just inner/outerHTML
08:10 <whsieh> dandclark: remember that for table there's a bunch of nuance for including content around cells
08:11 <whsieh> dandclark: we should ...be careful (lots of subtle behaviors at play)
08:12 <whsieh> johanneswilm: is it something we can specify? or is it like half the codebase in the engine
08:12 <whsieh> dandclark: it's complicated (just table stuff, but other stuff too)
08:13 <whsieh> dandclark: would be interesting to see if Mozilla wants to make this change, and see what you run into
08:13 <whsieh> dandclark: unlikely that we would be able to standardize this whole thing in great detail
08:13 <whsieh> dandclark: but maybe we can agree on some high level behaviors
08:13 <whsieh> zcorpan: yeah, needs more investigation to standardize properly
08:13 <whsieh> johanneswilm: how to move on?
08:14 <whsieh> johanneswilm: have Mozilla see if it's possible to align to Chrome/Safari
08:14 <whsieh> (and see if there's any speed bumps along the wway)
08:15 <whsieh> next issue: https://github.com/w3c/clipboard-apis/issues/227
08:15 <whsieh> dandclark: I think we don't have anything new..
08:15 <whsieh> dandclark: one update though — TAG reviewed, and said they were okay with it
08:16 <dandclark> https://github.com/w3ctag/design-reviews/issues/1017
08:17 <whsieh> dandclark: interested in working towards new version of this in Chrome
08:17 <whsieh> next issue: https://github.com/w3c/edit-context/issues/111
08:17 <whsieh> (no new activity)
08:18 <whsieh> https://github.com/whatwg/html/issues/11173
08:19 <whsieh> johanneswilm: we don't really have a good spec around exactly what happens in a cE container with plaintext-only
08:20 <whsieh> johanneswilm: originator noted that plaintext-only behavior is not well specified in this scenario
08:20 <whsieh> johanneswilm: we could make a suggestion here for the whatwg
08:21 <whsieh> zcorpan: this is in scope for execCommand because it's about behavior of delete
08:21 <whsieh> johanneswilm: the reason we divided cE from eCommand is that there might be a future where execCommand is not supported but cE is
08:23 <whsieh> johanneswilm: annevk says he's okay with it being in cE, execCommand or HTML. we should write more works if it's going into HTML spec
08:24 <whsieh> zcorpan: ...spec already suggests that it should work in plaintext-only
08:24 <whsieh> zcorpan: (the execCommand spec that is)
08:25 <whsieh> johanneswilm: we should probably specify this in a document that is not deprecated (i.e. execCommand)
08:26 <whsieh> dandclark: seems like the contentEditable spec would be a good home for this
08:27 <whsieh> dandclark: should we reconsider putting it in cE? HTML spec seems not great because we'll need to keep making changes in HTML spec moving forward (big spec, lot of process to make changes here)
08:27 <whsieh> dandclark: is it too late to put it in cE
08:28 <whsieh> johanneswilm: we could remove all the experimental stuff from cE spec, and then undeprecate it
08:29 <whsieh> dandclark: if we remove experimental stuff from cE and clarify that execCommand is legacy, then seems fine to use cE moving forward
08:31 <whsieh> johanneswilm: (to clarify as well, the execCommand API is here to stay — can't remove it outright from engines)
08:31 <whsieh> johanneswilm: could also consider: new document from scratch?
08:33 <whsieh> zcorpan: let's leave retired cE spec as is — instead make a new document or merge into execCommand and rebrand it to something else
08:34 <whsieh> johanneswilm: sounds like new document is the lowest common denominator 
08:34 <whsieh> dandclark: seems fine to me
08:35 <whsieh> johanneswilm: resolution: new document
08:35 <whsieh> dandclark: tbd — figure out the naming
08:35 <whsieh> q+
08:35 <whsieh> johanneswilm: call cE2 for now or something
08:43 <whsieh> dandclark: note — also not just cE anymore, but also EditContext
08:43 <whsieh> dandclark: should reference generic 'editing hosts' not specifically contentEditable
08:43 <whsieh> zcorpan: in a way, it's closer to UI events-related specs
08:45 <whsieh> johanneswilm: ...can we start writing something here?
08:45 <whsieh> zcorpan: could start by pulling pieces from cE
08:46 <whsieh> johanneswilm: this will be a 'DOM-based editing host' spec covering both cE and EC
08:46 <whsieh> dandclark: maybe input type=text too?
08:46 <whsieh> zcorpan: not considered editing host I think
08:47 <whsieh> dandclark: (...need to double check that)
08:49 <whsieh> johanneswilm: I'll notify w3c..
08:49 <whsieh> dandclark: should we answer the OP's question in https://github.com/whatwg/html/issues/11173?
08:49 <whsieh> dandclark: seems like it should be deleted
08:50 <whsieh> whsieh: (agree)