W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Suggestion for Menus in Web Forms 2.0

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 9 Aug 2004 13:15:35 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0408091256230.5270@dhalsim.dreamhost.com>
On Mon, 9 Aug 2004, Matthew Thomas wrote:
> 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.

CSS can be disabled. Or not supported at all. It generally is not a 
solution to legacy fallback.


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

CSS shouldn't be required at all. That's the whole point. This should all 
work without CSS, although be compatible with CSS being present.

I don't like the pseudo-element idea; that's why the spec doesn't mention 
it and why I've been asking for better ideas. :-)



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

I understood it; in the same message, I said that making it not 
display:none was not workable. :-)


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

We're talking about the menu part of a menu bar here, not the menu bar 
itself. Menus aren't visible until activated. (The only exception to this 
rule that I'm aware of is the Gimp, hardly the pinacle of good UI!)


> > It should be hidden until activated.
> 
> That won't work -- you can't activate a menu if there's nothing to click 
> on.

Right. That's what I've been saying for a while now!


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

I'm not entirely sure what you're saying here, but if you are suggesting 
that display:none should be used to hide semantically-unavailable menu 
items, then I strongly disagree; that an item is unavailable is a semantic 
thing, not presentational.


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

I believe I gave an example that shows why you are wrong in my last 
e-mail. Basically, there are two ways of showing the label; with and 
without attributes. Similarly there are ways of using menu items that 
degrade to nothing and ways that degrade to visible. All of these are 
supported in th e current proposal, as are stylable menus and non-stylable 
native menus.

My problem is how to make the label in the stylable-but-only-visible-in- 
WA1-UAs version be addressable by CSS without using a pseudo-element.

I suppose I could use another element _before_ the element:

   <menubar>
    <menulabel label="File"/>
    <menu>
     ...

...where the default styling is:

   menulabel { content: attr(label); }

...but that doesn't seem as neat as an attribute.

Or we could require a pseudo-element, but say that it isn't the label, but 
is the ::menu, so that then to style the menu you just use the <menu> 
element. Except then for context menus you'd have this emptly block.

The problem with menu::menu-label pseudo-elements is that putting a pseudo 
outside an element always causes many bugs.

Hmm...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 9 August 2004 06:15:35 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC