[Bug 8800] New: Cut/copy/paste should use dedicated events instead of overloading drag and drop

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800

           Summary: Cut/copy/paste should use dedicated events instead of
                    overloading drag and drop
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: mjs@apple.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


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. (Sites using at least some of these
included Google Docs and Yahoo Mail.)

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.

Thus, I suggest that the requirement to dispatch drag and drop events for
cut/copy/paste operations should be removed, and instead HTML5 should specify
the existing legacy events for this, including at least "cut", "copy", "paste"
and "beforepaste".


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 23 January 2010 03:06:04 UTC