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 tree. Unfortunately, we don't have that semantic easily accessed from the keyboard. On the desktop, copy and paste hot keys are often used for keyboard access to drag and drop, even though you can't copy a folder into a text document. That's the state of things. I do think browser vendors should be responsible for implementing DnD via keyboard. onclick works via keyboard but even with input file, WebKit has not extended the same support as a DnD onto an input element (vs click and file selection). Process has stalled, there's a stalemate between vendors. -Charles On Jul 12, 2013, at 12:56 AM, Paul Libbrecht <p...@hoplahup.net> wrote: > 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 >
