[whatwg] Looking at menus in HTML5...

[Ian Hickson]

On Tue, 7 Aug 2007, Andrew Fedoniouk wrote:
> 
> Pure text? Why?

With HTML5 we're following a design principle of not biting off more than 
we can chew at once -- so the initial design is intended to be very 
conservative.


> As an example see first image ont the right at: 
> http://en.wikipedia.org/wiki/Pie_menu

The current HTML5 design supports pie menus -- the menu should be 
presented in whatever fashion is considered native to the OS. If the OS 
uses pie menus, then that's what should be used. Nothing in the HTML5 spec 
requires that the menu be your typical vertical list of items.


> There are many cases when menus are not just flat lists of items.
> Examples: Start menu in Windows contains as menu items as buttons,
> see: http://en.wikipedia.org/wiki/Start_Menu
> And gnome:
> http://reverendted.wordpress.com/2006/06/17/show-me-that-new-gnome-main-menu/
> and KDE:
> http://photos1.blogger.com/x/blogger/938/4204/1600/471459/menu.png

These aren't context menus, so they're not really in scope for this 
feature.


> As you may see above, Windows XP/Vista, Gnome and KDE4 all use rich 
> menus. So it is not RiscOS only.

The three menus you mention above are all examples of a specific OS 
launcher menu, they're not context menus. The feature under discussion is 
currently intentionally limited in scope to just context menus.


> And in modern web applications typical implementation of menu compnents
> provide rich menu constructions.
> Example
> http://www.telerik.com/demos/aspnet/Menu/Examples/Overview/DefaultCS.aspx.

Indeed, colour selection is something we might well do in a future 
version, as are menu buttons or toolbars with drag-down button sets. 
(Everything else on that page can already be done with the spec as is.)


> So I would not restrict menus in the way it is done in HTML5 now.
> It is enough that we have so limited <select>.

While your enthusiasm for flexibility is commendable, we are intentionally 
limiting the speed at which we add features to HTML5 to prevent feature 
creep. Feature creep is often the cause of poor quality implementations. 
We have to move slowly so that we can take into account implementation 
experience from multiple vendors (especially those with significant market 
share), and so that we can make sure we are addressing the most desired 
features instead of only the most unusual ones.


> Personally I think that menu functionality is a part of CSS
> specification, something like:
>   menu { position: popup }
> should allow to define menus as popup elements if needed.

Indeed, such a feature might well be necessary to support menus and popup 
controls in XBL. I recommend bringing this up to the CSS working group.


> > I'm just talking about the menu item mnemonics, not the shortcut keys. 
> > The shortcut keys are part of the bigger accesskey problem for which 
> > we don't even have the start of a solution yet. Whatever solution we 
> > find for accesskey will just be folded into the command and menu 
> > features.
> 
> Mnemonics in menu items is a very old concept. I doubt that people are 
> using them for selecting menu items.

That's quite possible, but it doesn't affect the specification, since the 
mnemonics are simply left up to the implementation, which can simply 
ignore them if they decide they are not necessary.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'