[whatwg] HTML5 cut/copy

On Fri, 22 Jan 2010, Maciej Stachowiak wrote:
> 
> 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.

Are there sites that use them for useful purposes but that do not support 
drag and drop? (If so, I'd like to study them to see what can be learnt 
from them. Last I checked, use of the copy/paste events was almost 
uniformly for anti-user reasons, and I couldn't find any sites that made 
good use of them.)


> 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.

Is there a good reason for this?


> 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).

The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model that 
it is based on) doesn't really work for this case anyway, regardless of 
the copy/paste issue, since there doesn't seem to be any sane way to 
distinguish between an in-page drag and a drag to an external application 
such as a clipboard. If you can drag to a clipboard, I don't see why we 
would _disallow_ the copy/paste interaction.


> 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.

The API does support that distinction -- when the operation was performed 
without position information, the screenX and screenY coordinates will be 
zero.


> 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.

Is there any reason to disallow that model though? If it was free to 
support it, would you still have disabled it?


> 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.

The drag and drop event sequence is way too complicated to use for drag- 
and-drop, let alone copy/paste. But if you've done the work to get drag- 
and-drop working, it seems silly to have to do even _more_ work to get 
copy/paste working as well.


In any case, while the above points are all good points, the reason for 
emulating copy/paste using the drag-and-drop model is actually to ensure 
that pages that use the (primarily mouse-based) drag-and-drop model are 
still accessible to keyboard users, and to ensure that the model is indeed 
in fact device-independent, and as such, I don't think they are a 
convincing argument to remove the feature. While it is true that Apple can 
be trusted to provide a keyboard-accessible UI, I think it would be 
optimistic of us to assume that everyone who provides a drag-and-drop UI 
thinks about how it can be used by non-mouse users.

Independent of this, though, I agree that we should specify the copy/paste 
events, if they are indeed used on pages that don't support drag-and-drop. 
Are these events documented anywhere?


> Filed as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800>.

FWIW, sending a mail to the WHATWG list has the same effect as filing a 
bug, there's no need to do both.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 23 January 2010 03:19:41 UTC