[whatwg] Menus and Toolbars

Wed Nov 28 11:46:35 PST 2012

Greetings,

I'm not a browser implementor, but I have been dealing quite a bit with
menus and other GUI stuff from the web development perspective; so here it
goes some comments I hope implementors might find interesting:

I have put a first example on http://std.dragon-tech.org/mainmenu.png
All you can see there is doable with plain CSS and HTML. It doesn't even
use any CSS3 features. In fact, the whole thing works fine in IE8.
As Fred Andrews mentioned, menus are quite easy to achieve with no
scripting, as long as one stays within "hover-based" menus.
Of course, most of the buttons and items in the screenshot require JS to
actually do anything, but that's because of the app's own complexity.
All the stuff in that window should be pretty much accessible (everything
in there are ul's, li's, and img's with matching @alt and @title for the
toolbar, which contains only shortcuts anyway, and load's of @onclick
attributes that could be easily replaced by <a>'s with @href's on a more
"web-ish" scenario).

In summary, menu bars and tool bars are quite a solved problem

Now, here is when stuff gets serious:
http://std.dragon-tech.org/contextmenu.png
To be honest, I hate most of the code behind that with a passion... and I
wrote it! I get paid for making stuff work, and thus I make stuff work, no
matter what it takes.
The context menu requires JS to display at all. It "overrides" the
browser's native menu (which sometimes would be useful). There is a huge,
empty, transparent div covering the whole iframe (the main area on the
screen with the table on it) just so it can catch clicks and dismiss the
menu. The "context menu key" (that nice thing between right Ctrl and the
"Windows" key) doesn't do anything (doesn't trigger neither my menu nor the
browser's) when the iframe has focus.
Don't get me wrong, I quite love what I pulled off, and so do most of the
app's users; but I loathe the truckload of crap code I have to feed the
browser for everything to work as intended.

So, in summary, context menus are somewhat achievable with significant
scripting, some creativity, and epic x-browser patience; but it's still a
problem far from solved.

----

As a web developer, what I'd love to see implemented natively would be:

* A mechanism (most probably an attribute + a CSS pseudo-class, or maybe
even recycling :hover) to show click-based menu bars some script-less love.
* A mechanism to deal with context menus in a sane way. It all boils down
to UA's natively handling the showing and dismissing of the menus; and
maybe enabling a mechanism to define a default (did you noticed the bolded
option at the start of the menu on the screenshot? Yay, double-clicking
instead of right-clicking does invoke it, skipping the whole "show the
menu" step! ). That would cause it to work with any native method the
browser or platform already supports for displaying context menus.

As a user, I would hope any context menu implementation grants me the
ultimate control on which menu is used (native vs. app-provided).

Of course, other users, authors, and developers may have other needs, but I
can only talk about the ones that I know about.

Re-capping, my needs could be solved with this (element and attribute names
are meant to be verbose and descriptive, not practical nor "final"):
- A @enable-toggling-hover-state-by-clicking attribute.
- A <context-menu> or similar element, plus a mechanism to "bind" it to
other elements on the page. As long as the browser deals with show/dismiss
logics, I could handle everything else. If it had a @default-action
attribute that would be great, but I could live without it (or, more
likely, toss in a @data-* attribute, and loop through elements bound to the
menu to hack in the double-click handlers).

Regards,
Eduard Pascual

On 28 November 2012 01:12, Ian Hickson <ian at hixie.ch> wrote:

>
> (If you're cc'ed, your opinion likely affects implementations of this and
> so your input is especially requested. See the question at the end. If you
> reply to this, please strip the cc list as the mailing list software will
> otherwise block your post for having too many cc's. Thanks.)
>
> There's a big section in the spec that tries to do three things:
>
>  * context menus
>  * toolbars
>  * menu buttons
>
> Right now it's not implemented by anyone, though Firefox has a variant.
>
>    http://whatwg.org/html/#the-menu-element
>
> This section has two big problems:
>
> 1. Styling of toolbars and menu buttons is just not defined.
>
> Toolbars could be a purely stylistic issue, to be solved either excluively
> by CSS, or CSS plus a component/widget binding model (whatever solution we
> end up with for that).
>
> Menu buttons are a real widget, though, so we can't just leave them to CSS
> styling of <div>s, there needs to be some real styling going on. Right
> now, because of the algorithm mentioned in #2 below, this is very
> complicated. I'll get back to this.
>
> (Styling for context menus is not a big deal, they just use native UI.)
>
>
> 2. Nobody is implementing it, in particular, the algorithm that converts
> HTML elements into a menu structure seems unpopular.
>
> Right now, the spec has this algorithm that defines how to map existing
> HTML semantics to a context menu or menu button (or toolbar, though the
> latter is less important if we move to a pure-CSS rendering model for
> toolbars, since we'd just drop the algorithm for them then).
>
> The idea here is that you don't have to use JavaScript to replicate the
> effects of existing semantics. For example, if you want a menu button
> which acts as a navigation mechanism, you just put <a> elements in your
> markup and they automatically get turned into menu items.
>
> There's also a generic <command> element for when you don't need an
> existing element to be used. Firefox essentially only implements this,
> though it's called <menuitem> in Firefox. <command> also supports an
> attribute that points at other elements to indirectly define features.
>
>
> To move forward on this, here are some proposals:
>
> #1: Drop <menu> and all related features. I don't think we should do this,
> but if we can't get agreement on what to implement, this is the only
> option left, so it's on the table.
>
>
> #2: A design that supports context menus and menu buttons using dedicated
> markup, with support for indirect defining of commands.
>
> First, we make <menu type=""> take three values: "toolbar", which just
> means to render the element using CSS (the default value for legacy pages,
> too), and "context" and "button", which define menus. "context" menus
> would be hidden by default, "button" menus would render as a button,
> which, when clicked, shows the menu. contextmenu="" can be used to point
> to a <menu type=contextmenu>.
>
> The <menu> element in "context" and "button" modes would only have three
> elements as descendants: <menuitem> elements, <menu> elements, and <hr>
> elements. (Or maybe no <hr>s, and we do separators by using groups of
> <menu> elements without labels.) Other children are ignored.
>
> <menuitem> elements would just have a label="" attribute and, optionally,
> a command="" attribute. The command="" attribute would work as it does in
> the spec now, deferring to some existing element. When the menu item is
> selected, it would fire click on the <menuitem>, and then as a default
> action do whatever the action of the command="" is, if specified. (We can
> talk about whether to bother supporting icons in the <menuitem>, and if so
> how, especially given high-res screens, but that's a minor detail.)
>
> With type=button, CSS would apply to the <menu> and <menuitem> elements,
> maybe with a limited set of properties applying. Long term, we look to XBL
> or Web components or whatever for styling.
>
> We drop <command> entirely.
>
>
> #2a: Same as #2, except we keep <command> as a way to introduce commands
> without using existing elements.
>
>
> #3: We forget the non-JS case; so, the same as #2, but <menuitem> doesn't
> get a command="" attribute. We add radio menu items, checkbox menu items,
> and the like, over time, as features on <menuitem>. (Defined much like
> <command> has some of them defined today.)
>
>
> #4: We do what the spec has now.
>
>
> #5: We do what the spec has now, except we change the type=toolbar to just
> be rendered in CSS (and remove type=list, making toolbar the default).
>
>
> #6: Your idea here.
>
>
> So, implementors: Which of these would you be willing to implement? Are
> there constraints I've not thought of? Are there features that we need to
> deal with that I haven't mentioned above? Are there use cases that we
> should just abandon that could simplify the solution drastically?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>