W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2016

Re: [csswg-drafts] [css-text] behavior of copy/paste with text-transform

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Oct 2016 02:40:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-255279958-1477017630-sysbot+gh@w3.org>
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". 

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/627#issuecomment-255279958 
using your GitHub account
Received on Friday, 21 October 2016 02:40:39 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:04 UTC