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. `._.-(,_..'--(,_..'`-.;.'
