Re: [editing] Enumerating CommandEvents

Before jumping into a specific API design, it might be useful to come up with a list of commands, their use cases, and requirements to fulfill those use cases.  That'll allow us to evaluate any API (change) proposal more thoroughly.

On Jun 5, 2014, at 2:47 PM, Julie Parent <jparent@google.com> wrote:

> 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)
>