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

On Fri, Jul 8, 2011 at 9:29 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> 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).

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.

I'll go ahead and answer the rest of your email as if you were
speaking from a hypothetical position, but take what I said into
account.  Using something pre-implementation doesn't help you, and it
has a chance of hurting the feature in the future.


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

Mostly, yes, though in some cases using form elements lets you define
certain types of commands more easily.  For example, you can use
<select> to define a group of type=radio commands more easily/tersely
than if you used <input type=radio name=foo> or <command type=radio
radiogroup=foo>:


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

"context" is meant for right-click menus, hooked to an element by
specifying the @contextmenu attribute on an element and pointing it to
the <menu>.  Note that the default CSS of a <menu type=context> is
display:none.

I don't really understand the difference between "toolbar" and "list".


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

Implied CSS or UA magic.


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

This is something that'll be worked out as browsers actually implement things.


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

Patches welcome.  ^_^  Any suggested examples?


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

If you're designing something to be a context menu, it likely won't
work at all without Javascript.  You'd need a significantly different
UI.


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

Slightly.  I don't think it's a big deal, but shrug.  Note that *any*
element would work there to hide the submit button from the "build a
menu" algorithm.


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

This is another thing that'll be worked out as browsers implement.

~TJ

Received on Monday, 11 July 2011 11:03:35 UTC