[whatwg] HTML5 cut/copy

[Maciej Stachowiak]

On Jan 23, 2010, at 3:19 AM, Ian Hickson wrote:

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

Here are some sites that use cut/copy/paste event listeners. Given the nature of the sites, I do not believe these event listeners are set for user-hostile purposes. But the way I got this information (by instrumenting my copy of WebKit) does not lend itself to revealing the particular purpose for which the listeners are set:

https://mail.google.com/ (only when you call up the compose window)
    beforecut
    beforepaste
    cut
    paste

http://google.com/
    paste  (it's on the main input field, but the JS is obfuscated so I can't tell what it does - no drag event listeners)

http://mail.yahoo.com/ (after logging in, and additional listeners are set when you focus the compose window)
    paste
    cut

http://docs.google.com/  (when viewing a Document)
    beforecut
    beforepaste
    cut
    copy
    paste

http://docs.google.com/  (create a new presentation and click an editable text area)
    beforecut
    beforepaste
    cut
    paste

http://hotmail.com/ (when opening compose window)
    cut
    paste

http://livejournal.com/ (in the "Post a New Entry" view)
    paste

http://me.com/ (Sign in page; likely more after that but that would cost money to test)
    paste




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

The bottom line is that it's a design choice and shouldn't be forced by the API. Although I'm not the UI designer responsible for this decision, my best guess is that this would interfere with the lasso selection gesture. Whether it's a really great reason or not, I'd be hesitant to design an API that second-guesses our UI designers.


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

That sounds like a design flaw with the drag and drop model. Sounds like something to fix, not something to compound with another design flaw.

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

That's exactly the problem. Paste is not equivalent to a drop at (0, 0) in screen coordinates (unless you assume that a valid drop target can never be at (0, 0), but that is not a correct assumption in general). Granted, this could be fixed by having an explicit flag to indicate "no position".


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

The items in the bookmarks bar can actually be keyboard focused (in full keyboard access mode), so it would have been almost free to support cut & paste. It was a design choice to avoid making the interaction too complex, not a matter of insufficient resources to implement the behavior.


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

Sure, but apparently it's common to want to customize copy/paste behavior without doing drag-and-drop at all. Which is fine and should be allowed.

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

There's really two aspects of the feature:

A) Drag-and-drop events are the *only* way to do cut and paste, and the specific events for them are undefined. This is clearly not necessary to achieve the above accessibility property. Thus, accessibility considerations are not a valid reason to fail to specify the legacy events, since they are widely implemented and used on popular sites. But I see below that you agree with this point.

B) Anything that handles drag-and-drop will also handle interaction via cut/copy/paste. But this is not sufficient to give automatic keyboard accessibility to anything done via drag-and-drop:
    I. It doesn't guarantee that drag sources or drop targets are keyboard focusable. Without the ability to focus, the abilities to copy and paste are not very useful.
    II. Drag and drop is often used for specific positioning within an area, and cut-and-paste cannot replicate that.
    III. Drag-like gestures within the page or within a single element can (and in fact often do) just use mouse events (mousedown, mouseup, mousemove, etc). The weird cut/copy/paste linkage does not help this case, and might even discourage authors more from using proper drag events.

For users with motor impairments, the most thorough way to provide accessibility to drag-and-drop UIs is to have a method for stepwise control of the mouse pointer and a "sticky" click. For users with visual impairments, it may be desirable to have similar "sticky drag" behavior, though fine positioning may not at this point be a consideration. I think those are the best things to do at the browser/OS level.

In both cases, it's best to make sure that anything that can be done via drag-and-drop can be done in at least one other way. Sometimes cut/copy/paste is the best way, but not always. 

Thus, making drag-and-drop always accessible via cut-and-paste seems well-meaning but I think it is ultimately misguided. Therefore I am not sure this aspect of the feature is justified either.

One possibility is to make cut/copy/paste binding the default, but let authors opt out if they have some better alternate UI in mind. I'm not sure of the best design for that.

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

We trust not only ourselves, but also our application developers to get this right. It's true that a lot of Web development is not done with careful thought to HI and accessibility considerations, but I don't think a technical solution is practical in this case.


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

I cannot vouch for the accuracy or completeness of this information, but here's some docs:

http://msdn.microsoft.com/en-us/library/ms533051(VS.85).aspx
https://developer.mozilla.org/en/DOM/element#Event_Handlers
http://www.quirksmode.org/dom/events/cutcopypaste.html


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

I've been planning to file this bug for a while. (Or maybe more than one, since adding the cut/copy/paste events is really a separate issue from whether cut/copy/paste operations are bound to drag events.) But I chose to also send an email since there was a topical thread about it.

I realize that it has the same effect for you either way, but it doesn't have the same effect for me. It's much easier for me to track bugs I have filed than to track email feedback that could lead to meaningful changes.

I'll gladly just close the bug myself if the email discussion leads to sufficient changes (or convinces me that further change is not called for).

Regards,
Maciej