Just to enhance a bit the comments here, all the implementations guides I've seen about drag-and-drop very quickly rely on the fact that a state is assigned with the drag-operations-sequence, e.g. to define acceptance or rejection and that this state is unique globally on the whole user-interface. Much of the behaviours of many GUIs change while a drop is happening, Apple's exposé is another such: you can trigger it while dragging. I am sympathetic to timeless's wishes but I have the impression they're not really realistic, I don't see normal mobile phone user able to copy-and-paste instead of drag-and-drop with a cursor if the page developer has not also thought of enabling copy-and-paste... paul Le 28-juil.-09 ā 15:38, Sebastian Markbåge a écrit : > A similar issue has been brought to the WHATWG list: > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021445.html > > The spec doesn't define how the UA should select an element to do > your drop without a mouse - because drop targets may not be focusable. > > So, a copy/paste would not automatically be enabled for all drag/ > drop operations anyway. By having a separate copy/paste API, an app > developer would be required to provide a functional keyboard > alternative.
Received on Tuesday, 28 July 2009 13:52:43 UTC