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 a flavour is identified). A good way to test this is to take a heavy piece in a graphics programme and drop it outside. Those two specs have evolved independently and I always sow clipops to be a more refined version of html5's DnD but there you have spotted a non-extension point. Is there any reason to justify the requirement to populate before the dragstart? Paul On 12 juil. 2013, at 00:22, Daniel Cheng 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. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model specifies that the drag data store is populated before dispatching the dragstart event. > > Would it make sense to do something similar for http://dev.w3.org/2006/webapi/clipops/#processing-model? Right now, as I read it, we don't populate the clipboard until after the copy/cut event has been cancelled. It'd be nice to make it consistent with drags... the main problem is I'm not sure if this will break compatibility with sites that didn't expect this. > > Daniel
Received on Friday, 12 July 2013 07:56:30 UTC