On Jan 22, 2010, at 1:38 PM, Daniel Cheng wrote: > Two more questions about implementation details: > > Cut/copy: > Does it make sense to fire a drag event at all? The spec says that drag > events should be fired at the source node every 350ms (presumably to allow > the source node to cancel a drag after it started), but a cut/copy takes > place "instantaneously". If drag events should be fired during cut/copy, > should the clipboard be restored to its original state if the drag event is > cancelled? It would make sense, but might make implementations more > complicated. > > Paste: > It seems like there is no time a dragleave event would ever fire. A paste > essentially goes through the drag and drop loop once; the only possible > transition is for the current target element to go from null to non-null.
I don't think it makes sense to have cut/copy/paste use drag events. 1) Browsers already have specific events for cut/copy/paste - those three plus beforepaste are used in content, including in major sites, so they must be implemented for Web compatibility regardless of anything else. It seems unwise for HTML5 to document a brand new untested way to do events for cut/copy/paste, but not document the existing way that is needed for Web compatibility. Thus, even if cut/copy/paste operations continue to fire the drag events, the pre-existing events should be documented. 2) In native UI, it is not always the case that drag-and-drop is possible whenever cut/copy/paste is. For example, in Preview on Mac OS X, if you select a rectangular piece of an image, you can cut or copy it, but you can't drag it. 3) In native UI, even when cut/copy/paste and drag are both possible, they do not always have the same effect. For example, it's common that in reorderable lists you can drag to reorder, but on the Mac at least they rarely allow reordering via cut/copy/paste. Instead there are specific key bindings for reordering (often including up or down arrows with modifiers). Drag and drop also has positional information that is lacking for cut/copy/paste. When dragging files in a file manager's icon view, you can drop the icon at the exact position of your choice, but cut/copy/paste often inserts in a position based on the current arrangement. This requires an actual distinction between operations. 4) In native UI, it is not always the case that cut/copy/paste is possible whenever drag-and-drop is. For example, bookmarks in Safari's Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. The keyboard-accessible interface for reordering the bookmarks bar is via the bookmarks manager. 5) The drag and drop event sequence is way too complicated to use for the simple case of customizing copy/paste behavior. Many of its fiddly details are simply not applicable. Filed as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800>. Regards, Maciej > Daniel > > On Tue, Jan 12, 2010 at 5:38 PM, Ian Hickson <[email protected]> wrote: > On Tue, 12 Jan 2010, Daniel Cheng wrote: > > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard > > > > The current spec says that drop events should be fired while handling > > copy/cut operations. Is this intended? The clipboard is not a DOM > > element; it seems like it'd make sense only to fire the drop event for > > pastes. > > Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
