Editing WG Meeting - May 12, 2022

12 May 2022


BoCupp, comandeer, Travis, whsieh

Meeting minutes

Henri's issue

github: https://github.com/w3c/clipboard-apis/issues/173

henri: w/contenteditable, user expects that space bar produces a visible space.
… originally, there was no CSS for whitespace: pre ?
… (because of whitespace collapsing)
… clipboard adds alternating spacing + non-breaking spaces
… when browser maps all nbsp to regular space.
… (number)nbsp(unit) these can sometimes be replaces.
… conclusion: impossible to copy from the web that retains nbsp's.
… contemplating change in Gecko to...
… 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.
… This is an area that is not really part of web interop concerns...
… compat/interop concern is from copy-then-paste all within the web platform.
… Q to other vendors: any concerns with this plan?
… can you see interop problems with this?
… (except a divergence between the three engines doing the same thing in this case)

BoCupp: Not sure I follow what all the browsers are doing...
… Do all browsers just put the copy of the spaces when copying...

henri: when copying from plaintext (no HTML involved); blink preserves nbsp,
… Gecko does not.
… when pasting into plaintext, all engines currently replace the nbsp. Gecko wants to diverge from this.

BoCupp: which scenario are we optimizing for?

henri: when HTML contains a nbsp for legitimate typographical reasons (keep units together with number, french quotes, etc.)
… anything except faking the collapsing of space by the editor.
… hypothesis: all other cases are legitimate uses of nbsp and should be preserved when exporting to clipboard.
… so we don't want to mess with those.

johanneswilm: do you think you can detect all the case when the editor does the fixup?

henri: if there is a sequence of nbsp has either an ascii space before/after, then we would consider that editor-generated.
… everything else would be considered a legitimate.
… 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.

whsieh: q: idea is to preserve nbsp in dataTransfer.data or paste to plaintext and readback?

henri: idea is to preserve nbsp when exporting to native clipboard flavor; the rest of the behavior would flow from that.
… if an app paste to plaintext, then it would be affected.
… a little handwavy to understand the other subtle places where this might impact.

whsieh: I wonder if there would be compat with apps (external to browser).

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.

whsieh: it would be broadening the concern if it was there.

Travis: sounds like the consensus of the group is to "give it a try" and report back?
… didn't hear any objections (just questions)?

johanneswilm: is this something we want to put in the spec? Or are we just OK with the interop divergence.

henri: I'm not asking for inclusion in a spec (this is borderline not part of standards).

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.
… contenteditable spec has a section we could put this into...

johanneswilm: execcommand?

BoCupp: ..looking for a link.

johanneswilm: For now, henri should try it out and report back on the issue.
… like seeing the algorithm for determining the space handling that henri is going to try.
… other browsers may want to then try it out.

BoCupp: can you comment on which issue (mentioned in the github issue) ...

henri: I think the scenario is copying from the web, then pasting into plaintext textarea--demonstrating how it's relevant to web interop.

BoCupp: These would be changes to the serialization to the clipboard?

henri: not sure. I was thinking of the action when a range in the DOM is exported to clipboard (HTML) on copy.
… 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.

BoCupp: Suspect that they don't go through the same codepath.
… some cases you walk the DOM, in other cases, you're just given some text to insert.

henri: Okay.

BoCupp: Like the idea of you experimenting with it!

johanneswilm: and if it DOESN'T work, we'd appreciate knowing!

Remove cliboard-write permission

github: https://github.com/w3c/clipboard-apis/pull/164

johanneswilm: this is blocked...
… action last time--BoCup will communicate...

