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

Re: [clipboard] Semi-Trusted Events Alternative

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 15 Sep 2014 14:34:31 -0700
Cc: Dale Harvey <dale@arandomurl.com>, "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>
Message-id: <53D84108-6D84-4EC4-8550-0152153C087F@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Sep 15, 2014, at 1:09 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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?

Doing 2 would mean that well be changing the semantics of copy and paste.
It would be extremely confusing for users IMO.

Its also incompatible with conventions on a lot of operating systems.

- R. Niwa
Received on Monday, 15 September 2014 21:35:05 UTC

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