[whatwg] Looking at menus in HTML5...

[Andrew Fedoniouk]

----- Original Message ----- 
From: "Ian Hickson" <ian at hixie.ch>
To: "Andrew Fedoniouk" <news at terrainformatica.com>
Cc: "WHAT WG List" <whatwg at whatwg.org>
Sent: Tuesday, August 07, 2007 1:52 PM
Subject: Re: [whatwg] Looking at menus in HTML5...


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

I think that

<menu type="context-menu">
   <li>Copy<kbd>Ctrl-C</kbd></li>
</menu>

is conservative enough as it allows me to define typical menus.

All modern UAs have their own implementation of menus
so they already can "chew" menu items with markup and styling.

Otherwise <menu> should not use <li> but <option> or so.
But this will not be backward compatible.

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

Do you have definitions on what is context menu and what is not?
Do you have any examples of exisiting web applications that will
benefit significantly from having that flat puristic context menus?

Almost all real cases when context actions are needed are perfectly
handled by side bars with list of links. So why bother?

So where this context menu feature request comes from?

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

BTW: Everything there works already without any HTML5.

I believe that HTML5 goal is to provide more or less
generic solution that can serve as simple menus *and*
cover the whole class of popup elements and lightweight
dialog needs.

Otherwise we will end up with spending rest of our life
adding that endless <menu>, <rich-menu>, <popup>,
<dialogue>,<monologue>, <novel>, <poem>,
<haiku>, whatever....

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

It is not an enthusiasm but rather frustration of where this thing is 
moving.
As I said, proposed <menu> is not a solution. Just a cosmetic and
limited feature that will solve some pretty small number of cases. If any.

In any case I would like to know examples of existing web applications
that such non-styleable menus.

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

XBL is using primitives of DOM and CSS.
So yes, if you will be able to define this in HTML/CSS then
you can use XBL(Gecko) or HTC (IE) or some other
technology of this kind.

Andrew Fedoniouk.
http://terrainformatica.com