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

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

Ok, I think I see where you're misunderstanding me,  let me try to 
explain it a little better.  Given this markup:

<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.

>>>  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 :

I have and my question still stands.  The menu element seems completely 
superfluous in that context.  The point is we should try to reduce the 
amount of unnecessary markup, not just use it because the current draft 
uses it in a section that, if I've understood correctly, is being 
significantly rewritten.

>>>  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?

Firefox doesn't seem to submit a form when pressing enter on a select 
control regardless of whether a submit button is present.  I didn't 
bother testing other browsers.

>><cmd>
>>   <select/>
>>   <button/>
>></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?

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>.

>>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>

Is that really a problem?  Besides, there's already a lot without <cmd>, 
it just adds one more.

>    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?

>  * Merge <cmd> and <menulabel>.

AIUI, the difference between them can be illustrated as follows:

<menu>
   <cmd>          <!-- Menu command item -->
     <button/>    <!-- abel 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>

>  * 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.

>  * 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.

>    That gives us something like this:
> 
> | <menu>
> |   [<li>]
> |     <a/>
> |   [</li>]
> |   [<li>]
> |     <menulabel/>
> |   [</li>]
> | </menu>
> ...
>    That's much more manageable. Perhaps we could add <cmd> in after all:
> 
> | <menu>
> |   <a/>
> |   <cmd/>
> |   <menulabel/>
> | </menu>

Add <menu> back to the list of children.

> It would be nice of menus with advanced menu functionality could 
> degrade to something reasonable functional without excessive scripting 
> for the legacy client.

That is the exact intention behind using a combination of select and button.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Tuesday, 29 November 2005 16:12:00 UTC