BoCupp: Hmm, haven't reached out to them yet.
… (it's coming back to me now)

Don't recommend user gesture in clipboard API

github: https://github.com/w3c/clipboard-apis/issues/75

johanneswilm: last time the action was whsieh will check user-activation spec and propose number of seconds.
… and BoCupp said 1s seems reasonable.

whsieh: I haven't yet decided on a specific value of seconds... :(
… I think we should just start with 1s and increase if needed.

BoCupp: refresher: why the number of seconds? (Can't remember the details)
… 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.

whsieh: in this case the requestor doesn't know whether they want to call clipboard write during the user gesture.

johanneswilm: e.g., in remote desktop they don't know if anything's on the clipboard.
… do I hear correctly that 1s is the recommendation?

whsieh: I think we should start more conservatively. Chrome/Firefox time is currently 5s.
… Webkit's user activation time is 1s everywhere else. This would match everything else.
… then eventually we could move everything to match other browser (user-activation time delay to perhaps 5s)
… right now there is no delay--it has to be during the event handler.

BoCupp: Even in navigator.clipboard.write?

whsieh: yes, in webkit.
… like touchstart--other things we consider user activation.
… it has to be synchronously as part of the user gesture (no async stuff)

johanneswilm: So, 1s? Will other browsers change?

BoCupp: I feel like (no number of seconds) will ever be enough for some of these scenarios.

johanneswilm: should there be a minimum?
… e.g., in firefox it's 5s? But other browsers have faster times (500ms), then it will break everywhere else.
… but if it's written down as 1s, then there's an expectation set.

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].
… 5s seems like a really long time for a user-gesture...

BoCupp: Would like to say in the issue--not likely to change this. There's no guarantee that this will solve all use cases...
… wondering if this is the kind of issue we don't need to put in the spec.

whsieh: having some delay (in WebKit) would help, since there's currently no delay.

johanneswilm: So, we don't want to specify any value, but should just say some amount of time?

BoCupp: If we did say it, we wouldn't put it in our spec... should probably go to user-activation spec?
… increasing the seconds to solve this problem isn't really solving the problem.
… I do like having a consideration for introducing an async delay.
… I like the idea of having whsieh post to the issue and indicate they may take some action...

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.

clarifying pickling design

github: https://github.com/w3c/editing/issues/393

johanneswilm: (reviewing where we are...)
… related to 100 custom format limit?
… anything new on this issue?
… or can we close it now?

BoCupp: I see a new question we haven't responded to..
… maybe take off the Agenda label and continue discussing async.

johanneswilm: Bo will you answer?

BoCupp: snianu is on it.
… OK to let the discussion continue. will bring back to the group if we need to talk about it here (if it needs consensus)

Concern for screen reader users

github: https://github.com/w3c/virtual-keyboard/issues/15

johanneswilm: Is there an action for the group to discuss?

BoCupp: haven't had cycles to review this recently.

johanneswilm: reviewed the charter... (checking on timeline for standardization)

BoCupp: We plan to circle back on this in a bit, but haven't had a chance to look at it recently.

Touch on the interop issue that whsieh raised?

BoCupp: could be issue https://github.com/w3c/editing/issues/396
… ?
… see also https://github.com/web-platform-tests/interop-2022-editing/issues/1

<BoCupp> https://github.com/web-platform-tests/interop-2022/issues/77

BoCupp: might have been suggested that contenteditable be an area of focus? I don't think we were having that be a focus...
… my current focus is EditContext and clipboard.
… other interop problems around input events--I think are more important than contenteditable.
… where/who to talk to if we want this on their agenda?
… do these areas resonate with folks?

whsieh: Also want to note (e.g., composition events) are problematic.
… might need to change the test harness to simulate these. It's a sizable efforts that shouldn't be lost.

BoCupp: Glad you mentioned that.
… we had an intern that extneded the CDP in playright to support simulating OS input for composition. Didn't extend WebDriver yet.
… I agree that's a big area that should be invested in.
… there is some remaining work on our side to make this work for WPT.
… We thought it would be useful to be able to create test cases for EditContext.


BoCupp: I think the focus on supplementing the testing infra is a good priority.
… happy to show up and represent Editing WG with our collective position.

Summary of action items

  1. 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.
Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).


Maybe present: henri, johanneswilm