W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Revisiting Command Elements and Toolbars

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Mon, 28 Nov 2011 21:58:17 -0800
Message-ID: <CABNRm637UHVpP1Wc8qwD1s1_EQpOPhsfT2gS+2fgP0Bog7MV_w@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
Cc: Erik Arvidsson <arv@chromium.org>, Alex Russell <slightlyoff@chromium.org>, tantek@cs.stanford.edu, Ehsan Akhgari <ehsan@mozilla.com>, Enrica Casucci <enrica@apple.com>, Florian Rivoal <florianr@opera.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>, Aryeh Gregor <ayg@aryeh.name>
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.
   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.
   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.
   4. Mixing UI-specific information such as "hidden" and "checked" with
   more semantical information such as "disabled" or "checked" isn't clean.
   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".

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?

Best,
Ryosuke Niwa
Software Engineer
Google Inc.
Received on Tuesday, 29 November 2011 05:59:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT