Re: Revisiting Command Elements and Toolbars

On 11/29/2011 07:58 AM, Ryosuke Niwa wrote:
> Hi all,
>
> I've been looking into the command element
> <http://dev.w3.org/html5/spec/Overview.html#the-command-element> and how
> a toolbar might be built
> <http://dev.w3.org/html5/spec/Overview.html#building-menus-and-toolbars> by
> them in the last several months.  In general, I'm thrilled to see this
> feature being a part of HTML5.  I've chatted with several Web developers
> internally at Google and also with some UA vendors before and during
> TPAC 2011 about various ideas to utilize command elements.
>
> Pros I found in the current spec:
>
>   * Commands can be defined where UI is provided
>   * Commands can be implicitly defined by accessKey content attribute
>   * Defining in terms of anchor element, etc... will allow nice fallback
>
> Cons (or at least ones I didn't think the current spec adequately address):
>
>  1. Authors often want to fine-grained control over the appearance of
>     toolbars; UAs automatically rendering them in canonical form will
>     make it harder.
I thought the idea was that the toolbar *could* be kind of part of the
browser chrome, in which case we don't want to let authors to style
everything. Icon and text should be hopefully enough.


>  2. In many web apps, commands are involved and associated with multiple
>     UI components, toolbars, side panel, context menu, etc... commands
>     being a part of UI components doesn't represent this model well.
There has been discussion about having abstract commands.
So, you could have <menuitem command="foo"> and <command id="foo" 
onclick="dosomething(event)"> (Shouldn't probably be onclick but
oncommand or such)
We should probably copy some more XUL functionality to command handling 
here, so that event listeners for <command> can access also the original 
event dispatched to <menuitem>.
(In XUL "command" events have .sourceEvent)


>  3. Many commands make sense only in the context of some widget in a
>     page. E.g. on a CMS dashboard, "bold" command only makes sense
>     inside a WYSIWYG editor. There ought to be mechanism to scope commands.
If focus is not in such special context, you could always disable the 
command.
I think it would be hard to make any automatic scoping, but handling it 
in script should be easy.


>  4. Mixing UI-specific information such as "hidden" and "checked" with
>     more semantical information such as "disabled" or "checked" isn't clean.
Not sure what you mean here.

>  5. Some commands may need to have non-boolean values. e.g. consider
>     "BackColor (as in execCommand), this command can't just be checked.
>     It'll have values such as "white" and "#fff".
perhaps command elements should have .value



>
> Furthermore, it seems unfortunate that we already have a concept of
> "command" in the editing API
> <http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html> and methods on
> document such as execCommand, queryCommandState, etc... yet commands
> defined by command elements and accessKey content attribute don't
> interact with them at all. It'll be really nice if we could use
> execCommand to run an arbitrary command defined on a page, or ask what
> the value of command is by queryCommandValue.
>
> What are your thoughts on this topic?

I wouldn't mix execCommand and command API.
It should be trivial enough to call execCommand etc in command
event listeners. queryCommandState shouldn't be hard either if one just 
updates things in focus/blur event listeners.

Perhaps command API should be renamed.
Maybe ActionTarget API or some such.



-Olli



>
> Best,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>

Received on Wednesday, 14 December 2011 19:47:27 UTC