W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: [clipboard] Semi-Trusted Events Alternative

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 15 Sep 2014 13:09:55 -0700
Message-ID: <CA+c2ei_EE5p6K2+LZOQVLV0nqyhbOv2Ma9wiyn+sJXAf5_n-2A@mail.gmail.com>
To: Dale Harvey <dale@arandomurl.com>
Cc: "Hallvord R. M. Steen" <hsteen@mozilla.com>, Ben Peters <Ben.Peters@microsoft.com>, "James M. Greene" <james.m.greene@gmail.com>, Perry Smith <pedzsan@gmail.com>, Webapps WG <public-webapps@w3.org>
On Sun, Sep 14, 2014 at 5:54 AM, Dale Harvey <dale@arandomurl.com> wrote:
> websites can already trivially build editors that use copy and paste within
> the site itself, the entire problem is that leads to confusing behaviour
> when the user copies and pastes outside the website, which is a huge use
> case of the clipboard in the first place

I'm not sure I fully follow your argument. So let me provide two
options that I think we have.

1. Forbid any attempts at reading directly from the clipboard, no
matter if the data there came from the current origin or not. Thereby
keeping the API consistent.
2. Allow reading data from the clipboard at any time if the data there
originated from the current origin. Thereby making the API as helpful
as possible for the case when data is copied within a website.

Are you saying that you think the consistency of option 1 is more
important than the ease-of-use of option 2?

The only thing that I'd worry about is that having websites handle
within-website copying themselves rather than go through the clipboard
API is that it can very easily create edgecases that are easy to miss.

For example, how does the website detect if the user overwrites the
contents of the clipboard by copying data from another location? Or if
the OS has features like a clipboard manager which allows you to keep
a history of clipboard contents and paste old values (I believe
Windows used to enable this).

/ Jonas
Received on Monday, 15 September 2014 20:10:53 UTC

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