W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Copy/Paste Events

From: Jacob Rossi <t-jacobr@microsoft.com>
Date: Mon, 27 Jul 2009 04:39:05 +0000
To: "www-dom@w3.org" <www-dom@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>
CC: Travis Leithead <travil@microsoft.com>, Tony Ross <tross@microsoft.com>
Message-ID: <1FBDB72C331CBA4D815A8B85E1CBB65C03E5D4@TK5EX14MBXC115.redmond.corp.microsoft.com>
Section 7.10.6 "Copy and paste"<http://dev.w3.org/html5/spec/Overview.html#copy-and-paste> of the HTML5 spec suggests that "copy-and-paste is a form of drag-and-drop." It mandates that for a copy operation the user agent should act as if the user had initiated a drag on the current selection. Likewise, a cut should be a "drag" operation followed by a selection delete operation. Accordingly, a paste should be treated as a drop.

I would assume this concept should be applied to the events associated with these actions as well. Thus it would follow that a copy/cut operation would produce a drag event and a paste would produce a drop.

Is this really what we want? Most implementations (IE, Firefox, Safari, and Chrome) already have separate events for copy/cut/paste. While I see the similarities between the copy-and-paste and drag-and-drop, I don't believe that means they should be lumped together.  For example, what if a web page wishes to change the mouse cursor while a drag operation is occurring? You wouldn't want the mouse cursor to change in the same manner when text is copied to the clipboard.

In general, unless there is a significant savings in combining these two operations into one set of events, I think that they are best differentiated.



Jacob Rossi
Received on Monday, 27 July 2009 04:39:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC