- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 15 Sep 2014 13:09:55 -0700
- 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