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

Sat Dec 3 22:17:48 PST 2005

Anne van Kesteren wrote:
> Quoting Matthew Raymond <mattraymond at earthlink.net>:
>>Without fallback, this would be the following:
>>
>>| <menulabel for="foo">Menu Label</menulabel>
>>|
>>| <cmd id="foo">
>>|  <option>Item 1
>>|  <option>Item 2
>>|  <option>Item 3
>>| </cmd>
>
> Too much markup imho. Especially for the one with fallback.

   We're talking about this...

| <menulabel>
|   <label for="sel1">Menu Label</label>
|   <cmd>
|     <select id="sel1">
|      <option>Item 1
|      <option>Item 2
|      <option>Item 3
|     </select>
|     <button>Go</button>
|   </cmd>
| </menulabel>

   ...versus this:

| <cmd>
|   <label for="sel1">Menu Label</label>
|   <select id="sel1">
|    <option>Item 1
|    <option>Item 2
|    <option>Item 3
|   </select>
|   <button>Go</button>
| </cmd>

   By using only one extra element and moving the <label> outside of the
<cmd> element, we can make <cmd> a type of menu and reuse it elsewhere.
Plus we can style the menu label directly.

   The above is, of course assuming that we're not using the first
<option> approach to labeling. Granted, this...

| <menulabel for="foo">Menu Label</menulabel>
| <cmd id="foo">
|   <option>Item 1
|   <option>Item 2
|   <option>Item 3
| </cmd>

   ...Is mildly more verbose than the first-option-as-label solution...

| <cmd>
|   <option>Menu Label
|   <option>Item 1
|   <option>Item 2
|   <option>Item 3
| </cmd>

   ...And we probably loose by an element or two more when you include
fallback. However, think about which is easier to style and read for
newcomers to HTML. Let's just take the styling for now. For the
<menulabel> solution, you just style the <menulabel> :

| menulabel { /* Menu label styling. */ }
| option { /* Menu item styling. */ }
| label { /* Fallback label styling. */ }

   For your solution, you have to do this:

| cmd option:first-child { /* Menu label styling. */ }
| cmd option:not(:first-child) { /* Menu item styling. */ }

   Oh, wait, :not is a CSS3 pseudo-class, so in fallback situations
you'll have to override anything you do to the styling of the first
<option> for browsers like IE6 that don't support it. Also, without a
proper hack to get styling for the <cmd> element, the styling above
would be ignored entirely.

   In short, it's a styling nightmare.

>> As you can see, <menu> uses the |list| attribute from Web Forms 2.0
>>to load data from a <datalist>. Since <menulabel> is associated with a
>><menu> element, there's no change in its semantics. With the exception
>>of the <button> element, the use of <datalist> is pretty much how it is
>>used in WF2.
> 
> Even more markup...

   Doesn't matter. If we use a <datalist>, we make the styling too
complicated and there would be no direct children to assign events to.
So the idea's no good regardless whether there's too much markup.

   The more I look at the current spec, the better thought out it
appears to be. It allows <menu> to have <option> children. As a result,
the following is valid under the spec if my version of <menulabel> is used:

| <menulabel for="foo">Menu Label</menulabel>
| <menu id="foo">
|   <option>Item 1
|   <option>Item 2
|   <option>Item 3
| </menu>

   If you make <command> a <head>-based element, then <menu> would only
have to support <option>, <li> and some kind of item grouping element as
valid children. I'd say <commandset>, but since <command> isn't a
potential child in that scenario, a name change is in order. Perhaps
<itemgroup>?

   So that gives us this model of the <menu> element:

| <menu>
|   [<itemgroup label="Item Group Name">]
|     <li>Item Name</li>
|     <li><label><input type="radio | checkbox">Item Name</label></li>
|     <li>
|       <input type="radio | checkbox">
|       <label for>Item Name</label>
|     </li>
|     <li><input type="submit" value="Item Name"></li>
|     <li><button type="submit">Item Name</button></li>
|     <li><a href>Item Name</a></li>
|     <li><menulabel>Item Name<menu></menu></menulabel></li>
|     <li><menulabel for>Item Name</menulabel>[<menu></menu>]</li>
|     <li><hr></li>
|     <option>Item Name</option>
|   [</itemgroup>]
| </menu>

>>We're running into too many possible sources for adding labels. If
>>you include this we have:
>>
>>* A child <option>.
>>* The first <option> in the child <select>.
>>* A child text node.
>>* A child <label> node.
>>* A child <button>.
> 
> Not sure what you mean. My suggestion was to take the first Node from the
> NodeList when calling getElementsByTagNameNS method with the parameters
> "http://www.w3.org/1999/xhtml" and "option" from the <cmd> element and give
> that element "semantic meaning". (Which is essentially what is done 
> today so it is quite backwards compatible.)

   Your suggestion is semantically abusive, and unless someone clearly
knows that the first <option> is a label, they won't understand the
markup. The only purpose of allowing such markup seems to be for
reducing the total amount of markup, and that's probably offset in
bandwidth by the additional styling requirements.