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

Re: [editing] Enumerating CommandEvents

From: Julie Parent <jparent@google.com>
Date: Thu, 5 Jun 2014 14:47:30 -0700
Message-ID: <CAPSmAAQ0uT0oiWOo=YRHS4XK5EWc5KHBBabyEqfzB3GQu5zmPw@mail.gmail.com>
To: Ben Peters <Ben.Peters@microsoft.com>
Cc: public-webapps <public-webapps@w3.org>
Before we (further) complicate execCommand, can you explain what using
execCommand buys over using a CustomEvent of type "command"?  For the
application, the event handling code would remain the same either way. The
dispatch would be slightly more complicated since execCommand does
automatically figure out which node to fire the event on, but I'd consider
that more of a limitation than a feature.


On Thu, Jun 5, 2014 at 11:36 AM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

> On Thu, Jun 5, 2014 at 11:16 AM, Julie Parent <jparent@google.com> wrote:
> > Custom commands are definitely a key concept, and I agree with them.
>  What
> > would the transition from the current execCommand signature look like?
> aka,
> > execCommand(String aCommandName, Boolean aShowDefaultUI, String
> > aValueArgument).  I think ShowDefaultUI may not even be used by anyone,
> and
> > could be removed (we'd need to verify this obviously)?  For commands that
> > currently take an argument for the value, would you just convert to
> > document.execCommand('FormatBlock', {value:'h1'})?
>
> Unfortunately, ShowDefaultUI is used for createLink. So I believe we
> should support both
>
> execCommand(String aCommandName, Boolean aShowDefaultUI, String
> aValueArgument)
>
> and
>
> execCommand(string aCommandName, object commandData)
>
Received on Thursday, 5 June 2014 21:47:59 UTC

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