Anne van Kesteren wrote: > Another idea I had was to make the first <option> element when it has a > particular ancestor element a label. So instead of saying it explicitly > it gets > its semantics from where it appears. > > <cmd> > <option>this is the label > <select> > <option>this is not > </select> > </cmd>
I don't see why we can't just have <cmd> be a "command menu" and use <menulabel> for it: | <menulabel for="foo"><label for="sel1">Menu Label</label></menulabel> | | <cmd id="foo"> | <select id="select"> | <option>Item 1 | <option>Item 2 | <option>Item 3 | </select> | <button>Go</button> | </cmd> 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> I've got a better idea, though. If we're trying to make <cmd> similar to <datalist>, why not just use <datalist>? | <menulabel> | <label for="bar">Label for Menu</label> | <menu list="foo"/> | </menulabel> | | <datalist id="foo"> | <select id="bar"> | <option>Item 1</option> | <option>Item 2</option> | <option>Item 3</option> | </select> | <button type="submit">Go</button> | </datalist> 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. > ... or: > > <cmd> > <select> > <option>this is the label > </select> > </cmd> 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>. I think it's cleaner to just have a <menulabel> associated with the <cmd> and treat <cmd> like a type of menu. As you saw above, the fallback is not difficult (though perhaps a little heavy on the markup). >>So we've completely reinvented <menu><select/></menu>, only using >><cmd> as the parent instead. Why not just return to using >><menu><select/></menu> then? > > As noted earlier in this thread <cmd> was just some random name that has to be > replaced at some point, not? Anyway, I think <menu> should be reserved for > dropdown lists, but I don't feel strongly about that. With the use of <datalist>, I don't see a point in having separate markup for various menu types. You only need specialized markup for the specific areas where they are different: For menu bars: | <menubar> | <menulabel> | Menu 1 | <menu/> | </menulabel> | <menulabel> | Menu 2 | <menu/> | </menulabel> | </menubar> For command menus: | <menulabel> | Command Menu Name | <menu/> | </menulabel> For context menus: | <textarea name="ta1" context="foo"></textarea> | <menu id="foo" label="edit"/> Without the <option> element to worry about, and with a version of <command> that goes in the <head> instead of a <menu>, we can limit the immediate children of <menu> to <li> elements like we do with other lists. Therefore, the following gives an idea of what markup to expect for <menu>: | <menu> | [<commandset>] | <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> | [</commandset>] | </menu>