W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2007

[whatwg] Looking at menus in HTML5...

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 7 Aug 2007 12:01:26 -0700
Message-ID: <000001c7d927$14aca840$f502000a@internal.toppro.net>

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


> On Mon, 6 Aug 2007, Andrew Fedoniouk wrote:
>> > >
>> > > Pay attention on "Third option - submenu". It contains additional
>> > > markup and/or styling.
>> >
>> > Assuming you mean for the boldened letters to represent the
>> > accelerator key, the idea is that you don't have to give them at all,
>> > the user agent will determine the optimal accelerators.
>>
>> That was just an example.
>>
>> I mean that either you allow all menu items to have arbitrary markup or
>> all of them should have plain text only model (so be an <option>).
>
> All the menu item labels are pure text. See the definitions in the section
> on how commands are defined ("3.18.5. Commands"). Any included markup gets
> flatted out and is really only allowed for fallback purposes.

Pure text? Why?

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

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

Simplistic flat menus is an outdated concept in UI - limitations of initial 
implementations
when there were simply no way to define more or less rich content in 
resource files.
All modern OSes use more flexible layouts of menus.

In principle menu is a short living window running so called
mouse-modal-loop. There is no technical limitations to limit
its content by just flat lists. Especially in context of Web Application
that supposed to mean thing that have modern and rich UI.

>
>
>> In real UI there are cases when menu even contains input elements:
>> http://terrainformatica.com/htmlayout/images/css-menus.png - so may have
>> arbitrary markup.
>
> The current spec supports checkbox and radio button menu items; further
> types are quite rare and I don't think we should support them in this
> version of the specification. (We can always extend the specification at
> some later time.) (The only GUI I am aware of that condones text fields in
> a menu would be the graphical RiscOS shell, and the other UI concepts
> shown in that screenshot are extremely rare and we could probably get away
> with never supporting them.)

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

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.

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


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.

>
>
>> Menu items even can be organized as a table (<td role=menu-item>) :
>> http://www.terrainformatica.com/htmlayout/images/popupdemo.png
>
> IMHO that's a separate widget, not a context menu. I would expect such a
> UI to be built using XBL or a new widget in a future version of HTML.
>
>
>> > > How you would achieve this with the @label?
>> >
>> > You don't need to bolden the letters, so it all Just Works.
>>
>> Sorry but I am not so optimistic. You cannot build optimal shortcut
>> system deducing only captions. Think about cut/copy/paste/select-all
>> menu items written in different languages.
>
> 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.  They used to be actual for
UI scripting/automation when sending of keystrokes was the only
way to activate some function/command from the code.
Do you know anybody who is using mnemonics for menu item activations
these days? Especially in web apps that are primarily occasionally used
and highly dynamic things - you literally cannot remember all keystroke
sequences for particular functions in all sites you are visiting. In 
contrast
rich menus with inline descriptions and proper organization will help
you significantly more to get what you need in application that you use
say at the end of the month to do your online banking or so.


Andrew Fedoniouk.
http://terrainformatica.com
Received on Tuesday, 7 August 2007 12:01:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:36 UTC