- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Mon, 9 Aug 2004 23:16:07 +1200
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/
Received on Monday, 9 August 2004 04:16:07 UTC