Meeting minutes
Henri's issue
github: https://
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://
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://
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://
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://
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://
… ?
… see also https://
<BoCupp> https://
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.
https://
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.