The linked document seems only concerned with one usecase of the
clipboard, that of adding a 'copy to clipboard' type button to a page,
but doesn't address any other cases, namely the more common case of
copy/paste using the browser UI (edit menu, keyboard shortcuts), for
which the existing event driven model is more suited.
I don't think that having two separate APIs for each usage is a good
idea. I think you want to make use of the DataTransfer object in the new
APIs as well. For example:
let c = new ClipboardData(...);
...
clipboard.copy(c)
Having an asynchronous promise-based way of retrieving data is needed
though, but is needed for all clipboard usage, as well as for
drag-and-drop which also uses DataTransfer. I'd suggest instead to just
add some additional methods to DataTransfer for this. I filed a bug
recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1221562) about this.
As an aside, in IE5 one could do:
window.clipboardData.setData("text/plain", "Data");
So the proposed syntax has some precedent.
Neil
On 2016-03-10 3:00 PM, Hallvord Reiar Michaelsen Steen wrote:
People kindly pointed out to me that the plain-text forwarded message
had lost the link to Lucas's draft. Here it is:
https://docs.google.com/document/d/1QI5rKJSiYeD9ekP2NyCYJuOnivduC9-tqEOn-GsCGS4/edit#
On Thu, Mar 10, 2016 at 3:57 PM, Hallvord Reiar Michaelsen Steen
<hst...@mozilla.com> wrote:
Hi dev-platform-people,
while editing the clipboard API spec [1] it's sometimes been suggested
to forget about the old slightly cranky API and start fresh. I haven't
had much response from implementors when such ideas came up on
public-webapps, but here's an interesting E-mail from Lucas Garron at
Google who has drafted a document that might turn into a spec for a
better clipboard API.
I've been allowed to circulate this and ask which developers at
Mozilla might want to be involved in giving feedback on and perhaps
eventually implement such a draft spec. See Lucas's E-mail and the
linked draft below.
-Hallvord
[1] https://w3c.github.io/clipboard-apis/
---------- Forwarded message ----------
From: Lucas Garron <lgar...@google.com>
Date: Wed, Mar 9, 2016 at 4:16 AM
Subject: navigator.clipboard
To: hst...@mozilla.com
Cc: Daniel Cheng <dch...@google.com>
Hello Hallvord,
I'm a security engineer from Chrome who was slightly involved in
bringing text copying to the open web in Chrome. (Daniel Cheng, CCed,
did most of the hard work.) After introducing copying, we punted on
the topic of image formats, pasting, and clipboard listening, but it
has recently come up again.
At this point, I'm strongly interested in exploring the possibility of
"getting things right" by introducing a fresh clipboard API, which I'm
tentatively referring to as "navigator.clipboard" (although
window.clipboard would be fine, too ;-).
I know that it can be a common fallacy to start over on part of the
web platform, but document.execCommand() has a *lot* of baggage from
its designMode origins and it seems you yourself have wondered whether
browsers should consider something else.
We're seeing is a mounting desire to support more clipboard features
on the open web, and I think now is the time to consider a
straightforward-to-use API that is asynchronous:
- We want to transcode image formats for security, but this would
block a synchronous API.
- Paste will require a permission prompt in Chrome, which is much more
straightforward for Promise-based API.
I've started a very drafty proposal, mostly focused on historical
context and reasons to start fresh.
Do you have time and interest in collaborating to adapting the
clipboard API spec to a fresh clipboard API?
There are teams at Google with an active interest (e.g. Chrome Remote
Desktop, Google Docs) in bringing clipboard paste/listening to the
open web whom I'd like to bring in to lead an effort from the Google
side, but I wanted to ask you early in the process.
Thanks,
»Lucas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
