[whatwg] Suggestion for Menus in Web Forms 2.0

[Matthew Thomas]

On 9 Aug, 2004, at 8:40 AM, Ian Hickson wrote:
> ...
> Your mistake is assuming that it should be visible by default.
>
> There are two cases. The "it should be visible" case and the "it should
> not be visible" case. In the "it should be visible" case, it all works
> already as defined; the markup would be:
>
>    <menubar>
>     <h3>File</h3> <!-- or <h>, or <span>, or <a>, or whatever -->
>     <menu>
>      ...
>
> The problem is in the case where you _don't_ want it visible in  
> downlevel UAs.

In which case you can use CSS to hide it.

To allow degradation to either shown or hidden menus, your current idea  
requires UAs to support a new (CSS3? CSS4?) pseudo-element. My  
suggestion requires UAs to implement CSS1's {display: none}. I think  
the latter is probably easier to implement, given that it's implemented  
in most UAs already.

>>     <menulist>
>>      <menu id="fm">
>>       <menutitle>File</menutitle>
>
> That won't work, the <menu> is display:none.

In the same message I said "After getting rid of the menu {display:  
none}...". I probably should have reordered the message to make it  
easier to understand.

> ...
>>> The menu element itself is display:none, and its display (on visual  
>>> media) is micromanaged by the UA. The question is how do you style  
>>> the label? Where is it? How does it get rendered?
>>
>> After getting rid of the menu {display: none}
>
> Why on earth would you want the menu visible? It's a menu.

Why on earth would you want to hide a menu? It's a menu. If none of its  
items apply to the current context, a menu should appear inactive, not  
hidden. Dynamically hiding and showing entire menus would make the  
interface unnecessarily unstable.  
(<http://developer.apple.com/documentation/mac/HIGuidelines/ 
HIGuidelines-76.html#MARKER-2-78>: "Your application's menu titles  
should remain constant. This constancy adds to the user's sense of  
perceived stability of the interface and helps users identify  
applications when they switch from one to another.")

If you *really* wanted to hide an entire menu, however (and to my  
chagrin, I see that Gnome suggests hiding and showing entire menus in  
"component-based applications"), you could indeed use menu {display:  
none} for that menu.

> It should be hidden until activated.

That won't work -- you can't activate a menu if there's nothing to  
click on. What you really want is to hide the menu's *items* until the  
menu is clicked on. Which is something my CSS did:
> ...
>> menu li {display: none;}
>> menu::active itemgroup, menu::active li {display: block;}

> ...
> menus are native, not rendered by CSS,

That's great!

> and therefore CSS is irrelevant here.

However unstylable native menus may otherwise be, and however unwise  
hiding menus may be, I wouldn't go as far as saying UAs shouldn't  
implement "display: none" for them. And that's how existing HTML form  
controls are hidden.

> This still doesn't answer the question, which is, where does the label
> come from in the label-attribute case.
> ...

That's your problem, since my suggested syntax doesn't put the label in  
an attribute. Furthermore, with my suggested syntax, in any legacy UA  
that supports CSS1, unusable (hidden) menus degrade to unusable menus,  
and usable (shown) menus degrade to usable menus. In a legacy UA that  
doesn't support CSS at all, all menus degrade to usable menus.

With the current syntax, however, *all* menus degrade to unusable in  
every legacy UA (because they know how to hide the <menu> but not how  
to display its label), except those UAs that don't support CSS at all,  
for which all menus degrade to usable. That wouldn't just be wrong; it  
would also be strange.

-- 
Matthew Thomas
http://mpt.net.nz/