Re: [w3c/clipboard-apis] Replacing no-break spaces when converting HTML to plain text upon clipboard export (Issue #173)

The Web Editing Working Group just discussed `Henri's issue`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Travis> Topic: Henri's issue<br>
&lt;Travis> github: https://github.com/w3c/clipboard-apis/issues/173<br>
&lt;Travis> henri: w/contenteditable, user expects that space bar produces a visible space.<br>
&lt;Travis> .. originally, there was no CSS for whitespace: pre ?<br>
&lt;Travis> .. (because of whitespace collapsing)<br>
&lt;Travis> .. clipboard adds alternating spacing + non-breaking spaces<br>
&lt;Travis> .. when browser maps all nbsp to regular space.<br>
&lt;Travis> .. (number)nbsp(unit) these can sometimes be replaces.<br>
&lt;Travis> .. conclusion: impossible to copy from the web that retains nbsp's.<br>
&lt;Travis> .. contemplating change in Gecko to...<br>
&lt;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.<br>
&lt;Travis> .. This is an area that is not really part of web interop concerns...<br>
&lt;Travis> .. compat/interop concern is from copy-then-paste all within the web platform.<br>
&lt;Travis> .. Q to other vendors: any concerns with this plan?<br>
&lt;Travis> .. can you see interop problems with this?<br>
&lt;Travis> .. (except a divergence between the three engines doing the same thing in this case)<br>
&lt;Travis> BoCupp: Not sure I follow what all the browsers are doing...<br>
&lt;Travis> .. Do all browsers just put the copy of the spaces when copying...<br>
&lt;Travis> henri: when copying from plaintext (no HTML involved); blink preserves nbsp,<br>
&lt;Travis> .. Gecko does not.<br>
&lt;Travis> .. when pasting into plaintext, all engines currently replace the nbsp. Gecko wants to diverge from this.<br>
&lt;Travis> BoCupp: which scenario are we optimizing for?<br>
&lt;Travis> henri: when HTML contains a nbsp for legitimate typographical reasons (keep units together with number, french quotes, etc.)<br>
&lt;Travis> .. anything except faking the collapsing of space by the editor.<br>
&lt;Travis> .. hypothesis: all other cases are legitimate uses of nbsp and should be preserved when exporting to clipboard.<br>
&lt;Travis> .. so we don't want to mess with those.<br>
&lt;Travis> johanneswilm: do you think you can detect all the case when the editor does the fixup?<br>
&lt;Travis> henri: if there is a sequence of nbsp has either an ascii space before/after, then we would consider that editor-generated.<br>
&lt;Travis> .. everything else would be considered a legitimate.<br>
&lt;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.<br>
&lt;Travis> whsieh: q: idea is to preserve nbsp in dataTransfer.data or paste to plaintext and readback?<br>
&lt;Travis> henri: idea is to preserve nbsp when exporting to native clipboard flavor; the rest of the behavior would flow from that.<br>
&lt;Travis> .. if an app paste to plaintext, then it would be affected.<br>
&lt;Travis> .. a little handwavy to understand the other subtle places where this might impact.<br>
&lt;Travis> whsieh: I wonder if there would be compat with apps (external to browser).<br>
&lt;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.<br>
&lt;Travis> whsieh: it would be broadening the concern if it was there.<br>
&lt;Travis> Travis: sounds like the consensus of the group is to "give it a try" and report back?<br>
&lt;Travis> .. didn't hear any objections (just questions)?<br>
&lt;Travis> johanneswilm: is this something we want to put in the spec? Or are we just OK with the interop divergence.<br>
&lt;Travis> henri: I'm not asking for inclusion in a spec (this is borderline not part of standards).<br>
&lt;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.<br>
&lt;Travis> .. contenteditable spec has a section we could put this into...<br>
&lt;whsieh> q+<br>
&lt;Travis> johanneswilm: execcommand?<br>
&lt;Travis> BoCupp: ..looking for a link.<br>
&lt;Travis> johanneswilm: For now, henri should try it out and report back on the issue.<br>
&lt;Travis> .. like seeing the algorithm for determining the space handling that henri is going to try.<br>
&lt;Travis> .. other browsers may want to then try it out.<br>
&lt;Travis> BoCupp: can you comment on which issue (mentioned in the github issue) ...<br>
&lt;Travis> henri: I think the scenario is copying from the web, then pasting into plaintext textarea--demonstrating how it's relevant to web interop.<br>
&lt;whsieh> q-<br>
&lt;Travis> BoCupp: These would be changes to the serialization to the clipboard?<br>
&lt;Travis> henri: not sure. I was thinking of the action when a range in the DOM is exported to clipboard (HTML) on copy.<br>
&lt;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.<br>
&lt;Travis> BoCupp: Suspect that they don't go through the same codepath.<br>
&lt;Travis> .. some cases you walk the DOM, in other cases, you're just given some text to insert.<br>
&lt;Travis> henri: Okay.<br>
&lt;Travis> BoCupp: Like the idea of you experimenting with it!<br>
&lt;Travis> johanneswilm: and if it DOESN'T work, we'd appreciate knowing!<br>
</details>


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/173#issuecomment-1125130700
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issues/173/1125130700@github.com>