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

[Matthew Raymond]

Lachlan Hunt wrote:
> Matthew Raymond wrote:
>>Lachlan Hunt wrote:
>>>Ian Hickson wrote:
>>>>Pity about the <menubar> being necessary to get the <select> to disappear, 
>>>>but I guess we need that...
>>
>>   If we must exclude the use of actual menu bars, I'd prefer the following:
>>
>>| <nav>
>>|   <form ...>
>>|     <menulabel>
>>|       <menu>
>>|         <select>
>>|           ...
>>|         </select>
>>|       </menu>
>>|       <button type="submit" name="menu">Foo</button>
>>|     </menulabel>
>>|   </form>
>>| </nav>
> 
> The <menu> element seems superfluous here.  I disagree with the use of 
> the <nav> element because this isn't a navigational menu, it's a command 
> menu.

   I explicitly state that this is for scenarios where a true
menubar-type element is not available. The <nav> element is simply the
next logical choice with regard to existing markup in the WA1 spec.

>>   I'm not sure I like the whole <menubar> scenario. With <menulabel> 
>>(as you will see below), certain child markup is ignored, whereas 
>><menubar> is actually changing the semantics of the child markup. 
>>Overloading and selectively altering the semantics of elements should be 
>>avoided whenever possible.
> 
> I don't believe my suggestion was altering the semantics of any element. 
>   The intention was the use the semantics of existing controls in a way 
> that can rendered as a single widget that performs the functions of both 
> (selection and submission) to achieve the submit-on-activation behaviour 
> required, with a very good, accessible fallback mechanism in current UAs.

   You're changing the <button> so that when activated, it passes
activation to an invisible <select> that is then presented as a menu.
Then when you click on an option, the submit is triggered. It sure
sounds to me like the semantics have been altered.

   What's worse is that it's the great grandparent that alters the
semantics (<menubar>) rather than the immediate parent. Neither the
<label> element nor the <li> element is altering the nature of how the
controls behave.

>>><label>
>>>   <button for="foo">Foo</button>
>>>   <select id="foo">
>>>     ...
>>>   </select>
>>></label>
>>>...
>>
>>   If you interpret <button> as being a form control, then in the former
>>the <label> would be associated with the <button>, where in the latter
>>it would be associated with the select. Personally, though, I think this
>>makes more sense:
>>
>>| <label for="foo"><button>Foo</button></label>
>>| <select id="foo">
>>|   ...
>>| </select>
> 
> Yes, but it loses any advantage gained (if there is/was any) by having a 
> common parent element for the button and select elements.

   What's the use case where this presents a problem? I do have to
agree, though, that having <label for> work and <label> not work is
nonsensical. Then again, I'm not really pushing this markup anyway.

>  However...
> 
>>   The <button> is not associated with the <label> because the |for|
>>attribute explicitly defines the association as being with the <select>.
>>Therefore, <button> can inherit the <label> association without adding a
>>|for| attribute to it.
> 
> What's the advantage of having the label element at all in this case? 

   It actually has focus passing semantics, for one.

> Why not just give the button a for attribute?

   Poor readability, since you don't know what the |for| is for until
you look a great granddaddy <menubar>. Also, you have to specify |for|
on <button> as being different from |for| on <label>. Also, how would
the |for| work in a non-menu context? Get the picture?

>>   I think we should focus on how to create solutions that allow optimal
>>fallback rather than trying to support a broad range of suboptimal
>>fallback options.
> 
> I thought my suggestion was an attempt at providing optimal fallback.  I 
> can't think of any cases where it would be suboptimal?

   How about the fact that the <label> contains multiple controls when
it's only supposed to have one, and you essentially have to guess which
control the UA will associate <label> with? That isn't suboptimal?

>>   The <menulabel> would ignore the <button> in the same way I defined
>>it as ignoring <a> elements. The contents are kept, but the element
>>itself is ignored.
>>
>>   Similarly, this is another solution:
>>
>>| <menulabel>
>>|   <menu>
>>|     <select>
>>|       ...
>>|     </select>
>>|   </menu>
>>|   <button>Foo</button>
>>| </menulabel>
> 
> Again, what's the point of the <menu> element?  And, the menulabel don't 
> make sense.

   Dude, read the bleeping spec!

