On Fri, Jul 8, 2011 at 9:29 PM, Hugh Guiney hugh.gui...@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
