Matthew Raymond wrote:
Lachlan Hunt wrote:
No, command in the current spec represents an abstract form control for
sharing features among several real form controls.
The <command> element is most certainly not a form control, since it
can't be submitted
I know that, I said *abstract* form control, though perhaps I should
have omitted the word "form".
AIUI, the difference between them can be illustrated as follows:
<menu>
<cmd> <!-- Menu command item -->
<button/> <!-- [Label] for command menu -->
<select/> <!-- The menu items -->
</cmd>
<li> <!-- Menu list item (e.g. navigational list) -->
<menulabel/> <!-- Label for nav menu -->
<menu/> <!-- The menu items -->
</li>
</menu>
You're mistaken. The <button> caption actually isn't the menu label
in many cases.
Since the button itself wouldn't actually be visible in WA1 UAs, it's
really only there for fallback, why can't it be used as the menu's label?
You would only use the button for submission. Here's a
stripped down version of what Ian has on his weblog:
| <form action="./" method="get">
| <p>
| <label>
| Jump to
| <select name="start"/>
| </label>
| <input name="order" value="-1" type="hidden">
| <input name="count" value="5" type="hidden">
| <input value="Go" type="submit">
| </p>
| </form>
Also, as you point out, the <input> element could be used instead. So
you'd need either a <label> or child text, as you see Ian using above.
Why? <input type="submit"> is still a button, what difference does it
make from the button element?
But, if you really don't like overloading the use of the button as the
menu label as well, then I guess we could add a label, but I think just
using the button itself has the advantage of less markup and if the
button isn't required to get the menu, authors won't bother including
it, which reduces accessibility.
| <menulabel for="menu1">Label Text</menulabel>
| <menu id="menu1">
| <select/>
| <button/>
| </menu>
We already have <label> for form controls, I don't think we need a new
element for that especially when it's basically still associating a
label with a form control. I also think you're overloading the use of
the menu element too.
Do you like the structure of any of these alternatives? (with the actual
element names still up for discussion)
1. <cmd>
<button>Jump to</button>
<select/>
</cmd>
2. <cmd>
Jump to <select/>
<button>Go</button>
</cmd>
3. <cmd>
<label>Jump to <select/></label>
<button>Go</button>
</cmd>
4. <cmd>
<label for="jump">Jump to</label>
<select id="jump>/>
<button>Go</button>
</cmd>
5. <cmd>
<label>Jump to <select/> <button>Go</button></label>
</cmd>
6. <label>
<cmd>Jump to <select/> <button>Go</button></cmd>
</label>
7. <label for="jump">Jump to</label>
<cmd id="jump">
<select/>
<button>Go</button>
</cmd>
Hmm... Is there really a use case where we'd be using <select>
elements for submenus?
Not that I can think of, but select elements could have submenus using
the optgroup element, as currently described in the spec.
Not menus, mind you, but menus within menus. If not, then we could
drop <cmd> from the list of possible children for <menu> while
keeping the element itself.
I don't understand your logic behind this.
| <menu>
| ...
| <command/>
| </menu>
Why does <command> need to be a child of menu at all? It's really more
of an abstraction, rather than a physical control for the user to use.
Wouldn't it be better for them to be declared within the <head> or early
within the <body> and then referenced by other controls as needed?
--
Lachlan Hunt
http://lachy.id.au/
