[whatwg] Menus, fallback, and backwards compatibility: ideas wanted

Lachlan Hunt wrote:
> Matthew Raymond wrote:
>>>>| <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.
>>
>>   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 
> navigational menus.

   I would agree, with one condition: The <label> must be inside the
<cmd> element.

>>>3. <cmd>
>>>    <label>Jump to <select/></label>
>>>    <button>Go</button>
>>>  </cmd>
>>
>>   This is fine.
>>
>>>4. <cmd>
>>>    <label for="jump">Jump to</label>
>>>    <select id="jump>/>
>>>    <button>Go</button>
>>>  </cmd>
>>
>>   Same here.
> 
> 
> They're the ones I preferred too.

   Note that we could also do something similar to this:

| <form ismenu>
|   <label for="jump">Jump to</label>
|   <select id="jump>/>
|   <button>Go</button>
| </form>

   Just a thought...

   There's something that still just bugs me about <cmd>, and it's not
the name, because actually I'm starting to warm to that. What bothers me
is that we have an element specifically designed to convert markup
content into WA1 content without serving any other function. As a
result, the markup will become obsolete once WA1 is widely in use
because people will start directly using the standard menu markup.

   Hmm, then again, do we currently have a way of submitting a form with
current <menu> markup? Let's see...

| <form>
|   <menu>
|     <li><button type="submit"></button></li>
|     <li><input type="submit" value="Item 2"></li>
|     <li><input type="submit" value="Item 3"></li>
|   </menu>
| </form>

>>   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:
> 
> <menu>
>    <cmd>
>      <label>File <select name="file"/></label>
>      <button name="menu" value="file">Go</button>
>    </cmd>
>    <cmd>
>      <label>Edit <select name="edit"/></label>
>      <button name="menu" value="edit">Go</button>
>    </cmd>
>    <cmd>
>      <label>View <select name="view"/></label>
>      <button name="menu" value="view">Go</button>
>    </cmd>
> </menu>
> 
> That might be rendered like this:
>   _____________________
> |File  Edit  View     |
> |---------|___________|
> | New...  |
> | Open... |
> |_________|

   That's not a menu. It's a MENUBAR. You should be using <menubar> as
the parent element. Otherwise, you could do the whole thing with a <div>
and CSS and wouldn't need the <menu> at all. We don't need a special
case of <menu> to display buttons next to each other in a row.

| <div class="fakebar"><cmd/><cmd/><cmd/></div>

>>   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:
> 
> <menu>
>     <cmd>          <!-- Menu command item -->
>       <label/>     <!-- Label for command menu -->
>       <select/>    <!-- The menu items -->
>       <button/>
>     </cmd>
>     <li>           <!-- Menu list item (e.g. navigational list) -->
>       <menulabel/> <!-- Label for nav menu -->
>       <menu/>      <!-- The menu items -->
>     </li>
>     <li><a href=""/></li>
> </menu>
> 
> Requiring an li around <cmd> would just be extra markup for no good reason.

   A "menu command item" is just as much a list item as the
<menulabel>/<menu> combination and therefore should be in an <li>.
Here's both the <cmd> and the <menulabel>/<menu> pair at the root level:

| <cmd>
|   <label/>   <!-- Label for command menu -->
|   <select/>  <!-- The menu items -->
|   <button/>
| </cmd>
|
| <menulabel/> <!-- Label for nav menu -->
| <menu/>      <!-- The menu items -->

   Note that <menu> and <menulabel> are not the children of an <li>,
just like <cmd>, yet they are excluded from being direct children of
<menu>. That's inconsistent.

   Furthermore, <li> part of the fallback markup. Without it, the
<select> menu doesn't have the same presentation as the other items.
Worse is that all the elements in <cmd> default to being inline, so they
 all stack up on the same line if you don't use an <li>. If you don't
believe me, copy and paste this to a file at try it for yourself:

-----
<menu>
  <cmd>
    <label for="foo1">Item 1</label>
    <select id="foo1"></select>
    <button>Go</button>
  </cmd>
  <cmd>
    <label for="foo2">Item 2</label>
    <select id="foo2"></select>
    <button>Go</button>
  </cmd>
  <li>
  <menulabel for="bar">Item 3</menulabel>
  <menu id="bar"></menu>
  </li>
  <li><a href="">Item 4</a></li>
</menu>
-----

   The <li> element will always be needed for fallback situations, and
we need it for consistency in non-fallback situations, so why not just
require it's use?

> 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 
>>   happens.
> 
> 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 
> XHTML documents.

   Yeah, you can't really get around a <menubar> element if you want an
actual integrated menubar...

Received on Friday, 2 December 2005 08:51:03 UTC