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>

> 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