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