Re: Copy/Paste Events

On Mon, 27 Jul 2009, Jacob Rossi wrote:
>
> 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?

It seems like the quickest and simplest way of making copy/cut/paste and 
drag-and-drop transparently accessible and implementable to authors. That 
is, by doing this we don't require authors to implement all of drag-and- 
drop, copy-and-paste, and accessible alternatives: just by doing DnD, they 
get the other two for free.


> 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.

Nor would it, since the copy operation would skip the mouse movement steps 
of the algorithm.


> 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.

I believe there are significant savings to be made.


On Mon, 27 Jul 2009, Sebastian Markbåge wrote:
>
> I agree with Jacob. I find this part of the spec... puzzling. Since 
> there is currently no way to differentiate between a copy and a 
> dragstart, you could potentially cause unnecessary UI flicker if you 
> added/changed elements during dragstart and removed them during dragend 
> to make a visual indication that a drag was being performed.

It's true that if you change the DOM during drag-and-drop that you would 
get flicker. We could address this by providing a flag on the events 
saying that this is a programatic drag and not an interactive one, if it 
turns out to be a real problem.


> It seems that nobody has bothered to implement this part of the spec 
> even when implementing Drag & Drop so it must not make sense.

This part of the spec postdates most implementations, and the newer 
implementation (Gecko) was only trying to be compatible with what IE did, 
as I understand it.


On Tue, 28 Jul 2009, timeless wrote:
> 
> so, one advantage of not distinguishing is that it enables people w/o 
> mice to trigger drag events.
> 
> if you don't do this, you effectively block such users from interacting 
> with certain classes of web pages.
> 
> Having encountered various other stupid forms of discrimination while 
> working on devices which have limitations wrt input methods, i 
> appreciate it when things are designed with more flexibility in mind.

Indeed.



On Mon, 27 Jul 2009, Jacob Rossi wrote:
> 
> Do you have any data on how many people would be browsing with neither 
> mouse nor touch capabilities?

Many people with disabilities fall into this camp, as well as a number of 
smaller device users. HTML5 is built on the principle of applying to as 
many people as possible, not just a majority.



> One possible solution is that copy-and-paste could be treated as 
> drag-and-drop only when the browser is in Caret Browsing mode (do any 
> browsers other than Firefox and IE have this?) and on mobile devices 
> without touch capabilities.

That sounds like it would lead to undetected bugs.


On Tue, 28 Jul 2009, Sebastian Markbåge wrote:
> 
> 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.

I'm not quite sure what you're saying here. In general we want to reduce 
the burden on the author as much as possible, so anything we can make 
automatic, we should.


> Also, a clipboard operation can last longer than a drag/drop. It can 
> last long after the application has been closed. At which case, any 
> stateful data in the operation may not be viable anymore. I.e. the data 
> may not be viable after "dragend".

Copy-and-paste is defined as _two_ drag operations, one from the app to 
the clipboard, and one from the clipboard to the app.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'