[whatwg] [WA1] Quick thoughts on menus.
ian at hixie.ch
Sun Oct 16 13:05:21 PDT 2005
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.
* 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,
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
* 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.
* 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg