Re: navigator.clipboard
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 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 > Date: Wed, Mar 9, 2016 at 4:16 AM > Subject: navigator.clipboard > To: hst...@mozilla.com > Cc: Daniel Cheng > > > 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
Re: navigator.clipboard
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
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
Date: Wed, Mar 9, 2016 at 4:16 AM
Subject: navigator.clipboard
To: hst...@mozilla.com
Cc: Daniel Cheng
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
Re: navigator.clipboard
Generally speaking, I find it really hard to reason about what we should do regarding clipboard events and drag'n'drop events without taking a larger look at the sad story that rich-text-editing on the web is today. It seemed like there was some really promising explorations happening for a while regarding developing a better API than the current contentEditable behavior. Did that go anywhere? / Jonas On Thu, Mar 10, 2016 at 6:57 AM, Hallvord Reiar Michaelsen Steen 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 > Date: Wed, Mar 9, 2016 at 4:16 AM > Subject: navigator.clipboard > To: hst...@mozilla.com > Cc: Daniel Cheng > > > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: navigator.clipboard
On Fri, Mar 11, 2016 at 8:57 AM, Jonas Sicking wrote: > It seemed like there was some really promising explorations happening > for a while regarding developing a better API than the current > contentEditable behavior. Did that go anywhere? http://w3c.github.io/editing/ ? It's still going strong - well, at least the specs are being worked on, I have no idea if implementation work has started anywhere, maybe specs are not quite ready to call for implementations yet. -HR ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
