Fwd: Proposed Agenda

The discussion in the call seemed to center mostly around the plaintext
version of the clipboard. I thought this didn't matter too much as one can
always just create a different plaintext version based on the richtext
version of the clipboard.

But then I looked at what browsers copy in the html version.

On Chrome/Linux 54,

  <p style="text-transform: uppercase;">This is some text.</p>

turns into

  <meta http-equiv="content-type" content="text/html; charset=utf-8"><span
style="color: rgb(0, 0, 0); font-family: &quot;Times New Roman&quot;;
font-size: medium; font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: normal; letter-spacing: normal;
orphans: 2; text-align: start; text-indent: 0px; text-transform: uppercase;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration-style: initial;
text-decoration-color: initial; display: inline !important; float:
none;">THIS IS SOME TEXT.</span>

on Chrome/Windows 53, it turns into

  <html>
<body>
<!--StartFragment--><span style="color: rgb(0, 0, 0); font-family:
&quot;Times New Roman&quot;; font-size: medium; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal; font-weight:
normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent:
0px; text-transform: uppercase; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
!important; float: none;">THIS IS SOME TEXT.</span><!--EndFragment-->
</body>
</html>

This is much more problematic, because now there is actual information
loss, and one cannot reconstruct a better plaintext version from the
richtext no matter what. Paste handlers will strip almost all of the style
information, but as some other mentioned here, there are arguments to be
made to include them. But if you include all the css styling, then it
doesn't seem to make sense to apply text-transform directly.

Firefox/Linux creates this html-copy:

  This is some text.

or

  <p style="text-transform: uppercase;">This is some text.</p>

depending on how much of the surroundings one selects.





On Tue, Oct 18, 2016 at 11:27 AM, Daniel Glazman <daniel.glazman@disruptive-
innovations.com> wrote:

> On 18/10/2016 04:06, Alan Stearns wrote:
>
> > 4. Copy/Paste
> >    https://lists.w3.org/Archives/Public/public-editing-tf/2016A
> pr/0005.html
>
> I won't be able to attend that discussion, so here my thoughts about it,
> based on 25 years of handling of this problem in various markup-based
> editors... This is clearly one of the MAJOR issues all Wysiwyg
> markup-based editors have to face. Cc:ing to public-editing then.
>
> One important thing we must not forget is the fact we're biased. We
> think of Web content editors only and that harms other potential usages
> of html-based core editors. We are geeks and don't edit content like
> non-geeks. We understand the issues, most editing environment users
> don't. So I would myself divide the problem into the following cases:
>
> 1. style-preserve: current-best
>
>    Copy exactly the html and try to resolve all styles into inline
>    styles.
>
>    This is the case where you want to preserve all the styles of the
>    source selection. Fantasai is right that style attributes are
>    _almost_ (see below) enough but unfortunately, !mportant could be
>    necessary in those style attributes depending on the target document
>    and stylesheets. That leaves some complexity to the target document's
>    side.
>
>    Unfortunately, we also have to deal with pseudo-elements and at-rules
>    here. For the former, the style attribute can't help and the CSS WG
>    identified that issue long ago. For the latter, it would be for
>    instance extremely difficult to copy styles for all MQs or copy
>    animations because painful collisions could happen in the target
>    document. Determining precisely where to store those CSS rules would
>    also be painful. So it's also pointless to preserve the animation
>    properties UNLESS the animation name exists in the target document.
>
>    That's why it can't be "preserve all", it can only be "preserve
>    best". It's also "preserve current" because of Media Queries.
>
>    I'd like to note I've always said scoped stylesheets would be
>    immensely useful here but... sigh.
>
>    Some new API could help here and that's where the CSS WG could help.
>
> 2. style-preserve: basic
>
>    Copy the html as is (don't inline styles inherited from the
>    ancestry or acquired from CSS rules.) This is fantasai's c) case.
>
> 3. style-preserve: none
>
>    Copy the html but strip inline styles and presentational html
>    attributes from all elements. And of course don't inline inherited
>    or CSS-rule-based styles. The question of presentational html
>    ELEMENTS like B or I remains open. I tend to get rid of them
>    replacing them by their child nodes.
>
> Side note: IDs should usually be stripped to avoid collisions. The case
> of named anchors is unfortunately painful... Class attributes can
> complexify the paste operation.
>
> Fantasai's b) case does not really exist, seen from the copy operation.
> It's exactly her a) case plus some extra operations done during the
> paste operation, potentially requiring user prompt.
>
> Hope that helps.
>
> </Daniel>
>
>
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org

Received on Wednesday, 19 October 2016 20:15:59 UTC