On Mon, Aug 3, 2009 at 1:06 PM, Ian Hickson <i...@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? > 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<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021445.html>, it won't necessarily be possible to select the elements that are copyable. Hence, the author wouldn't automatically get copy/paste behavior by just implementing drag/drop. The burden is still on the author to provide a means of selection etc. Unless that particular UA can do that automatically somehow. > 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. It could also be that the user is transfering data that is inheritably transient and should therefore not be available beyond dragend. So I'm saying is that, regardless of whether you use voice, keyboard, touch or mouse... There are two distinct concepts at play here.
