- From: Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>
- Date: Mon, 4 Apr 2016 13:45:32 +0200
- To: Johannes Wilm <johannes@fiduswriter.org>
- Cc: Florian Rivoal <florian@rivoal.net>, Yoshifumi Inoue <yosin@google.com>, fantasai <fantasai.lists@inkedblade.net>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
On Fri, Apr 1, 2016 at 5:30 PM, Johannes Wilm <johannes@fiduswriter.org> wrote: > So, if we are proposing three different paste versions: Well, we have two different plaintext options but need to pick one.. > - A. plaintext exactly as was > - B. plaintext with some intelligence applied Not sure exactly which one you consider "as was" in this context - the case the user sees, or the case in the source code :) > I wonder: > - How difficult (or impossible) is it to obtain the same output as A or B if > one has access to C? This should be trivial, really - at least if we assume all paste targets that understand HTML also have a basic understanding of CSS. > Would it be possible to just have either A or B > browserside and let the client calculate the other one in JS? I'm not following you here. You can certainly go from *C* to either A or B. You can *not* go from A to B or vice versa without having the formatting details preserved in C to refer to. Also, that "client" may not run JS - if you paste into an instance of a good ol' desktop word processing application for example, the input will probably be handled by compiled C(++) code, not JS. A client getting C *can* choose to derive A or B - but we certainly do not want to say the UA must *only* place HTML+CSS, not plaintext equivalent, on the clipboard in this scenario. Copying from a web page and not being able to paste into Notepad would just be weird. > - if we have both A and B, how do we decide which one to use in places that > only allow plaintext input? That's exactly the challenge we're discussing. -Hallvord R.
Received on Monday, 4 April 2016 11:46:30 UTC