- From: Johannes Wilm <johannes@fiduswriter.org>
- Date: Tue, 25 Oct 2016 15:58:38 +0200
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style list <www-style@w3.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
- Message-ID: <CABkgm-Tt=ERVTMU_ukqRr1-2h2DNL3=mewHc9jO6XGVMCmpWjQ@mail.gmail.com>
Hey, as promised, I did a little survey among some of the main JS based editors that exist as of today and how they look at plaintext on the clipboard when an HTML version is available. I only contacted the main ones that have been responsive in the past this time, and I left out those maintained by browser makers, as I assume that others on the list have a more direct line of communication with them. I had conversations with each of the editor developers on their usage of the plaintext clipboard contents when handling paste and what they think about the application about text transform on the part of the browser for both plaintext and html. Some of the answers/discussions that resulted from my initial questions were much longer than what I summarize below, and some of the developers may decide that they want to respond with more detail themselves here. In brief, the answers were as follows: 1. Usage of the plaintext version of the clipboard contents: CKEditor: Makes use of the plaintext version when there is no HTML-version. In those cases it attempts to create a pseudo-HTML version based on the plaintext version. When there is an HTML-version, it uses that instead,. If it needs a plaintext version and there is an HTML-version available, it creates its own plaintext version based on the HTMl version. ProseMirror: Uses the plaintext version if the user hits Shift + paste-shortcut. QuillJS: Is not directly using either plaintext or html version "because of inconsistencies across browsers. For example copying from IE11 and pasting into Chrome will include the entire document markup including <head> and <style> tags and in some cases <script> tags". Paste is handled by moving the caret into an offscreen contenteditable element and then cleaning up whatever ends up in there. Substance.io: Uses the plaintext version as a backup, if they cannot figure out what's supposed to be in the HTML-version. TinyMCE: Makes use of the plaintext version when plaintext is needed. 2. Ideas about application of text-transform in plaintext: CKEditor: -- Doesn't apply -- ProseMirror: "transforming text before putting it on the clipboard is probably a bad idea" QuillJS: "[...] it should not transform. There should be a separation between data and presentation [...] . Trying to be helpful by changing the data breaks this paradigm because now the data is wrong. This also leads down a deep dark rabbit hole. Should you put '-' in front of list elements? What if CSS and inline styles changes or hides list-style? This in my view is a classic example of trying to be too helpful." Substance.io: Applying the transformation seems consistent with the HTML version. TinyMCE: "the data put on the clipboard should be available though the clipboard API as raw as it can be some security filtering needs to exist. So if I copy content from a browser it should basically be innerHTML and innerText of the fragment being copied. Then on paste it should do no fancy stuff at all just provide what ever is in the plain text and html mime types as raw data." 3. Ideas about application of text-transform in html (see https://jsfiddle.net/johanneswilm/b054qzts/2/ in Chrome ) CKEditor: Problematic. "We'd like the HTML to stay as it was on copy. We've been complaining a lot about the spans which Chrome adds, because it's hard to understand which of them should be filtered out. Applying text transformation is even bigger problem, cause then we have no clue about the original case." ProseMirror: -- same as plaintext -- QuillJS: -- same as plaintext -- Substance.io: "If you use the Clipboard HTML between applications, you have to accept some losses. I would prefer to express as much as possible with simple HTML and only to put unimportant stuff into styles, just as a hint for the other [receiving] app. [...] It's a technical, internal detail how an app/website arrives at its capital letters." (my translation) TinyMCE: as plaintext + "[...] you want to distinct between style that was in the page and styles that was computed and added by the browser. In this case: <style> .bgRed { background: red; } </style> [<p style="color: red" class="bgRed">abc</p>] The contents on the clipboard on some browsers would be in Chrome for example: <p style="color: red; background red;">abc</p> So there is no way for us to know that supposed to be in there or not. What they could do is to generate classes so the clipboard would be: <style> .bgRed { background: red; } </style> <p style="color: red" class="bgRed">abc</p> This way it would be up to the implementer to get rid of the bgRed and style element or compute the runtime styles." -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Received on Tuesday, 25 October 2016 13:59:11 UTC