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
