[webkit-dev] New feature: Implement command API in webkit

[Ryosuke Niwa]

On Thu, Nov 24, 2011 at 9:32 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 24 Nov 2011, Ryosuke Niwa wrote:
> >
> > For example, the current design doesn't allow a single command be
> > associated with multiple UI components such as toolbar, pane, and
> > context menu because a command is defined at wherever UI component that
> > triggers the command.
> >
> > However, in practice, many web apps share the same command state across
> > multiple UI widgets such as toolbars and context menu. Take, "bold"
> > command as an example. "bold" command can be disabled or checked (i.e.
> > the selected text is in bold) and this state needs to shared across many
> > UI elements.
>
> Correct, though that is only a temporary limitation. I avoided adding this
> because I figured adding too much at once would cause implementors to
> avoid it. I'm happy to add it already if that is what it takes to get it
> implemented. :-) The idea is to add a command="" attribute which takes an
> ID and would then make the element defer to the element with that ID, so
> that you only need define the command once and then refer to it from the
> various places in the UI where you want to refer to it.
>

(At this point, we should probably move this discussion to public-html or
whatwg but I'll post it here for the sake of consistency)

That's an interesting idea. When Erik, Alex, and I were talking about this,
we thought each command can have a name and command content attribute can
refer to that.

One thing I really want to do is to tie command's name space with that of
execCommand since they already have useful functions like
queryCommandState, and queryCommandValue.

One big problem I have with the current design is that when a command can
take multiple values like foreColor, "checked" state doesn't make much
sense. In fact, we probably just need a generic "command value" that can
be coerced into boolean as needed (i.e. what queryCommandValue returns for
editing commands). Once we have that, whether a radiobox or checkbox is
checked or not can be determined by whether command value matches the value
or is boolean equivalent to true.

So I don't think command state should include checked.

> I also don't think UA should auto-generate toolbars as most of web apps
> > want to have a fine-grained control over the look and feel of their
> > toolbars.
>
> Agreed with the fine-grained control issue. I figured we would do that
> using pseudo-elements and component decorators, but I haven't specced
> anything out yet because those aren't ready yet.
>

I'm very skeptical that any author, especially those building web apps,
would start using menu + command if decorating them was harder than it is
today. I'd think that authors much rather keep command an abstract concept,
and define toolbars themselves.

Another big problem with the current design is modularity. We've got to
make sure any commands defined in a widget will not interfere (i.e. should
be unavailable or disabled, or even overridden by page's commands) with the
rest of the page.

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111124/3ea58fc1/attachment.html>