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

[Nathan Heagy]

While it is true that authors will want to style their menu buttons it's
not true that every menu item would need a label. In that case nesting
<menu> inside its label becomes quite ugly with a menu of menus only
some of which have labels:

<menu>
	<menulabel>
		Foo
		<menu>
		...
		</menu>
	</menulabel>
	<menu>
	...
	</menu>
	<menulabel>
		Foo
		<menu>
		...
		</menu>
	</menulabel>
</menu>

N


	
-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Matthew Raymond
Sent: December 13, 2005 7:24 AM
To: Ian Hickson
Cc: whatwg at whatwg.org
Subject: Re: [whatwg] Menus, fallback, and backwards compatibility:
ideas wanted

Ian Hickson wrote:
> In the case of <menulabel>, the presence or absence of the attribute 
> directly affects the immediate rendering of the other element, and any

> reference to one element requires examining the other element. It's a
much 
> closer relationship, and one that happens continually, not just at 
> specific points (e.g. on a click).

   Well, that doesn't have to be the case. We can use <menulabel> and
something like <menu type="popup"> together. The rendering is always the
same for the menu whether a <menulabel> is associated with it or not.

>>Also, you can still use implicit association.
> 
> I assume you mean containership?
> 
> The problem with
> 
>    <menulabel>
>      foo
>      <menu>...</menu>
>    </menulabel>
> 
> ...is that finding the actual string that corresponds to the title is 
> non-trivial. Imagine bidi elements or ruby being sprinkled into it, 
> consider the various error-handling cases, ponder what might happen if
the 
> author sets 'display:block' on the menu explicitly, etc. None of these
are 
> unsurmountable problems, but the lack of a very simple solution makes
it 
> less attractive.

   I don't see how it's any more difficult than dealing with a <label>.
In that respect, isn't this problem already solved? We just copy the way
we handle <label>.

> There's also the whole conceptual problem (also present with <label>)
of 
> having the menu be inside its label.

   Well, in most user interfaces, clicking on the label brings up the
menu, so there's sort of a child relationship already. It does introduce
a few minor inheritance issues in CSS, but those seem rather trivial to
me. To be honest, I don't see this as being much of an issue.

> My current thinking goes something like:
> 
>    <menu type="commands" label="Menulabel"/>
> 
> ...where type="commands" means "make a toolbar", and label="Menulabel"

> means "the toolbar has only one button, its value is "Menulabel", and
its 
> menu is this menu".
> 
> I'm not overly joyous about it, but it _is_ simple. :-)

   I don't think this is going to fly for menu buttons and the like. Web
authors are going to want to style the menu buttons. As for toolbars or
similar menus, just use |title|.

> Another option is:
> 
>    <button menu="foo"/>
>    <menu type="context" id="foo"/>
> 
> But as you point out in your mail, this has some of the <menulabel> 
> problems (at least when extended to <menu type="commands">-type
scenarios 
> where you want to make a toolbar of these things).

   Actually, it's no different from this:

| <menulabel for="foo"/>
| <menu type="context" id="foo"/>

   You've simply changed the element and attribute names. Using <button>
may have fallback advantages, though. Also, I'm concerned that the name
"menu" for the attribute many not be specific enough, especially if we
allow both context menus and popup menus.

   The "context" type value seems to be like "popup". Difficult to say
what the best name for that is.

>>The XHTML2 model has significant styling problems, though.
> 
> Indeed.
> 
> In general, I think having the label be its own element (or attribute)

> without anything inside it other than the label text is the most
sensible 
> design (semantically), at least when compared to designs that put
other 
> elements inside the label. But it's not perfect, as you say.
> 
> Note that in terms of styling, we shouldn't shy away from saying that
CSS 
> should be fixed to handle our markup, if CSS sucks. The style should
be 
> slave to the content, not vice versa.

   I suppose, but there's still the matter of the time it takes to
implement the spec, especially if we create dependencies on CSS, so we
can't ignore it entirely. Also, I like the idea of decoupling the label
from the target element. It allows for multiple labels to target the
same element.