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 11:16:07 -0700
Message-ID: <CAPSmAASOiaEK5E2v3VZJc4kvgVYacTZd2uvgPifa2K1+hp=TOA@mail.gmail.com>
To: Ben Peters <Ben.Peters@microsoft.com>
Cc: public-webapps <public-webapps@w3.org>
On Thu, Jun 5, 2014 at 10:58 AM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

> On Wed, Jun 4, 2014 at 7:55 PM, Julie Parent <jparent@google.com> wrote:
> > I’ve taken a stab at enumerating possible types for CommandEvents.
> >
> > You can find the list at
> >
> https://docs.google.com/spreadsheets/d/11Gdl1fnVrEmxiT5dDOnBAwjnog2Xc43qOmFuXfekmUo/edit?usp=sharing
> >
> > I’ve categorized each command (Formatting, Insertion, etc), and merged
> > related commands (aka, Indent/Outdent) to simplify the list a bit.  The
> list
> > is includes more events that *should* be exposed as CommandEvents.  To
> > start, we can eliminate selection and clipboard events, as they should be
> > covered by ClipboardEvents and selection events (included in spreadsheet
> > just for completeness as they have corresponding execCommands).
>
> Agree that we don't need clipboard and selection for CommandEvent, and
> also that it's useful to keep them tracked.
>
> > Is this useful as a starting point? What other areas should be added?
>  Which
> > commands should be removed?
> >
> > Julie
>
> Yes, this is really useful! The main thing I want to add is the ability to
> do custom commands. This would allow sites/frameworks to implement things
> that aren't supported in a given browser, or functionality specific to a
> given site. My current thinking on this is
>
> document.execCommand('foo', {value:'bar'})
>
> would fire
>
> CommandEvent
> {
>         commandName: 'foo';
>         commandData: { value: 'bar' };
> }
>
> Which has no default action if a browser doesn't support the 'foo' command
> natively, but could be handled by the framework or site.
>

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'})?
Received on Thursday, 5 June 2014 18:16:35 UTC

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