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

The problem is backwards compatibility. There are sites that use the
copy/cut event handler, and the proposal reverses the behavior.
Suppose it were implemented:

On older browsers: You must call event.preventDefault() in order for
your changes to be written to the clipboard.
On newer browsers: You must NOT call event.preventDefault() in order
for your changes to be written to the clipboard.

This transition would be extremely confusing, even if the proposal
does seem more intuitive =/

Daniel

On Fri, Jul 12, 2013 at 12:20 PM, James Greene <james.m.greene@gmail.com> wrote:
> 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
>>
>

Received on Friday, 12 July 2013 20:08:50 UTC