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: James Greene <james.m.greene@gmail.com>
Date: Fri, 23 May 2014 07:33:38 -0500
Message-ID: <CALrbKZhM3Y36wkS6+aZcWCFYRVZak7mqKQn4DQeiJvAHycHjHw@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: Glenn Maynard <glenn@zewt.org>, Anne van Kesteren <annevk@annevk.nl>, "Hallvord R. M. Steen" <hsteen@mozilla.com>, public-webapps <public-webapps@w3.org>
I'm all in favor of a new API as well.

Sincerely,
    James Greene



On Fri, May 23, 2014 at 5:53 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard <glenn@zewt.org> wrote:
> > 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.
>
> I'm inclined to agree, FWIW.  If the command is really strictly
> editor-related, and makes sense only in conjunction with an editor
> based on existing commands, I would add it to execCommand for
> consistency (like defaultParagraphSeparator or fontSizePt).  But
> anything else should stay far away.  (Actually, if contenteditable
> wasn't an unsalvageable trainwreck, I would rather write a new API
> that actually follows JS norms, like window.editor.bold() or similar,
> but it is, so there's no point in doing anything beyond *maybe* trying
> to get it a bit more interoperable.)
>
>
Received on Friday, 23 May 2014 12:34:27 UTC

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