Re: Clipboard API: Default content in copy/cut handlers

Right, I think this makes total sense.  A common example might be to add
your page's URL, copyright notice, etc. to the end of whatever text the
user has selected WITHOUT having to query the Selection/Range APIs to
[hopefully] retrieve their selected text.

I am discouraged, however, to see someone who works for a browser vendor
lamenting that doing it in what is likely the "right way" may be impossible
because a number of browser vendors have already implemented the
functionality.  To me, it doesn't really seem like adding this new behavior
would negatively affect the current APIs at all as no one is *expecting* to
have that data provided on the Event right now; the only real change here
is in the browser internals, and consumers can take advantage of such by
eliminating their current Selection/Range queries once the Event is
providing that data on their behalf.

As someone who is not a browser vendor employee, this sounds very doable.
 ;)

Sincerely,
    James Greene



On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng <dcheng@google.com> wrote:

> On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht <paul@hoplahup.net>
> wrote:
> > Is there any reason to justify the requirement to populate before the
> dragstart?
>
> My guess is that it's a convenience for authors to be able to modify
> the content from the default easily.
>
> On Fri, Jul 12, 2013 at 5:22 AM, Hallvord Reiar Michaelsen Steen
> <hallvord@opera.com> wrote:
> > Regarding the question: I'm not sure what exactly you're asking for with
> > "something similar" and what effect it would have. Is it about reading
> from
> > clipboard (for example, since you mention  DnD of files, like reading
> pasted
> > file references in a paste event)? Writing to the clipboard? Is there any
> > change the clipboard spec should make to make pasting files/folders
> easier
> > to implement? If yes, how and why?
>
> My original idea is that prior to dispatching a copy/cut event, run
> "if there is a selection, place the contents of the selection in the
> data store", then dispatch the copy/cut event.
>
> If the copy/cut event is not cancelled, then:
> - Write the data store to the clipboard.
>
> If the copy/cut event is cancelled:
> - Do nothing. The data store is discarded and the changes are not
> written to the clipboard.
>
> Unfortunately, this is completely opposite of how it's handled today
> by Firefox/Chrome/Safari so I don't think we can do this. Oh well.
>
> Daniel
>
>