Re: CSS and copy/pasting guidelines

On Thu, 07 Apr 2016 03:25:02 +0200, fantasai  
<fantasai.lists@inkedblade.net> wrote:

> On 04/06/2016 11:34 AM, Johannes Wilm wrote:
>>
>> Florian seemed to propose that we provide all three versions richtext  
>> and two types of plaintext.
>>
>> I am wondering if we can get away with leaving out one of the two  
>> plaintext versions.
>
> I think this is all getting quite complicated. Most users won't
> understand the difference.
>
> Pasting the source text is generally not useful.
>    * It includes uncollapsed spaces (quite confusing and annoying)
>    * It may not include necessary line breaks (to represent block
>      boundaries)
>    * It doesn't include list numbers, section numbers, and other
>      generated content (which are usually expected to show up)
>
> Imho only one plaintext output is needed. Imho it should only
> account for
>    * display type
>    * generated content
>    * white space collapsing
>    * properties (like 'display' and 'visibility') that influence
>      visibility (But if you can see it in selection, it should be
>      copied. Transparent text therefore gets copied.)

Agreed that all these things should be accounted for…

> There are two significant issue here:
>
> 1 is whether text-transform falls in the same category as white space
> collapsing (honored) or font-variant (ignored). Since
>    * text-transform is very often used to effect font variations
>      -> uppercasing is a visual effect often interchanged with
>         small-caps, for example, which are obviously not preserved
>    * there are transforms which are inherently lossy
>      -> large-kana, as Florian mentioned, is handled as a style so
>         that the base text for alternate presentations (and speech
>         output) can remain lossless, arguments which are important
>         also in copy-paste operations
> I feel very strongly that text-transform should not be considered
> for plaintext copying, even though in some cases it is arguably
> confusing to the user. For such cases, the author should probably
> be transforming the base text, and indeed that remains an option.

My strong preference as a user is for small caps to be preserved as upper  
case. It's an equivalent form of "shoutiness". But I fear this is an  
argument where we won't get the right answer without surveying the world.  
So we should ask people who are most likely to be confused and have  
difficulty fixing things for a bit of feedback, then make a decision.

> 2 is whether positioning an element either out of flow (1.1) or
> outside the scrollable area (1.2) affects whether it gets copied.
> I don't have much opinion on this one.

In my ideal world… flows should be copied as blocks. So a block of text,  
which has a second block floated out at the top, should be copied as the  
main bloc followed or proceeded by the floated block.

Likewise, tables pasted as plain text should collect cells as blocks. And  
then of course comes the magic - if they are small, I'd like the layout  
preserved with spaces, but if not I'd like them to have e.g. one line  
between cells in a row, and an extra line between rows.

But this is even less likely to be a universal desire.

> HTML copying is a bit more complicated; there are three ways to do it:
>    a) Copy exact formatting.
>    b) Copy rich text for pasting into another document
>       such that it adopts the document's style.
>    c) Copy just the HTML, without any intelligence
>
> a) is solved by copy using style attributes or equivalent techniques
> to embed the formatting into the HTML. It is sometimes what's wanted,
> but I almost always want b). (I have pasted text into MS Word *so
> many times* and needed to 100% reformat it because of this problem
> with a). I have *never* wanted the font settings of the web page to
> come with the paste.)
>
> b) is solved by inlining the styles applied to elements *within* the
> selection, but not the styles inherited from outside the selection.
> This preserves things like bolding within the text, or complex
> constructs like blockquotes and tables within the text. But it lets
> the paste context control the font family and font size, which for
> short snippets is nearly always what you want and for longer snippets
> is probably still a more useful option.

Sadly, I have about equal numbers of times when I want each of these  
options. Roughly, when I am quoting something e.g. for an article, I often  
want original formatting, whereas editing two things together I more often  
want the pasted bit to take on the style of the target document.

I'd be inclined to go with b) as a default - a) is something that seems  
reasonable to have as a "special" option.

> c) is similar to b); it is more advantageous for JS applications,
> pasting within the same application as the copy; perhaps less so
> for pasting from HTML into some external application.

I'm not sure that this is a common enough desire to be a default. The use  
case would be copying HTML into a document at a different outline level,  
and having the styling deal with that. Unfortunately about half of that  
goal is how to treat headers, and since the <section><h1> all the way down  
model only works for visual styling, with a different outline reported to  
anyone using the document's real structure - such as a screen reader - I  
don't think it's a good idea to use it.

See also https://github.com/w3c/html/issues/33 (especially for headings…)

> You really only want a) if you're trying to create a patchwork quilt
> of web page snippets, and that's a pretty rare use case and also has
> many other problems to solve as well given that CSS layout reflows
> into its container. I don't think it's a useful behavior. Between
> b) and c) I don't have a strong opinion, and leave that up to you
> experts. :)

Oh. If you'd written that at the top, I could have saved this email ;)

cheers

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Thursday, 7 April 2016 08:59:32 UTC