Re: Copy/Paste Events

A similar issue has been brought to the WHATWG list:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021445.html

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

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

Note that there are several ways to do drag/drop or copy/paste:

1) You copy the data to the clipboard, and let it sit there for the
remainder of the clipboard's life time and try to trigger a paste on any
focusable targets.

2) You can make it a single operation. You can issue a dragstart and
highlight the object being dragged. Then the UA allows selection (only) on
drop targets. If canceled, dragend is triggered with dropEffect none, just
like in a drag operation. If successful a drop is issued on a target. Either
way the data is only alive for the duration of the operation. It's not
persistently stored in a local clipboard. This is comparable to how
Microsoft Excel does copy/paste.

The first one is comparable to copy/paste while the second one is comparable
to drag/drop. If an application doesn't support stateless moving of data, it
shouldn't support copy/paste.

On Tue, Jul 28, 2009 at 12:10 PM, timeless <timeless@gmail.com> wrote:

> Jacob Rossi wrote:
> > Are you mostly referring to non-touch mobile users?
>
> I'll answer this first, by saying that it was a general reference.
> Although, it is true that today I work in the mobile industry. But i
> also worry about other scenarios. Perhaps for some people it's hard to
> use a mouse (there are cases where people who need accessibility aids
> really can't easily manipulate mice).
>
> > Do you have any data on how many people would be browsing
> > with neither mouse nor touch capabilities?
>
> I'm not going to go looking through my internal sources (partly
> because they're almost certainly confidential, but mostly because i'd
> have to find them).
>
> I'd imagine that the majority of cell phones do not have touch or a
> mouse. I'm fairly certain that there are more mobile phones than there
> are personal computers.
>
> Please keep in mind that just because a device is under powered
> doesn't mean it doesn't have a web browser or the ability to use a
> browser proxy (SkyFire [1] / Opera Mini [2]). I'm fairly certain more
> devices are capable of running proxies than have touch screens or
> mice.
>
> > 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.
>
> This would mean that such devices wouldn't be able to easily trigger
> copy/paste behaviors.
>
> Explaining multiple modes to users is a royal pain. Caret browsing is
> just another form of pain, so is spacial navigation.
>
> For lack of a confusing reference to such pain, i've done a quick
> search and found one:
> Widget interaction models [3].
>
> I haven't read it, and please excuse the wonderful url structure. A
> quick glance indicates to me that it's confusing, and that's all I
> wanted in a reference :).
>
> [1] http://www.skyfire.com
> [2] http://www.opera.com/mini/
> [3]
> http://www.forum.nokia.com/infocenter/index.jsp?topic=/Design_and_User_Experience_Library/GUID-759A5FA5-5B7D-4B64-ACD1-48783FFC4486.html
>