- From: Paul Libbrecht <paul@activemath.org>
- Date: Thu, 13 Aug 2009 13:55:25 +0200
- To: Ian Hickson <ian@hixie.ch>, "public-webapps@w3.org Group WG" <public-webapps@w3.org>
- Cc: Sebastian Markbåge <sebastian@calyptus.eu>
- Message-Id: <C9615980-EEEF-4760-B145-203BA86BA7A1@activemath.org>
Le 13-août-09 à 13:34, Ian Hickson a écrit : >> So I'm saying is that, regardless of whether you use voice, keyboard, >> touch or mouse... There are two distinct concepts at play here. > > I disagree. The drag and drop model allows the user to drag to the > clipboard and paste from the clipboard. This is exactly what copy-and- > paste simulates. I don't see why this is a problem. If the drag-and- > drop > code doesn't support dragging to another app, then that's a problem > with > the drag-and-drop code, and providing a second API to work around that > problem just for copy-and-paste doesn't help the people using the > drag-and-drop feature in that fashion To me it is a problem to confuse the two operations: - drag and drop allows a precise visual target identification thus may be considered safer (and this is actually implemented so: you can faster drag-and-drop URLs than copy and paste them). Copying, however, is simpler and better understood as long as the selection model is clear. - copy-and-paste is aimed at long term storage: if you write to the clipboard you have to write all the flavours you think a recipient would ever make use of! The clipboard often survives computer-restarts. - drag-and-drop is aimed at direct negotiations: generally, only at the end of the drag is the actual data produced. In case this is running over a network-based conversion this is significant I feel. So I would insist to split the two set of events while keeping common, of course, some of the interfaces to denote what can be transferred. paul
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 13 August 2009 11:56:10 UTC