>From http://whatwg.org/specs/web-apps/current-work/#tutorial :
| <form action="redirect.cgi">
|  <menubar>
|   <menulabel><label for="goto">Go to...</label></menulabel>
|   <menu>
|    <select id="goto"
|    onchange="if (this.options[this.selectedIndex].value)

|    window.location = this.options[this.selectedIndex].value">
|     <option value="" selected="selected"> Select site: </option>
|     <option value="http://www.apple.com/"> Apple </option>
|     <option value="http://www.mozilla.org/"> Mozilla </option>
|     <option value="http://www.opera.com/"> Opera </option>
|    </select>
|    <span><input type="submit" value="Go"></span>
|   </menu>
|  </menubar>
| </form>

   http://whatwg.org/specs/web-apps/current-work/#the-option

   The only thing different between the spec and my example are
differences in how <menulabel> works that I've posted about on this
mailing list earlier. My version of <menulabel> makes it the only way to
display a menu (save context menus, which I still haven't messed with
since Ian brought up some problems with my attribute idea a very long
time ago).

>>   For situations where the button isn't used, you can just drop it:
>>
>>| <menulabel>Foo
>>|   <menu>
>>|     <select>
>>|       ...
>>|     </select>
>>|   </menu>
>>| </menulabel>
> 
> Without the button, I think it should just be an ordinary select 
> element.  There would be no submission semantics (from the button) and, 
> therefore, it doesn't really satisfy the semantics of a command menu.

   Well, I was thinking about it having the same semantics as when you
hit enter when a control is selected. Is a submit button required in
that case?

> After much though, I've refined my original idea and also gone back to 
> Ian's original idea that navigation menus and command are the same 
> structure, only differing in their functionality.
> 
> Each command menu is marked up like this:
> 
> <cmd>
>    <select/>
>    <button/>
> </cmd>
> 
> or with the button and select switched:
> 
> <cmd>
>    <button/>
>    <select/>
> </cmd>
> 
> or with input instead:
> 
> <cmd>
>    <input type="submit"/>
>    <select/>
> </cmd>

   Well, if you create an element specifically to encapsulate the
<select> menu situation, I guess that's fine...

> (Other alternative element names for <cmd> could be: menuitem, 
> commandmenu, cmdmenu, command, but I like cmd because it's short, easy 
> to type and to remember.)

   Is this supposed to be a version of <command> with contents?

   http://whatwg.org/specs/web-apps/current-work/#the-command0

> Also note that there doesn't need to be a for attribute to associate the 
>   button with the select, as it's implicitly done with the cmd element. 

   Yeah, that's what I like about it.

>   It would need to be defined in a way that says the first select 
> element is associated with the first button element (to handle cases 
> where authors throw other extraneous markup within, including extra 
> buttons/selects).

   Yeah, error handling could be complicated. There may be some ways of
defining the element to simplify matters, though.

> If there's just one command menu, that (with an associated form element) 
> should be all the markup requried for a functional menu with good 
> fallback abilities.  But, for the cases where it's more like a menu bar 
> comprising several menus (e.g. File, Edit, View, etc.) they can be 
> contained within a menu element:
> 
> <menu>
>    <cmd/>
>    <cmd/>
>    <cmd/>
> </menu>
> 
> (where each cmd contains a select and a button, as above)

   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>

   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>.
 * Merge <cmd> and <menulabel>.
 * Prohibit <menu> as an immediate child of <menu> (but not as a child
   of <menulabel>.
 * 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 gives us something like this:

| <menu>
|   [<li>]
|     <a/>
|   [</li>]
|   [<li>]
|     <menulabel/>
|   [</li>]
| </menu>

   Or without the <li> elements...

| <menu>
|   <a/>
|   <menulabel/>
| </menu>

   That's much more manageable. Perhaps we could add <cmd> in after all:

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


> Now, going back to the idea that navigational menus and command menus 
> are the same structure, the menu element can be used for those too, 
> except using <li> instead of <cmd>, much like people use <ul> today, but 
> with a more semantically appropriate element.
> 
> <menu>
>    <li><a>...</a></li>
>    <li><a>...</a></li>
>    <li><a>...</a></li>
> </menu>

   I want to keep this too, but it opens up a lot of questions about
supporting stuff like check boxes, radio buttons and the like. I'm
trying to figure out a way to minimize the amount of markup to give the
widest range of functionality. It would be nice of menus with advanced
menu functionality could degrade to something reasonable functional
without excessive scripting for the legacy client.