RE: Copy/Paste Events

Hi Sebastian,

>>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
You are right.
When mouse or touch screen are missing, there are  solutions like virtual pointer etc. But it is not a must,  depending on the required UX.

NetFront Browser is a full Web browser that does not use proxy (proxy may lead to relaxed security etc)

More info on NetFront (if you do not know it yet) is here:
http://www.access-company.com/products/mobile_solutions/netfrontmobile/browser/index.html

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Sebastian Markbåge
Sent: Tuesday, July 28, 2009 3:39 PM
To: timeless@gmail.com
Cc: Jacob Rossi; www-dom@w3.org; public-webapps@w3.org; Travis Leithead; Tony Ross
Subject: 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

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<mailto: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


________________________________
________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.