IRC log of editing on 2022-05-12

Timestamps are in UTC.

14:59:37 [RRSAgent]
RRSAgent has joined #editing
14:59:37 [RRSAgent]
logging to https://www.w3.org/2022/05/12-editing-irc
15:00:03 [Travis]
meeting: Editing WG Meeting - May 12, 2022
15:00:06 [Travis]
present+
15:00:12 [comandeer]
present+
15:00:22 [Travis]
chair: johanneswilm
15:00:33 [Travis]
scribe: Travis
15:00:41 [Travis]
scribeNick: Travis
15:01:37 [BoCupp]
present+
15:02:09 [johanneswilm]
johanneswilm has joined #editing
15:02:11 [Travis]
Topic: Henri's issue
15:02:12 [whsieh]
present+
15:02:41 [Travis]
github: https://github.com/w3c/clipboard-apis/issues/173
15:03:11 [Travis]
henri: w/contenteditable, user expects that space bar produces a visible space.
15:03:32 [Travis]
.. originally, there was no CSS for whitespace: pre ?
15:03:43 [Travis]
.. (because of whitespace collapsing)
15:04:07 [Travis]
.. clipboard adds alternating spacing + non-breaking spaces
15:04:25 [Travis]
.. when browser maps all nbsp to regular space.
15:04:58 [Travis]
.. (number)nbsp(unit) these can sometimes be replaces.
15:05:16 [Travis]
.. conclusion: impossible to copy from the web that retains nbsp's.
15:05:26 [Travis]
.. contemplating change in Gecko to...
15:06:22 [Travis]
.. when nbsp isn't adjacent to a regular space (both ends touch something other than a space--since those aren't created by editor as a hack), then LEAVE THEM BE.
15:06:40 [Travis]
.. This is an area that is not really part of web interop concerns...
15:07:08 [Travis]
.. compat/interop concern is from copy-then-paste all within the web platform.
15:07:28 [Travis]
.. Q to other vendors: any concerns with this plan?
15:07:35 [Travis]
.. can you see interop problems with this?
15:08:00 [Travis]
.. (except a divergence between the three engines doing the same thing in this case)
15:08:32 [AlexK]
AlexK has joined #editing
15:08:46 [Travis]
BoCupp: Not sure I follow what all the browsers are doing...
15:09:10 [Travis]
.. Do all browsers just put the copy of the spaces when copying...
15:09:32 [Travis]
henri: when copying from plaintext (no HTML involved); blink preserves nbsp,
15:09:37 [Travis]
.. Gecko does not.
15:10:19 [Travis]
.. when pasting into plaintext, all engines currently replace the nbsp. Gecko wants to diverge from this.
15:10:35 [Travis]
BoCupp: which scenario are we optimizing for?
15:11:01 [Travis]
henri: when HTML contains a nbsp for legitimate typographical reasons (keep units together with number, french quotes, etc.)
15:11:15 [Travis]
.. anything except faking the collapsing of space by the editor.
15:11:40 [Travis]
.. hypothesis: all other cases are legitimate uses of nbsp and should be preserved when exporting to clipboard.
15:11:49 [Travis]
.. so we don't want to mess with those.
15:12:06 [Travis]
johanneswilm: do you think you can detect all the case when the editor does the fixup?
15:12:47 [Travis]
henri: if there is a sequence of nbsp has either an ascii space before/after, then we would consider that editor-generated.
15:12:58 [Travis]
.. everything else would be considered a legitimate.
15:13:32 [Travis]
.. I haven't done the research to see if editors expect that behavior... my experience is that existing web logic expects the current editing behavior.
15:13:51 [Travis]
whsieh: q: idea is to preserve nbsp in dataTransfer.data or paste to plaintext and readback?
15:14:13 [Travis]
henri: idea is to preserve nbsp when exporting to native clipboard flavor; the rest of the behavior would flow from that.
15:14:31 [Travis]
.. if an app paste to plaintext, then it would be affected.
15:14:53 [Travis]
.. a little handwavy to understand the other subtle places where this might impact.
15:15:12 [Travis]
whsieh: I wonder if there would be compat with apps (external to browser).
15:15:57 [Travis]
henri: the case with a textarea in webkit, with no spaces, then the copy inserts the nbsp places... if that breaks apps then it would be an existing concern.
15:16:08 [Travis]
whsieh: it would be broadening the concern if it was there.
15:16:47 [Travis]
Travis: sounds like the consensus of the group is to "give it a try" and report back?
15:16:56 [Travis]
.. didn't hear any objections (just questions)?
15:17:25 [Travis]
johanneswilm: is this something we want to put in the spec? Or are we just OK with the interop divergence.
15:17:58 [Travis]
henri: I'm not asking for inclusion in a spec (this is borderline not part of standards).
15:18:38 [Travis]
BoCupp: I like the suggestion (it makes sense to me). When you do it and have success, I think it would be great if we could write it down.
15:18:51 [Travis]
.. contenteditable spec has a section we could put this into...
15:18:54 [whsieh]
q+
15:18:58 [Travis]
johanneswilm: execcommand?
15:19:06 [Travis]
BoCupp: ..looking for a link.
15:19:33 [Travis]
johanneswilm: For now, henri should try it out and report back on the issue.
15:20:05 [Travis]
.. like seeing the algorithm for determining the space handling that henri is going to try.
15:20:15 [Travis]
.. other browsers may want to then try it out.
15:21:02 [Travis]
BoCupp: can you comment on which issue (mentioned in the github issue) ...
15:21:31 [Travis]
henri: I think the scenario is copying from the web, then pasting into plaintext textarea--demonstrating how it's relevant to web interop.
15:21:57 [whsieh]
q-
15:22:10 [Travis]
BoCupp: These would be changes to the serialization to the clipboard?
15:22:32 [Travis]
henri: not sure. I was thinking of the action when a range in the DOM is exported to clipboard (HTML) on copy.
15:23:09 [Travis]
.. to the extent there are ways to trigger the export (other than users pressing Ctrl+C), would assume they would got through the same code path. If not, then that's an additional complication.
15:23:18 [Travis]
BoCupp: Suspect that they don't go through the same codepath.
15:23:34 [Travis]
.. some cases you walk the DOM, in other cases, you're just given some text to insert.
15:23:46 [Travis]
henri: Okay.
15:23:55 [Travis]
BoCupp: Like the idea of you experimenting with it!
15:24:11 [Travis]
johanneswilm: and if it DOESN'T work, we'd appreciate knowing!
15:24:41 [Travis]
topic: Remove cliboard-write permission
15:24:46 [Travis]
github: https://github.com/w3c/clipboard-apis/pull/164
15:25:00 [Travis]
johanneswilm: this is blocked...
15:25:41 [Travis]
.. action last time--BoCup will communicate...
15:25:49 [Travis]
BoCupp: Hmm, haven't reached out to them yet.
15:25:59 [Travis]
.. (it's coming back to me now)
15:26:58 [Travis]
topic: Don't recommend user gesture in clipboard API
15:27:04 [Travis]
github: https://github.com/w3c/clipboard-apis/issues/75
15:27:24 [Travis]
johanneswilm: last time the action was whsieh will check user-activation spec and propose number of seconds.
15:27:32 [Travis]
.. and BoCupp said 1s seems reasonable.
15:27:45 [Travis]
whsieh: I haven't yet decided on a specific value of seconds... :(
15:28:07 [Travis]
.. I think we should just start with 1s and increase if needed.
15:28:25 [Travis]
BoCupp: refresher: why the number of seconds? (Can't remember the details)
15:28:51 [Travis]
.. when writing to clipboard you can write immediately. Waiting on the network, etc., isn't a problem except for the timing of performing the write call.
15:29:10 [Travis]
whsieh: in this case the requestor doesn't know whether they want to call clipboard write during the user gesture.
15:29:26 [Travis]
johanneswilm: e.g., in remote desktop they don't know if anything's on the clipboard.
15:29:39 [Travis]
.. do I hear correctly that 1s is the recommendation?
15:30:01 [Travis]
whsieh: I think we should start more conservatively. Chrome/Firefox time is currently 5s.
15:30:22 [Travis]
.. Webkit's user activation time is 1s everywhere else. This would match everything else.
15:30:43 [Travis]
.. then eventually we could move everything to match other browser (user-activation time delay to perhaps 5s)
15:30:56 [Travis]
.. right now there is no delay--it has to be during the event handler.
15:31:06 [Travis]
BoCupp: Even in navigator.clipboard.write?
15:31:12 [Travis]
whsieh: yes, in webkit.
15:31:27 [Travis]
.. like touchstart--other things we consider user activation.
15:31:54 [Travis]
.. it has to be synchronously as part of the user gesture (no async stuff)
15:32:35 [Travis]
johanneswilm: So, 1s? Will other browsers change?
15:33:12 [Travis]
BoCupp: I feel like (no number of seconds) will ever be enough for some of these scenarios.
15:33:20 [Travis]
johanneswilm: should there be a minimum?
15:33:45 [Travis]
.. e.g., in firefox it's 5s? But other browsers have faster times (500ms), then it will break everywhere else.
15:33:57 [Travis]
.. but if it's written down as 1s, then there's an expectation set.
15:34:55 [Travis]
BoCupp: I'm not inclinded to write the 1s (or other time) anywhere. Would rather provide affordances for delaying rather than just changing the number of seconds for this [edge case].
15:35:12 [Travis]
.. 5s seems like a really long time for a user-gesture...
15:35:55 [Travis]
BoCupp: Would like to say in the issue--not likely to change this. There's no guarantee that this will solve all use cases...
15:36:51 [Travis]
.. wondering if this is the kind of issue we don't need to put in the spec.
15:37:21 [Travis]
whsieh: having some delay (in WebKit) would help, since there's currently no delay.
15:37:38 [Travis]
johanneswilm: So, we don't want to specify any value, but should just say some amount of time?
15:37:57 [Travis]
BoCupp: If we did say it, we wouldn't put it in our spec... should probably go to user-activation spec?
15:38:14 [Travis]
.. increasing the seconds to solve this problem isn't really solving the problem.
15:38:36 [Travis]
.. I do like having a consideration for introducing an async delay.
15:39:20 [Travis]
.. I like the idea of having whsieh post to the issue and indicate they may take some action...
15:39:55 [Travis]
action: whsieh to post to the issue and indicate a plan to make an adjustment to support async delay of some sort to handle this scenario.
15:40:28 [Travis]
topic: clarifying pickling design
15:40:36 [Travis]
github: https://github.com/w3c/editing/issues/393
15:40:50 [Travis]
johanneswilm: (reviewing where we are...)
15:41:02 [Travis]
.. related to 100 custom format limit?
15:41:06 [Travis]
.. anything new on this issue?
15:41:10 [Travis]
.. or can we close it now?
15:42:04 [Travis]
BoCupp: I see a new question we haven't responded to..
15:42:16 [Travis]
.. maybe take off the Agenda label and continue discussing async.
15:42:22 [Travis]
johanneswilm: Bo will you answer?
15:42:36 [Travis]
BoCupp: snianu is on it.
15:43:10 [Travis]
.. OK to let the discussion continue. will bring back to the group if we need to talk about it here (if it needs consensus)
15:43:47 [Travis]
topic: Concern for screen reader users
15:43:53 [Travis]
github: https://github.com/w3c/virtual-keyboard/issues/15
15:44:17 [Travis]
johanneswilm: Is there an action for the group to discuss?
15:44:34 [Travis]
BoCupp: haven't had cycles to review this recently.
15:45:35 [Travis]
johanneswilm: reviewed the charter... (checking on timeline for standardization)
15:52:49 [Travis]
BoCupp: We plan to circle back on this in a bit, but haven't had a chance to look at it recently.
15:53:15 [Travis]
topic: Touch on the interop issue that whsieh raised?
15:54:27 [Travis]
BoCupp: could be issue https://github.com/w3c/editing/issues/396
15:54:28 [Travis]
.. ?
15:55:40 [Travis]
.. see also https://github.com/web-platform-tests/interop-2022-editing/issues/1
15:55:51 [BoCupp]
https://github.com/web-platform-tests/interop-2022/issues/77
15:57:53 [Travis]
BoCupp: might have been suggested that contenteditable be an area of focus? I don't think we were having that be a focus...
15:58:02 [Travis]
.. my current focus is EditContext and clipboard.
15:58:43 [Travis]
.. other interop problems around input events--I think are more important than contenteditable.
15:59:00 [Travis]
.. where/who to talk to if we want this on their agenda?
15:59:11 [Travis]
.. do these areas resonate with folks?
15:59:32 [Travis]
whsieh: Also want to note (e.g., composition events) are problematic.
15:59:51 [Travis]
.. might need to change the test harness to simulate these. It's a sizable efforts that shouldn't be lost.
15:59:55 [Travis]
BoCupp: Glad you mentioned that.
16:00:20 [Travis]
.. we had an intern that extneded the CDP in playright to support simulating OS input for composition. Didn't extend WebDriver yet.
16:00:35 [Travis]
.. I agree that's a big area that should be invested in.
16:01:01 [Travis]
.. there is some remaining work on our side to make this work for WPT.
16:01:21 [Travis]
.. We thought it would be useful to be able to create test cases for EditContext.
16:02:10 [Travis]
https://github.com/web-platform-tests/interop-2022-editing/issues/1
16:04:08 [Travis]
BoCupp: I think the focus on supplementing the testing infra is a good priority.
16:05:29 [Travis]
.. happy to show up and represent Editing WG with our collective position.
16:05:56 [Travis]
zakim, end the meeting
16:05:56 [Zakim]
As of this point the attendees have been Travis, comandeer, BoCupp, whsieh
16:05:59 [Zakim]
RRSAgent, please draft minutes v2
16:05:59 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/05/12-editing-minutes.html Zakim
16:06:02 [Zakim]
I am happy to have been of service, Travis; please remember to excuse RRSAgent. Goodbye
16:06:06 [Zakim]
Zakim has left #editing
16:06:12 [Travis]
rrsagent, make logs public
16:09:29 [Travis]
RRSAgent, bye
16:09:29 [RRSAgent]
I see 1 open action item saved in https://www.w3.org/2022/05/12-editing-actions.rdf :
16:09:29 [RRSAgent]
ACTION: whsieh to post to the issue and indicate a plan to make an adjustment to support async delay of some sort to handle this scenario. [1]
16:09:29 [RRSAgent]
recorded in https://www.w3.org/2022/05/12-editing-irc#T15-39-55