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

[Ian Hickson]

On Sat, 9 Jul 2011, Hugh Guiney wrote:
> 
> 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?

There is no difference. It's only a matter of what you want the fallback 
to look like in older browsers.


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

Nested menus means submenus.


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

There's no difference except <command> doesn't show in old browsers. 
(Which might be good or might be bad depending on what you want.)


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

Well you'd use a context menu when you want a context menu, and a toolbar 
when you want a toolbar... those seem pretty clear. :-)

The "list" feature is just for backwards-compatibility, it's not really 
needed.


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

Not sure what you mean.


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

Theoretically, the styling here is expected to be done via CSS 
pseudo-elements.


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

Adding items to context menus seems like a pretty well-understood 
convention; could you elaborate on why this example is confusing?


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

You can use form controls (no <command> at all) when you want fallback.


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

Not sure what you mean.


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

The goal for toolbars is for them to be in-page.


On Mon, 11 Jul 2011, Tab Atkins Jr. wrote:
> 
> Really, since there are no browser implementations yet, it's best to 
> *not* use it yet.  Without any feedback in the form of actually seeing 
> it work, there's a good chance you'll accidentally get it wrong.  As 
> well, your early use of it counts as legacy usage if we decide that, 
> upon attempting to implement it, it needs to be changed.

Indeed.

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