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 <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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform