W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 20 May 2014 18:01:42 -0500
Message-ID: <CABirCh9gb5LL-=-WrQr5SAf69NtZ0ntnschq6jn+7fjyEDcHRw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "Hallvord R. M. Steen" <hsteen@mozilla.com>, public-webapps <public-webapps@w3.org>
I think I'd suggest avoiding the mess of execCommand altogether, and add
new methods, eg. window.copy() and window.cut() (or maybe just one method,
with a "cut" option).  execCommand is such a nonsensical way to expose an
API that trying to stay consistent with its commands is probably not much
of a win.


On Tue, May 20, 2014 at 5:11 AM, Hallvord R. M. Steen <hsteen@mozilla.com>
 wrote:

> However, if a scripted copy event can't take a payload and have it placed
> on the clipboard, what's the point of making script-generated copy events
> possible in the first place? If there's no point I'd rather disallow them.
>

This seems like you don't like an aspect of the DOM event model, so you
want it to behave differently when used with your API.  :)  There's nothing
special about copy for it to behave differently from other events, and the
other events on the platform can be generated by script.

On Tue, May 20, 2014 at 5:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> How is it true for click?
>

(We clarified this out of band.  Dispatching "click" does cause navigation,
but you have to use new MouseEvent.  This is a weird exceptional case and
should be ignored when designing new features.)

-- 
Glenn Maynard
Received on Tuesday, 20 May 2014 23:02:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC