- From: Hugh Guiney <hugh.guiney@gmail.com>
- Date: Sat, 9 Jul 2011 00:29:03 -0400
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
Received on Friday, 8 July 2011 21:29:03 UTC