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

Sat Dec 3 03:57:29 PST 2005

Anne van Kesteren wrote:
> Another idea I had was to make the first <option> element when it has a
> particular ancestor element a label. So instead of saying it explicitly 
> it gets
> its semantics from where it appears.
> 
> <cmd>
>   <option>this is the label
>   <select>
>    <option>this is not
>   </select>
> </cmd>

I don't see why we can't just have <cmd> be a "command menu" and use
<menulabel> for it:

| <menulabel for="foo"><label for="sel1">Menu Label</label></menulabel>
|
| <cmd id="foo">
|   <select id="select">
|    <option>Item 1
|    <option>Item 2
|    <option>Item 3
|   </select>
|   <button>Go</button>
| </cmd>

   Without fallback, this would be the following:

| <menulabel for="foo">Menu Label</menulabel>
|
| <cmd id="foo">
|  <option>Item 1
|  <option>Item 2
|  <option>Item 3
| </cmd>

   I've got a better idea, though. If we're trying to make <cmd> similar
to <datalist>, why not just use <datalist>?

| <menulabel>
|   <label for="bar">Label for Menu</label>
|   <menu list="foo"/>
| </menulabel>
|
| <datalist id="foo">
|   <select id="bar">
|     <option>Item 1</option>
|     <option>Item 2</option>
|     <option>Item 3</option>
|   </select>
|   <button type="submit">Go</button>
| </datalist>

   As you can see, <menu> uses the |list| attribute from Web Forms 2.0
to load data from a <datalist>. Since <menulabel> is associated with a
<menu> element, there's no change in its semantics. With the exception
of the <button> element, the use of <datalist> is pretty much how it is
used in WF2.

> ... or:
> 
> <cmd>
>   <select>
>    <option>this is the label
>   </select>
> </cmd>

   We're running into too many possible sources for adding labels. If
you include this we have:

* A child <option>.
* The first <option> in the child <select>.
* A child text node.
* A child <label> node.
* A child <button>.

   I think it's cleaner to just have a <menulabel> associated with the
<cmd> and treat <cmd> like a type of menu. As you saw above, the
fallback is not difficult (though perhaps a little heavy on the markup).

>>So we've completely reinvented <menu><select/></menu>, only using
>><cmd> as the parent instead. Why not just return to using
>><menu><select/></menu> then?
> 
> As noted earlier in this thread <cmd> was just some random name that has to be
> replaced at some point, not? Anyway, I think <menu> should be reserved for
> dropdown lists, but I don't feel strongly about that.

   With the use of <datalist>, I don't see a point in having separate
markup for various menu types. You only need specialized markup for the
specific areas where they are different:

For menu bars:
| <menubar>
|   <menulabel>
|     Menu 1
|     <menu/>
|   </menulabel>
|   <menulabel>
|     Menu 2
|     <menu/>
|   </menulabel>
| </menubar>

For command menus:
| <menulabel>
|   Command Menu Name
|   <menu/>
| </menulabel>

For context menus:
| <textarea name="ta1" context="foo"></textarea>
| <menu id="foo" label="edit"/>

   Without the <option> element to worry about, and with a version of
<command> that goes in the <head> instead of a <menu>, we can limit the
immediate children of <menu> to <li> elements like we do with other
lists. Therefore, the following gives an idea of what markup to expect
for <menu>:

| <menu>
|   [<commandset>]
|     <li>Item Name</li>
|     <li><label><input type="radio | checkbox">Item Name</label></li>
|     <li>
|       <input type="radio | checkbox">
|       <label for>Item Name</label>
|     </li>
|     <li><input type="submit" value="Item Name"></li>
|     <li><button type="submit">Item Name</button></li>
|     <li><a href>Item Name</a></li>
|     <li><menulabel>Item Name<menu></menu></menulabel></li>
|     <li><menulabel for>Item Name</menulabel>[<menu></menu>]</li>
|     <li><hr></li>
|   [</commandset>]
| </menu>