[css-text] behavior of copy/paste with text-transform

[dauwhe]

This is issue 108 in the disposition of comments. There's a www-style thread. Flattened version here.

There are several browser bugs:

Webkit: https://bugs.webkit.org/show_bug.cgi?id=43202
Webkit: https://bugs.webkit.org/show_bug.cgi?id=3429
Mozilla : https://bugzilla.mozilla.org/show_bug.cgi?id=35148

Consensus has eluded us over at least sixteen years. On the call yesterday, we decided to gather more information from the larger community on what to do.

[Crissov]

If we’re serious about the separation of content and style, text-transform should have no effect on the characters, i.e. code points, copied. They may be changed permanently when pasted if the target environment does only support plain text. If it works this makes no difference for users.
text-transform performs glyph changes in a script-specific way, font-variant and its sub-properties perform glyph changes in a font-specific way – they’re not different regarding user expectations.

The same is true, however, for content, display and visibility properties.

[frivoal]

I don't think it is so much about the separation of content and style, as it about the fact that you cannot preserve style separately from content when going plain text, and therefore having to make compromises. Since they are compromises, it is expected that there will be some tension between various desirable goals: discard as little information/semantics as possible, don't surprise the user, provide the most useful behavior... A general principle is to make the output look similar to the input to avoid surprises and confusion. This suggests that taking the display, list-style, visibility, content, or white-space properties is better.

On the other hand, breaking away from that generic principle can be justified by looking in to specific scenarios where a property is used, and see if in practice, it is more useful to discard the property than to preserve it. This is the argument that is being made against text-transform.

