[Minutes] Editing WG - 2024-1-11

[08:01] <whsieh> present+
[08:02] <whsieh> first issue: https://github.com/w3c/clipboard-apis/issues/191
[08:02] <smaug> present+
[08:02] <@dandclark> present+
[08:02] <comandeer> present+
[08:04] <johanneswilm> present+
[08:04] <whsieh> Evan: concerns — the spec explicitly states something contrary to this
[08:04] <whsieh> Evan: changing this introduces new error cases
[08:05] <whsieh> Evan: potential to introduce error cases for sites that adopt clipboard API but don't want this behavior
[08:05] <whsieh> Evan: gap between when request for data is made and when promise is resolved (?)
[08:05] <whsieh> Evan: what happens if pboard contents change in between
[08:06] <whsieh> Evan: in Chrome, we gate pasteboard access behind transient user activation check
[08:07] <whsieh> Evan: another proposal: instead of using getType, specify a list of types
[08:08] <whsieh> snianu: there's a sequence number check
[08:09] <whsieh> snianu: (…to prevent page from reading changed pboard content)
[08:09] <whsieh> smaug: there is risk
[08:10] <whsieh> snianu: re: async concern, the error still applies to DataTransfer?
[08:10] <whsieh> snianu: if sites already handle DT APIs well how would this be different
[08:11] <whsieh> smaug: ordering may cause issues
[08:12] <whsieh> Evan: can we extend the existing API in a way that doesn't impact existing adoption
[08:13] <whsieh> q+
[08:14] <whsieh> Evan: I don't think sites aren't going to be straight up broken. it'll be flaky
[08:14] <whsieh> Evan: unsure what % of the time it will be broken
[08:14] <whsieh> Evan: edge case that may hinder usability
[08:15] <sanketj_> present+
[08:15] <sanketj_> q+
[08:16] <whsieh> sanketj_: we're potentially trying to find a different soln. due to compatibility risk
[08:17] <whsieh> sanketj_: are we saying this is the right solution (ignoring compat risk), or is it fundamentally a bad design?
[08:17] <whsieh> Evan: latter, because it introduces flakiness
[08:17] <whsieh> sanketj_: this is under the assumption that the site doesn't call getType
[08:19] <whsieh> snianu: when you call read() in Chromium, all the data is eagerly read and cached
[08:20] <whsieh> Evan: the most likely outcome of this error case is silently failing
[08:20] <whsieh> q+
[08:20] <whsieh> Evan: admittedly isn't common
[08:20] <smaug> q+
[08:21] <smaug> q-
[08:22] <whsieh> snianu: the resolution _was_ to change behavior to not read items up front
[08:22] <whsieh> snianu: to web authors, there's no significant difference
[08:24] <whsieh> smaug: it's important to make the spec explicit about this
[08:24] <whsieh> smaug: (not just imply. detail)
[08:24] <whsieh> *impl
[08:25] <whsieh> Evan: broken site would not necessarily be due to a site issue
[08:25] <whsieh> Evan: since it should work in theory today if you called getType() later
[08:26] <whsieh> Evan: is there an objection to finding an additive change to the spec to make this new async behavior opt-in?
[08:26] <whsieh> Evan: excel doesn't call getType() immediately. shows a prompt to the user to choose _which_ type
[08:26] <whsieh> Evan: significant delay b/t read() and getType()
[08:27] <whsieh> sanketj_: the main goal is to avoid reading formats that are not asked for by the site
[08:28] <whsieh> Evan: you can achieve this by passing a type list when reading data
[08:28] <whsieh> Evan: (this is just one proposal)
[08:29] <whsieh> johanneswilm: do we need a special meeting for this?
[08:29] <whsieh> snianu: we already had resolution, but these are valid concerns. we can schedule special meeting.
[08:30] <whsieh> johanneswilm: we can continue discussing in the issue and arrange a special meeting
[08:30] <snianu> present+
[08:30] <snianu> I would like to attend the meeting
[08:30] <whsieh> johanneswilm: who will organize this meeting?
[08:30] <whsieh> (I would also like to attend)
[08:31] <smaug> I could attend
[08:31] <whsieh> sanketj_: snianu and I will arrange
[08:31] <whsieh> let's move on to https://github.com/w3c/input-events/issues/146 …
[08:32] <whsieh> smaug: basic proposal is that when you're doing something like backspace and selection is collapsed, don't report any ranges
[08:32] <whsieh> q+
[08:32] <@dandclark> q+
[08:32] <whsieh> q-
[08:32] <whsieh> smaug: which elements merged/removed is up to engine
[08:33] <whsieh> johanneswilm: getTargetRanges() will be different in cE vs. EC?
[08:33] <whsieh> johanneswilm: it's possible to change behavior in cE/input events, FF has done it in the past
[08:34] <whsieh> johanneswilm: (clarify): if the selection is not collapsed, getTargetRanges should return non-empty range
[08:34] <whsieh> johanneswilm: ...more exactly, should return the selection range
[08:35] <whsieh> johanneswilm: we want to allow web authors to match platform conventions
[08:35] <whsieh> johanneswilm: this makes it difficult
[08:38] <whsieh> smaug: do WK and chrome have different behviors
[08:39] <whsieh> johanneswilm: the implementations are not consistent, and it's not a requirement
[08:40] <whsieh> johanneswilm: from developer POV: you either use cE where you get platform convention info or you use EC and you get better IME handling
[08:40] <whsieh> dandclark: second everything johanneswilm has been saying
[08:40] <whsieh> dandclark: seems not good to have this tradeoff
[08:41] <whsieh> smaug: does Chrome have different behavior on macOS vs. windows when merging elements?
[08:42] <whsieh> johanneswilm: I don't think it's impossible to change getTR for cE
[08:42] <whsieh> johanneswilm: it's used by editors that need to be very robust, and handle corner cases and platform/engine differences like this
[08:43] <whsieh> johanneswilm: good to align behaviors when it makes sense
[08:43] <whsieh> (would be good to)
[08:43] <whsieh> johanneswilm: I know there's one bug in FF that many authors are currently working around atm
[08:43] <whsieh> johanneswilm: shouldn't be an issue to standardize to make this workaround unneeded
[08:43] <whsieh> smaug: need to sync up with masayuki again
[08:44] <@dandclark> https://github.com/w3c/edit-context/issues/86
[08:44] <whsieh> johanneswilm: dandclark and I discussed what to do with getTR in canvas, issue is https://github.com/w3c/edit-context/issues/86
[08:45] <whsieh> snianu: I'll check and see if there's platform-specific behaviors in Chrome when merging elements during editing
[08:46] <whsieh> next: https://github.com/w3c/editing/issues/439
[08:46] == dandclark [~sid391790@c080ddbb.public.cloak] has left #editing []
[08:46] == dandclark [~sid391790@c080ddbb.public.cloak] has joined #editing
[08:47] <whsieh> snianu: there's another mitigation — can we trigger *all* the callbacks asynchronously to limit FP surface?
[08:48] <whsieh> snianu: (less effective at delaying rendering, but...)
[08:48] <whsieh> snianu: at least it might help with the privacy risk
[08:48] <whsieh> q+
[08:50] <whsieh> snianu: typically only one custom format with high fidelity content
[08:50] <sanketj_> q+
[08:50] <whsieh> snianu: adobe mentioned that for images, they might have multiple custom formats that are expensive
[08:50] <whsieh> snianu: so in practice, usually 1 or 2, maybe more for images/media
[08:51] <whsieh> sanketj_: q for Safari/FF: is there a world where FF decides to delay rendering for a little while, and then underlay the formats and request the data
[08:52] <whsieh> sanketj_: in this scheme, there's no guaranteed way to FP the user
[08:52] <whsieh> sanketj_: balancing act between privacy and performance
[08:54] <whsieh> johanneswilm: moving on to https://github.com/w3c/edit-context/issues/81
[08:55] <whsieh> dandclark: it's annoying that authors need to track selection directionality in order to implement correct selection behaviors
[08:55] <whsieh> johanneswilm: resolution: allow backwards selection
[08:56] <whsieh> next: https://github.com/w3c/edit-context/issues/75
[08:57] <whsieh> dandclark: as the spec is written now, if you have an EC that's being composed in and you disconnect it, we fire compositionend on the disembodied EC
[08:57] <whsieh> proposal: reverse these steps so that we fire compositionEnd *before* the EC is disconnected
[08:57] <whsieh> q+
[08:58] <whsieh> whsieh: would this allow script to reconnect an EC in the middle of disconnecting?
[08:59] <whsieh> dandclark: should make sure this edge case is not ambiguous
[08:59] <whsieh> sanketj_: do any of the known users of EC use compositionEnd
[09:00] <whsieh> dandclark: Google Docs, maybe?
[09:00] <whsieh> johanneswilm: follow masayuki's proposal, check edge case of reentrant EC reconnect