This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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".
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024822.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: When I studied the APIs, I found them to be very complicated and over-engineered, as much as the drag-and-drop events. I'm not yet convinced that speccing the dnd events as we did is proving to be a good thing. I propose that we wait to see what happens with those before doing the same with the copy/paste events. Would that be acceptable?
(In reply to comment #2) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Did Not Understand Request > Change Description: no spec change > Rationale: When I studied the APIs, I found them to be very complicated and > over-engineered, as much as the drag-and-drop events. I'm not yet convinced > that speccing the dnd events as we did is proving to be a good thing. I propose > that we wait to see what happens with those before doing the same with the > copy/paste events. Would that be acceptable? If this API was purely optional for implementors, that would be fine. But from the list of popular sites I found to be using these events, it seems that implementing them is required to successfully process public Web content. I would be ok with marking these events as obsolete if you don't think they should be used, though I am not sure of the practical effect of making DOM APIs or events obsolete.
I do not have the bandwidth to write the tests for, reverse engineer, and spec this particular feature in the next few months. However, I would be happy to translate a description of the implementation requirements for this feature and a tutorial for authors using this feature into authoring and user agent conformance criteria in the spec should someone else have the bandwidth to do this.
(In reply to comment #4) > I do not have the bandwidth to write the tests for, reverse engineer, and spec > this particular feature in the next few months. However, I would be happy to > translate a description of the implementation requirements for this feature and > a tutorial for authors using this feature into authoring and user agent > conformance criteria in the spec should someone else have the bandwidth to do > this. > I will try to find someone who has the bandwidth to do that. I would consider it acceptable to close the bug as NEEDSINFO on the basis cited above. It would help if you could give some guidance on the information needed.
If anyone would like to work on this please feel free to contact me and I'll be happy to work with you to figure out what we need to have to move this forward. Basically though what's needed is an implementation guide and a tutorial (authoring guide), the implementation guide being something I'd then translate into specese, and the tutorial being something we can either put in the spec directly or turn into a set of examples for the spec (with the main bulk of the tutorial going into something like Lachy's draft or the wiki or a blog post). Marking REMIND per off-line discussion for now.
This bug is related to the other drag & drop bugs, #7721 and #10713
The bug-triage sub-team thinks this bug is TF priority as it is closely related to bug #7721 and #10713 that have the a11yTF keyword, too. Still it makes sense to wait for the outcome of the other bugs to find a consistent solution.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There is now a spec for this.