• p::first-line { text-transform: uppercase } preserving the transform here would look really weird when pasting into a window which is most likely a different size. not preserving is better
• abbr { text-transform: lowercase; font-variant: small-caps;} the font-variant cannot be preserved, so preserving the text-transform would mean getting lower-case acronyms, which is certainly not something you want. not preserving is better
• tr {font-size: small; text-transform: full-size-kana;} small kana are sometimes transformed into full size kana in japanese ruby when set at a small font size, to help with legibility at the expense of accuracy, turing しゃ (sha) into しや (shiya). If the text transform is preserved when the the layout is not, this will give incorrect pronounciation for no good reason. not preserving is better
• <h1>Breaking News: Cheese is Actually Made of Milk</h1> h1 {text-transform: uppercase; ... } The uppercasing is part of a set of stylistic choices to put emphasis on the title, the rest of which (font choice, font size, boldness...) get discarded. The user of the pasted text may want to style it the same way, but they may just as well want a different style. Text transform is a lossy transformation, and applying it discards the original casing. While the user could easily put everything back in uppercase if they wanted to, the opposite transformation cannot be done automatically. Some have argued that was outweighed by users who want to preserve the title's original style being surprised when it is not. arguments go both ways
• em {font-style: normal; text-transform: uppercase There is a semantic loss if the transform is not preserved. But that loss happens as well if emphasis was styled some other way, and preserving the transform causes another semantic loss, since the original casing cannot be restored from the all caps text. arguments go both ways

Unless more use cases are found that sway the argument the other way, it seems to me that the conclusion should either be "up the the UA" or "don't preserve text-transform". There are some cases where some users would prefer for it to be preserved, so leaving it up to the UA may be reasonable, but in most cases, the opposite is true, so if we're going to specify the behavior one way, it should be in favor of not preserving.

Polling of the CSSWG showed a roughly even split between these two options, with browsers representative mostly preferring "up to the UA", and others mostly prefering "don't preserve".

[Crissov]

My point was that CSS UAs should not mess with characters upon sending something to the OS clipboard, because the receiving end may well be capable of handling all the style information originally expressed in CSS and its user may want to deactivate or change some of it and since the effects of text-transform do not round-trip, a hard character conversion would result in irreversible information loss which is not in the user’s best interest.

It’s out of scope of CSS what the OS does to copied styled text. It’s also out of scope of CSS what applications that receive the clip from the OS do to the text prior to pasting it in. Basically the same applies if the sending and receiving apps communicate directly with each other – and the C&P operation can of course also happen within a single piece of software.

Browsers, however, have to deal with pasting styled content into both, plain and rich text environments. They may employ custom styled-to-rich-text methods and that is where <em style="text-transform: uppercase">MacDonald</em> copied from the web page displayed gets transformed into MACDONALD when pasted into a <input type="text">, but it would be inserted unchanged into some contenteditable node.

[frivoal]

We were not discussing what happens to copy-pasting as rich text, but copy-pasting as plain text.

[Crissov]

Perhaps I don’t know how system clipboards actually work, but the UX issue faced here is only in pasting! It should have nothing to do with copying, no matter whether rich text or plain text. A browser should copy styled text verbatim (without character transformations) and the OS or the receiving application can then apply some irreversible changes if they know how and that users expectat this. CSS is the wrong place to “fix” it.

I’m trying to show that your “arguments go both ways” bullet points are actually also “not preserving is better”.

[kojiishi]

I collected issues we're aware of, from http://crbug.com and our user forum. Given the @gregwhitworth request, this list isn't limited to text-transform.

1. Most of feedback are about preserving format in the way users expect when copy/pasting formatted text, either from browser or to browser.
2. There are cases where we don't handle spaces (collapse too much or to little) and new lines (fail to generate new lines for end of blocks) in the way users expect. One example is crbug.com/318925.
3. There are cases where selecting linked text is hard or impossible. One example is crbug.com/446391.

The text-transform didn't come up in either places.

[SebastianZ]

On 23 October 2016 at 20:34, Christoph Päper notifications@github.com
wrote:

Perhaps I don’t know how system clipboards actually work, but the UX issue
faced here is only in pasting! It should have nothing to do with
copying, no matter whether rich text or plain text. A browser should copy
styled text verbatim (without character transformations) and the OS or the
receiving application can then apply some irreversible changes if they can
do so and do know user expectations better. CSS is the wrong place to “fix”
it.

As far as I know, copying works by using multiple formats for the copied
item. See
https://msdn.microsoft.com/en-us/library/windows/desktop/ms649013(v=vs.85).aspx
as an example for Windows. E.g. if you copy some text from a website, it
willl be copied as plain text and in HTML format.
Plain text means that there is no styling information attached to it. So,
the styling information needs to be attached when the text is copied. The
OS doesn't transform it on pasting.

E.g. a user may expect uppercase text to be pasted as uppercase, they
usually don't care whether the author used text-transform: uppercase; or
actually wrote the text in uppercase letters. In other cases or for other
users this may not be the case.
So, as Florian said, you have to make some compromises here and I agree
with his points "discard as little information/semantics as possible, don't
surprise the user, provide the most useful behavior". And CSS does play a
role when doing clipboard actions. E.g. if you copy a green text as a user,
you expect it to be green when pasting it into a program that allows
formatting text.

One idea came to my mind right now. What if we handled the clipboard as
some media type? This would allow the author to control whether text should
be copied transformed or not. So e.g.:

h2 {
text-transform: uppercase;
}

@media clipboard {
text-transform: none;
}

This would even allow further modifications like e.g. resizing or hiding
images when copied, or removing some styling which should only be shown
within the browser, or display some copyright information on copied text.
On the other hand, authors may then break the copy/paste UX by choosing bad
styling.

Sebastian

[frivoal]

One idea came to my mind right now. What if we handled the clipboard as some media type? This would allow the author to control whether text should be copied transformed or not.

Interesting, that's a very creative approach.

Supposedly that would only apply to plain-text clipboard, and the rich text version of the clipboard would be unaffected, since by the time you paste it it is no longer in the clipboard, right?

I don't know if I like this. I gives control to the author about what may rather be a user preference. But then again it can enable the author to tell separate some use cases (abbr {text-transform:lowercase; font-variant: small-caps;) from some others (em {font-style:normal; text-transform: uppercase;}) that that may be a good thing.

[SebastianZ]

I just saw that my previous example was wrong. It should actually have been:

h2 {
  text-transform: uppercase;
}

@media clipboard {
  h2 {
    text-transform: none;
  }
}

Supposedly that would only apply to plain-text clipboard, and the rich text version of the clipboard would be unaffected

I thought it would affect both, so the text-transform value would be part of the HTML data.
If wished, my proposal could even be extended to allow to distinguish between plain text and HTML data by supporting MIME types:

@media clipboard("text/plain") {
  h2 {
    text-transform: none;
  }
}

@media clipboard("text/html") {
  h2 {
    text-transform: none;
  }
}

While this approach allows the web author to control the styling of the clipboard data, UAs still need to provide proper defaults. And that's still the hard part.
So, Christophs argument that copied plain text should not be influenced by CSS is still valid.

Because a 'clipboard' media type is independent from this discussion, I've filed issue #648 to discuss it separately.

Sebastian

[smfr]

Having a @media clipboard makes me (as an implementor) nervous. It implies that the UA needs to do a complete style resolution/layout on Copy to get the correct data for the clipboard.

[dauwhe]

What should happen with the paragraph below? I would be very unhappy if the text-transform on :first-line were applied to the text I copy.

[css-meeting-bot]

The Working Group just discussed text-transform on copy/paste, and agreed to the following resolutions:

• RESOLVED: text-transform doesn't apply to plain text copy paste
• RESOLVED: normative state that text-transform does not apply to plain text paste.

The full IRC log of that discussion

<fantasai> Topic: text-transform on copy/paste
<fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108
<dael> github: https://github.com//issues/627
<dael> myles: I've since flip-flopped. Last time I said itext-transform should apply to copy paste, but I've changed.
<dael> fantasai: Prop: text-transform doesn't apply to plain text copy paste
<dael> fremy: There could only be manual tests.
<dael> RESOLVED: text-transform doesn't apply to plain text copy paste
<dael> fantasai: If I say :firstline text-transform: uppercase if I copy paste that to a text document.
<dael> koji: I have internal feedback that we have different behavior then spec.
<dael> fantasai: inner text or html?
<dael> koji: Don't remember.
<dael> fantasai: I think applying text-transform is seriously problematic. Because you lose information when you copy out that text.
<dael> koji: It's not my opinion. I'm trying to find what they define.
<dael> myles: Maybe look at the end.
<dael> plinss: If they're defining how text-transform works they shouldnt do that.
<myles> s/myles: Maybe look at the end.//
<dael> florian: They apply to inner text.
<dael> koji: It says [reads]
<koji> From the HTML spec: If node is a Text node, then for each CSS text box produced by node, in content order, compute the text of the box after application of the CSS 'white-space' processing rules and 'text-transform' rules
<dael> TabAtkins: inner text is not the same as inner html. inner text takes weird css already.
<dael> tantek: so it's weird legacy and don't build on it.
<dael> fantasai: There's many things wrong with that spec text. We shouldn't build on that.
<dael> astearns: Given that inner text isn't a precedent should we resolve?
<dael> koji: He wanted to object, JS editors use inner text and want to be same as copy behavior.
<dael> florian: plain text copy?
<dael> koji: They're using plain text.
<dael> astearns: I am inclined to unles syou object have us resolve in this way and let editors come back with spec bug or objection in the issue.
<dael> astearns: Is that okay?
<dael> koji: [nods]
<dael> fremy: I don't know what edge is doing but we won't change for what the spec says. I think the spec says what Edge is doing. We try very hard to work. I'm fine resolving because I'm pretty sure we match.
<dael> fantasai: Am i putting this in the spec?
<dael> astearns: I'm hearing no objections. fremy says he may keep a bug against the text.
<dael> fremy: I don't think copy/paste should be in scope of CSS. If you want it in CSS that's fine.
<dael> astearns: WE have 2 options. ! is state that text-transform doesn't effect plain copy/paste and other is be silent in spec.
<rego> it seems Edge is doing what's resolved (not applying text-transform on copy&paste) :)
<dael> koji: Thier opinion is not to define.
<dael> astearns: How about a non-normative note that we beileve it should not apply to plain text paste but we're not sure it's web compat.
<dael> fremy: We don't apply.
<dael> fantasai: This isn't an issue raised from WG and people posted to www-style unhappy that some browsers have this behavior.
<dael> koji: For chrome we have a bug saying don't apply. I believe FF has bugs saying apply.
<dael> myles: Hearing 2 things. Everyone with opinions believe same on issue. I'm also hearing we don't have juristidction to say it.
<dael> astearns: That's my non-normative note.
<dael> florian: Let's say it.
<dael> astearns: So we should say it.
<fantasai> s/to say it/to say it. So we should just say it./
<dael> tantek: We have interop.
<dael> astearns: Objections to normative stating that text-transform does not apply to plain text paste.
<dael> RESOLVED: normative state that text-transform does not apply to plain text paste.