[whatwg] [WA1] Quick thoughts on menus.

[Ian Hickson]

On Sun, 16 Oct 2005, Matthew Raymond wrote:
>
> [...] Also, my model doesn't allow menus to be displayed via a 
> hyperlink. Displaying menus via hyperlink would introduce weird 
> situations like bookmarking menus and referencing menus outside the 
> document. While it may be possible to create a set of rules to deal with 
> these various problems, I believe my <menulabel> solution to be far 
> simpler and easier to learn. [...]

I'll take a closer look at this in a few months when I rewrite the menu 
section, but I just wanted to jump in here to give some context for people 
who do wish to come up with a better model than what is currently in the 
spec (and heck knows we need one).

There are several key things that this part of the spec is trying to 
achieve, and several things which are "nice to haves" which we should aim 
for but which should not constrain the design.

Requirements:

 * The design should be related to the way people do DHTML menus on sites 
   today. Either it should be possible to easily annotate existing markup
   and get native menus out of them, or it should be possible to easily 
   get older UAs to render the new menus in the old way, or something of 
   a real migration story.

 * Same with the way people do <select> menus.

These two points are the cause of the way the current proposal handles <a> 
and <select> specially.

 * It must be possible to do context menus with this system. This implies 
   getting data like mouse X/Y position, getting target element 
   information, having a way to update the context menu based on where it 
   was called from, etc.

This is really badly handled at the moment.

 * The feature must support a way to keep toolbar buttons and menu items 
   in sync regarding things like disabled state, radio button selection, 
   icons, etc.

This last requirement is the source of <command> et al. IMHO this works 
reasonably well as currently specified.

 * A balance between ease of authoring, ease of implementation, ease 
   of specification, ease of testing, etc.


Nice to haves:

 * It could be possible to have a stand-alone HTML "document" that has a 
   native menu bar in stand-alone mode, and have that same document work
   fine in a non-trusted environment (i.e. a Web browser content area).

<menubar> was supposed to help with this, but IMHO fails to do it in a 
sane way.

 * It should be possible to have this fallback to a sane rendering even in 
   Lynx, where instead of scripting to do the commands, you'd have a list 
   of items and have things happen server side.

This was the thinking behind using <menu> <li>.

 * Should be possible to share menus, e.g. to have one drop-down menu 
   shared between a toolbar button and a context menu without having to 
   list it twice.

The current proposal does this, though not that intuitively IIRC.

 * Should be possible to have menus drop down from buttons (the way that
   <select> is often abused today for doing commands, e.g. in GMail; 
   this kind of UI is seen a lot in native applications on all platforms).

I don't remember if this is possible in the current proposal.


Non-requirements:

 * Script-free. There's no reason to design this in a way that it doesn't 
   require script somewhere to do it. (Though of course, cutting down on 
   script is always good if it is replaced by something simpler.)

 * Replicate every feature of every OS in the first version.

 * Having arbitrary form controls in menus.

 * Introducing no new elements. It's ok to introduce new elements.


Let me know if you have any questions.

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