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

[Matthew Raymond]

Lachlan Hunt wrote:
> <cmd>
>    <button name="menu">File</button>
>    <select name="filemenu">
>      <option>New...
>      <option>Open...
>      <option>Save...
>    </select>
> </cmd>
> 
> (This explanation also applies equally to intention of my previous 
> markup suggestions in this thread)
> 
> This could be rendered as a single widget using the button text as the 
> menu label.  In this sense, button is acting like the menulabel element 
> and the select like a menu element (as currently described in the spec 
> for navigatoinal menus), but provides better fallback for the command in 
> legacy UAs and with script disaabled or unsupported.
> 
>  From a functionality perspective, you could look at it as though there 
> is an implied command attribute on each option element referring to the 
> button and upon selection, performs the button's default action.  (We'd 
> need to define how to handle cases where there's an explicity command 
> attribute too)
> 
> However, it isn't actually changing the semantics of either the select 
> (selection) or the button (submission) element, it's merely changing the 
> presentation and user interaction.  Without a script that cancels the 
> form submission, the result of activation in future WA1 UAs would be 
> identical that of current UAs.  i.e. The form is submitted.

   Yeah, I wasn't thinking of it from a separation of semantics and
behavior standpoint. Technically, it doesn't violate the semantics.

> No, command in the current spec represents an abstract form control for 
> sharing features among several real form controls and my version of cmd 
> doesn't.  That could be confusing having similar names, perhaps 
> <command> could be renamed to <control> or use an alternative name for 
> <cmd>.

   The <command> element is most certainly not a form control, since it
can't be submitted (unless you're using a |command| attribute on an
<input type="radio"> or something). Actually, <command> looks
suspiciously like a modified version of the XUL element <command>...

>>   Well, what I don't like about this scenario is that we end up with a 
>>lot of different markup in <menu>:
>>
>>| <menu>
>>|   <a/>
>>|   <cmd/>
>>|   <command/>
>>|   <li/>
>>|   <menulabel/>
>>|   <menu label=""/>
>>| </menu>
> 
> Is that really a problem?  Besides, there's already a lot without <cmd>, 
> it just adds one more.

   I'm concerned about readability and people understanding the markup.

>>   As for a stand-alone <cmd> elements being drop down menus, it mirrors 
>>what I've been trying to do with <menulabel>.
>>
>>Thoughts:
>> * Merge <command> and <menulabel>.
> 
> What?  How are they in any way similar?

   On second thought, they're not.

   /me crumples up a paper and throws it into the trash.

>> * Merge <cmd> and <menulabel>.
> 
> 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. 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.

   If we were to continue using <menu> to wrap <select>, as in the
current spec, we could just extent it to also wrap the <button>. Then we
could just use <menulabel> for the menu label to create a complete solution:

| <menulabel>
|   <label for="select1">Label Text</label>
|   <menu>
|     <select id="select1"/>
|     <button/>
|   </menu>
| </menulabel>

   If we drop the <label> element, we get this :

| <menulabel for="menu1">Label Text</menulabel>
| <menu id="menu1">
|   <select/>
|   <button/>
| </menu>

   We get lesser fallback semantics with the above example, but the
<label> doesn't really mean anything in the WA1 context, so we trade
richer fallback for more readable markup.

>> * Prohibit <menu> as an immediate child of <menu> (but not as a child
>>   of <menulabel>.
> 
> I don't think that makes sense semantically, as the menu itself is not 
> part of the label.

   It follows the existing conventions of the <label> element, which
does implicit association by having the control as a child. However,
explicit association should also be supported, so I retract the suggestion.

>> * The <li> element (but not its contents) is ignored when <menu> is
>>   an actual menu, unless its only contents include immediate children
>>   other than <a> and <menulabel>. (List items should be treated as
>>   part of a separate list?)
> 
> That doesn't make sense at all.

   As you know, the <li> elements are just there for fallback.
Otherwise, they serve no purpose. Therefore, they can be safely ignored
with respect to actual menu content. However, someone might be stupid
enough to mix non-menu <li> elements with <li> elements that have menu
content, so we need to figure out how to handle that.

> Add <menu> back to the list of children.

   We're pretty much back to where we started then:

| <menu>
|   <a/>
|   <cmd/>
|   <command/>
|   <li/>
|   <menulabel/>
|   <menu/>
| </menu>

   Of course, using <menu> as a wrapper for <select>/<button>, we can
drop <cmd> from the list. Then again, we could just use <cmd> as an
alternate wrapper for menu:

| <menulabel for="cmd1">Label Text</menulabel>
| <cmd id="cmd1">
|   <select/>
|   <button/>
| </cmd>

   Hmm... Is there really a use case where we'd be using <select>
elements for submenus? 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.

   Another thing we can do is to require the <li> for any element that
can potentially have children:

| <menu>
|   <li>
|     <a/>
|     <cmd/>
|     <menulabel/>
|     <menu/>
|   </li>
|   <command/>
| </menu>

   Hmm. I'll have to give this continued thought...