- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 6 Apr 2016 21:25:02 -0400
- To: Johannes Wilm <johannes@fiduswriter.org>, Hallvord Reiar Michaelsen Steen <hsteen@mozilla.com>
- Cc: Florian Rivoal <florian@rivoal.net>, Yoshifumi Inoue <yosin@google.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
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.) 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. 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. 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. 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. 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. :) ~fantasai
Received on Thursday, 7 April 2016 01:25:35 UTC