W3C home > Mailing lists > Public > www-style@w3.org > October 2016

[css-text] JS editors and copying text-transform'd text (was: Re: Proposed Agenda)

From: Johannes Wilm <johannes@fiduswriter.org>
Date: Tue, 25 Oct 2016 15:58:38 +0200
Message-ID: <CABkgm-Tt=ERVTMU_ukqRr1-2h2DNL3=mewHc9jO6XGVMCmpWjQ@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 25 October 2016 13:59:13 UTC