[whatwg] Call for Clarification of the Menu Element Et Al.

[Hugh Guiney]

Hey All,

I was in the process of coding a prototype for a site I'm working on
when I decided that certain nav's should actually be menu's.

While the basic concept is apparent, unfortunately, with zero browser
implementation at this time, it is impossible to actually know what my
markup is doing (or rather, would do).

So I looked to the spec for guidance, but ultimately it leaves me very
confused. These are some points I feel could be addressed, in no
particular order:


1. How does one know whether to wrap a nested menu in li or leave it
as a direct child element? Are these semantically-equivalent "coding
styles" or is there a difference?

1.1. When marking up a menu specifically with *multiple* menu items,
is menu/li the only way to do it or would menu/menu also be
appropriate?

2. What is the difference between a menu containing command elements
and a menu containing form controls? Do they merely favor future and
legacy UAs respectively?

3. The spec should provide examples demonstrating when it is better to
use context vs. toolbar vs. list, as these are very similar in
concept. I could easily see them being misappropriated.

4. In the first example, what renders the button UI? Is it
menu[@type=toolbar]/li, or li/menu? Or is it implied CSS?

4.1. Furthermore, should this example even depict a button UI, given
that most graphical interfaces display top-level toolbars as
text/icons against a [mostly] solid background Were a UA to render the
example as demonstrated, would designers not have to style away the
button appearance in order to achieve a look & feel that matches user
expectation?

Obviously, this would not be the case in "secondary" (or n-ary)
toolbars, for instance as in word processors, where everything below
the initial row are usually buttons. Could there be a way, then,
whether in markup or CSS, to denote whether a toolbar is displayed as
a "primary"/"top-level" toolbar or not?

5. Provide more/graphical/clearer examples, to aid both browser
vendors in deciding how to implement the elements, and authors in
having an idea of what result they can expect from using them. The NPC
form, for instance, does not say exactly what it is or does, nor does
it represent a common UI convention. The only thing I can think of
that comes close is Spotlight in OS X (if I'm interpreting it
correctly), which I don't think I've ever seen in a [presumed] game
before.

6. How is the command element rendered within a menu context when
JavaScript is disabled? Is it meant only for non-essential actions? If
it isn't, shouldn't it be able to be non-empty, so it can fallback to
links or buttons? Or is the only possible fallback replicating every
command with form controls that aren't direct children of the parent
menu?

6.1 On that note, why is the spec enabling the use of unstyled spans
to achieve alternative rendering? Doesn't this give meaning (however
contextual) to an element that is supposed to be semantically neutral?

7. Is the menu element always to be rendered in-page or could it be
displayed within the OS itself? Kroc Camen
(suggests)[http://camendesign.com/blog/stop_this_madness] the latter
but at present there is nothing in the spec about such an
implementation. If this is left up to the UA how will developers know
how/if to style it without using browser detection?


Guidance, insight, reactions?

Thank you,
Hugh