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