[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
lachlan.hunt at lachy.id.au
Fri Dec 2 05:28:09 PST 2005
Matthew Raymond wrote:
> Lachlan Hunt wrote:
> You could use the <button> as a menu label if the <label> is absent,
> but the web author should not be required to use the <button> as a
> label, because that forces them to use inferior fallback. The button as
> a label in a fallback scenario just doesn't seem that common to me.
Good point. Agreed, we need an explicit label, but using the button
text is ok if the label is not present (if that's possible for
implementations to do).
>>>| <menulabel for="menu1">Label Text</menulabel>
>>>| <menu id="menu1">
>>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.
> The <menulabel> is associated with a menu, so unless you have a
> opposition to that, I don't see your point. It can be argued, however,
> that the overloading of <menu> is undesirable, I agree.
My point is that this command menu is basically made up of a label, a
select control and a button, and that we already have a <label> element
for associating with select elements. Therefore, we don't need to use
another type of label element for that. <menulabel> is fine for
>> <label>Jump to <select/></label>
> This is fine.
>> <label for="jump">Jump to</label>
>> <select id="jump>/>
> Same here.
They're the ones I preferred too.
>>>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.
> If there isn't a use case for having <cmd> as a direct child of
> <menu>, why allow it to be the direct child of <menu>??? Furthermore, if
> <cmd> supports multiple submenu levels, you can just use it for the
> whole menu structure rather than a submenu. (Or, <cmd> could be require
> to be a child of <li>. See below.)
I thought there was a use case, where cmds as direct children of a menu
element would form the menu bar, and the select/button elements would
form each individual menu:
<label>File <select name="file"/></label>
<button name="menu" value="file">Go</button>
<label>Edit <select name="edit"/></label>
<button name="menu" value="edit">Go</button>
<label>View <select name="view"/></label>
<button name="menu" value="view">Go</button>
That might be rendered like this:
|File Edit View |
| New... |
| Open... |
> Hmm. In that case, could we just require <li> like we do for <ul> and
> <ol>? Perhaps even replace <menu> with <nl>, making it more like the
> XHTML 2.0 element?
That would be an alternative, but <menu><li> is already supported by
existing UAs. I wouldn't mind requiring li for content other than cmd,
since we already use it within ul for menus, and other than reduced
markup, I see no other benefit in leaving it out.
That would make the content model for menu look somethink like this:
<cmd> <!-- Menu command item -->
<label/> <!-- Label for command menu -->
<select/> <!-- The menu items -->
<li> <!-- Menu list item (e.g. navigational list) -->
<menulabel/> <!-- Label for nav menu -->
<menu/> <!-- The menu items -->
Requiring an li around <cmd> would just be extra markup for no good reason.
Earlier, Ian Hickson wrote:
> 1. Providing a menu bar for the entire window (or application, on Mac), so
> that the application can be a native-like application. This, IMHO, is
> out of scope for HTML5 and should maybe be revisited in HTML6 by
> whoever does the work on taking HTML out of the browser, if that ever
I just had a thought that maybe this could be marked up by including the
<menu> within the <head> element, since the content of the head element
contains metadata applying to the whole document, and an application
menu bar applies to the whole application, it makes sense for such a
menu to be marked up like that. However, this would only be possible in
More information about the whatwg