- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 8 Dec 2005 00:00:26 +0000 (UTC)
On Wed, 7 Dec 2005, Matthew Raymond wrote: > > > > <menu> > > <command .../> > > <command .../> > > <command .../> > > </menu> > > Doesn't the following do the same? > > <menu> > <option label="1"/> > <option label="2"/> > <option label="3"/> > </menu> It does if we say it does. Why would we do this? I don't really want to add a lot of new attributes to <option>; it would overload <option> and that element is already having plenty enough fun with <select>, <optgroup>, <datalist>, form submission, "am i control or am i not" schizophrenia, etc. > We can just use <option> elements instead of <command> when we need to > hide menus. If we're going to support <select> elements as menu fallback > markup, <menu> will have to support <option> elements anyways. This > frees up <command> to be used specifically in the <head>. I don't see any reason why <command> can't be used in the head anyway. Basically I think the way that <menu> will have to support <option> is separate and distinct from the way that it will have to support other commands. I don't expect <option> to support everything that <command> might. Do you disagree? > Sort of. I'm leaning towards having all elements but <option> nested > in an <li> element, though. Yeah, I'm just worried that people are going to want more flexible fallback than a bulleted list though (notwithstanding the fact that you can use CSS to change the presentation). > It just seems to have better semantics, and it also allows you to use > multiple elements to build a menu item, like having an <img>, a <input > type="checkbox"> and a <label> in the same <li> to create a menu item > with a checkbox and an icon. Oh I certainly agree that we want to allow <li>. > > Not quite sure how to get the label for nested <menu> elements yet. > > I fail to see what's wrong with using the activation of <menulabel> to > display menus. I dunno, it's just ugly. I wasn't really happy with it when I first put it in the spec and the more I look at it the less I like it. (See also earlier mail about this.) > Part of the benefit of [menulabel] is the ability to call menus that are > outside the <menubar>: Yes, we want to keep that functionality. There might be neater ways to do this than <menulabel for="">, though. Maybe even <menu def=""/> or something. > For toolbars, something similar to <menubar> that takes <button> or > <menulabel> children seems in order. I prefer doing this as opposed to > <menu type="menutype">, especially since <input type="[type]"> has > receive some resistance. So the main problem with <input type=""> is that one element is used for things that need to be implemented in fundamentally different ways. The proposal with <menu> is not as bad. Specifically, we have these cases: * <menu> is dumb (can just be styled by CSS). * <menu> is hidden. * <menu> is replaced by a toolbar. In addition, any <menu> can be used to generate a native menu. This isn't something relevant to <menu> itself, though -- much like the fact that you can generate an outline from <h1>s, etc, is not really that relevant to the <h1> elements themselves. > It also creates specific elements they have to support rather than > attribute values, which makes it harder for vendors to falsely claim > support. The solution to that problem is test suites, not compromises in language design, IMHO. > I think it also increases visibility. Not sure what you mean here. > Thought: Is the distinction between a menubar and a toolbar entirely > presentational? Use one element? <commandbar>? I don't think there is any difference at all between <menubar> and <toolbar>, really, hence wanting to just use <menu>. > Not sure I like the whole thing about the user agent guessing it's a > menu based on if it has a label or is connected to a context menu > reference. Might just be able to fix that by requiring the |label| > attribute. Then again, it seems like it's doing what could be done with > the |title| attribute. Agreed. > Perhaps an attribute |type| with the possible values "menu" and "list", > where "list" is the default. Yeah. > Then again, toolbars often have separators, so maybe they're a type of > list anyways and require <li>-type markup, thus making <menu type> more > appropriate. Hmm... <hr> is our separator element. Not sure what it stands for exactly. "Here is a separatoR", maybe. *cough* > Above, the type "menu" is assumed to be a sort of context menu activated > either by a true context menu feature or by a <menulabel>. Then again, > <commandbar>-type elements are flat, and while they may have > groupings/separators (for toolbars, at least), they don't have > multilevel groupings. They kind of do, in some contexts, e.g. drop-down buttons. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 7 December 2005 16:00:26 UTC