W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: Revisiting Command Elements and Toolbars

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 15 Feb 2012 00:30:07 +0000 (UTC)
To: Ryosuke Niwa <rniwa@webkit.org>
cc: public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1202150024330.11170@ps20323.dreamhostps.com>
On Mon, 28 Nov 2011, Ryosuke Niwa wrote:
> 
>    1. Authors often want to fine-grained control over the appearance of
>    toolbars; UAs automatically rendering them in canonical form will make it
>    harder.

For now, authors who don't want the automatic formatting can just get the 
current formatting using <menu> without a type="" attribute. They don't 
get any of the magic they would get with type=context.

Going forward, I think we should define a way to style <menu type=toolbar> 
controls, but I really don't know how to do that. Pseudos? Rely on the Web 
Component model? Special properties? I'm open to ideas here.


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

I've finally added the command="" attribute to allow <command> elements to 
defer to another element.


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

Not sure what you mean. In what sense are commands not scoped?


>    4. Mixing UI-specific information such as "hidden" and "checked" with
>    more semantical information such as "disabled" or "checked" isn't clean.

"hidden", "disabled", and "checked" all seem "semantical". I agree that 
"icon" should be in CSS; the CSS 'icon' property should really be the 
authoritative source here. However, people often have a particular icon 
per command/menu item/button/whatever so I think it makes some sense to 
put them together.


>    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".

Yeah. I haven't added this yet. I expect we'll leverage the new form 
widgets for this kind of thing.


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

I don't really see the link between the two. <command> is about the 
widgets. execCommand() is about the editor process. You would implement 
<command> actions in terms of execCommand() in an editor, but they are 
otherwise completely unrelated as far as I can tell.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 15 February 2012 00:30:30 GMT

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