W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

From: James Greene <james.m.greene@gmail.com>
Date: Fri, 23 May 2014 13:14:26 -0500
Message-ID: <CALrbKZjEG=v3QDtnU7vq4QFBYvCRW3WG5hL2csx2QupCum8U8g@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Robin Berjon <robin@w3.org>, Aryeh Gregor <ayg@aryeh.name>, Anne van Kesteren <annevk@annevk.nl>, "Hallvord R. M. Steen" <hsteen@mozilla.com>, public-webapps <public-webapps@w3.org>
Maybe it's just me but... I would personally never want the browser to
automatically assume what I wanted copied and into which clipboard
segments, with the possible exception of a Selection.

I would prefer something very explicit, e.g.:

  "text/plain": "BLAH",
  "text/html": "<b>Blah</b>",
  "application/rtf": "{\\rtf1\\ansi\n{\\b Blah}}",
  "text/x-markdown": "**Blah**"

Also, Hallvord et al: switching to a standalone API would also mean that we
can drop all of the `cut`-specific parts of the spec since `cut` requires
an active Selection, right?

    James Greene

On Fri, May 23, 2014 at 10:13 AM, Glenn Maynard <glenn@zewt.org> wrote:

> Hallvord: By the way, please add the editor of the HTML spec to the
> beginning of the list in your references.  It's strange to list a bunch of
> author names, but not the person who actually writes the spec.
> On Fri, May 23, 2014 at 8:21 AM, James Greene <james.m.greene@gmail.com>wrote:
>> This kind of copy does not implicitly have anything to do with Selection,
>> unless we continue to have its default action be copying the currently
>> selected text.  It is substantially more likely to be used for custom text
>> insertion.
> I'd assume something like:
> // Copy text:
> window.copyToClipboard("hello");
> // Copy HTML text:
> span = document.createElement("span");
> span.innerHTML = "<b>hello</b>";
> window.copyToClipboard(span);
> // Copy an image from a CanvasImageSource:
> window.copyToClipboard(canvas);
> window.copyToClipboard(img);
> // Copy the selection:
> window.copyToClipboard(window.getSelection());
> // Copy HTML text with plaintext alternative:
> dt = new DataTransferItemList();
> dt.add("hello", "text/plain");
> dt.add(span.innerHTML, "text/html");
> window.copyToClipboard(dt);
> This avoids the busywork of creating a DataTransfer in common cases, but
> allows using DataTransfer when you want to do something more advanced, like
> provide alternatives or explicitly specify a MIME type.  Note
> that DataTransferItemList isn't actually constructable right now.  Note
> that I used DataTransferItemList in the example and not DataTransfer, since
> DataTransfer is only relevant to drag-and-drop.
> I wonder what the right way to handle images is.  Native Windows
> applications can copy pixel data to the clipboard, then paste it back out.
>  DataTransferItem wants things to act like strings, though, so you'd have
> to encode the image to a file format.  If that's PNG, that's an expensive
> conversion.  Maybe DataTransferItem should be able to return an ImageSource.
> (As an aside, why is the paste event's .clipboardData not set to the text
> being pasted?  I wanted to see what pasting images did in current browsers,
> but at least in Chrome there's nothing in there, even if I just paste plain
> text.)
> --
> Glenn Maynard
Received on Friday, 23 May 2014 18:15:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC