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

2013-09-13 Thread Hallvord Steen
- Cancelling the event can result in one of two things: - If event.clipboardData is empty, nothing happens. The system clipboard does not change. Here, the spec differs from how browsers behave so I've chosen to document how browsers behave. Neither Firefox nor Chrome let you clear the

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

2013-07-12 Thread Paul Libbrecht
Daniel, I personally think it is not at all a good idea to populate the clipboard when starting the drag! It makes sense when a copy operation is triggered, as the application may be vanishing. Most desktop DnDs I have observed only operate the transformation when the drop has occurred (hence

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

2013-07-12 Thread Charles Pritchard
The issue I've come up against is in keyboard access to the DnD model. Clipboard semantics exist in their own world, with OS quirks. DnD presupposed some kind of security-consent from the user. It's one of the most powerful gestures, allowing a user to grant read access to an entire directory

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

2013-07-12 Thread Hallvord Reiar Michaelsen Steen
On Fri, Jul 12, 2013 at 1:22 AM, Daniel Cheng dch...@google.com wrote: I've noticed that the way that drag-and-drop processing model is written, the default content that would be in the drag data store is available in the dragstart event.

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

2013-07-12 Thread James Greene
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

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

2013-07-12 Thread James Greene
Sorry, I think I must've misunderstand what your original proposed changes were as I thought you meant that the DataTransfer interface's items weren't being pre-populated on the ClipboardEvent's clipboardData property for beforecopy/copy events. Now I'm thinking that THAT is already in place and