Re: Copy/Paste Events

(trimmed cc list)

On Tue, 4 Aug 2009, Sebastian Markbåge wrote:
> On Mon, Aug 3, 2009 at 1:06 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > 
> > > 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.
> 
> Yes, but WebKit already has a model partially compatible with what IE 
> did. Gecko also has the events. Wouldn't it fall well within the purpose 
> of this spec to define such existing ad hoc implementations?

I don't really understand what you are asking for at this point. Are you 
saying the aforementioned part of the spec should be removed altogether? 
The point of the spec is to try to move things forward, we don't do that 
by not allowing UAs to implement new stuff.


> > > 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.
> 
> I'm saying that unless you specify element focus behavior, it won't 
> necessarily be possible to select the elements that are copyable.

I've now specified that behaviour.


> > > 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.
> 
> Yes, but my inarticulated point is - the custom user data, that is 
> actually transfered, may be conceptually stateful. It could be clean up. 
> I could initiate a LOCK on an item during dragstart and release it 
> during dragend. To enforce some kind of transactional logic on a drag 
> operation. But the item data could have been moved to the clipboard only 
> to resurface later on. At which point the target would somehow have to 
> check that a valid LOCK exists before allowing the paste.

This is exactly the same as if someone actually did drag the data to the 
clipboard.


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

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