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

Re: Copy/Paste Events

From: Paul Libbrecht <paul@activemath.org>
Date: Tue, 28 Jul 2009 15:51:49 +0200
Cc: timeless@gmail.com, Jacob Rossi <t-jacobr@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, Travis Leithead <travil@microsoft.com>, Tony Ross <tross@microsoft.com>
Message-Id: <C64639ED-B76A-43D8-9E58-F1BE627E2FCE@activemath.org>
To: Sebastian Markbåge <sebastian@calyptus.eu>
Just to enhance a bit the comments here, all the implementations  
guides I've seen about drag-and-drop very quickly rely on the fact  
that a state is assigned with the drag-operations-sequence, e.g. to  
define acceptance or rejection and that this state is unique globally  
on the whole user-interface.

Much of the behaviours of many GUIs change while a drop is happening,  
Apple's exposé is another such: you can trigger it while dragging.

I am sympathetic to timeless's wishes but I have the impression  
they're not really realistic, I don't see normal mobile phone user  
able to copy-and-paste instead of drag-and-drop with a cursor if the  
page developer has not also thought of enabling copy-and-paste...


Le 28-juil.-09 ā 15:38, Sebastian Markbåge a écrit :

> A similar issue has been brought to the WHATWG list:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021445.html
> The spec doesn't define how the UA should select an element to do  
> your drop without a mouse - because drop targets may not be focusable.
> So, a copy/paste would not automatically be enabled for all drag/ 
> drop operations anyway. By having a separate copy/paste API, an app  
> developer would be required to provide a functional keyboard  
> alternative.

Received on Tuesday, 28 July 2009 13:52:43 UTC

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