Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: > On Thu, 1 Dec 2005, Matthew Raymond wrote: >>Thought: >> >>| >>| Menu Item 1 >>| ... >>| >> >>Hmm. > > That could work. It's an advanced feature though. (Anything involving > indirection is going to be harder for users; the more indirection, the > harder it is, IMHO. This is one reason is easier than CSS.) I'd > expect use of the command="" attribute to be much rarer than just use of > itself: > > > > > > > > (Falls back to a line break.) Doesn't the following do the same? We can just use elements instead of when we need to hide menus. If we're going to support elements as menu fallback markup, will have to support elements anyways. This frees up to be used specifically in the .
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: > On Tue, 29 Nov 2005, Matthew Raymond wrote: > >>Well, what I don't like about this scenario is that we end up with a lot >>of different markup in : >> >>| >>| >>| >>| >>| >>| >>| >>| > > > So the situation would be: > > > Z > Z > Z > > > ...or: > > > Z > Z > Z > > > ...where "Z" is one of the following: > > > > > [1] > > [2] > > [1] assuming type="" is one of radio, checkbox, button, submit, reset, > move-up, move-down, add, or remove. > [2] (optionally with a , , or element) > > ...and all other content is ignored (and could be used for fallback). Sort of. I'm leaning towards having all elements but nested in an element, though. It just seems to have better semantics, and it also allows you to use multiple elements to build a menu item, like having an , a and a in the same to create a menu item with a checkbox and an icon. > Not quite sure how to get the label for nested elements yet. I fail to see what's wrong with using the activation of to display menus. It allows handling of both menus that appear when you press a "button" (which could be the default styling of outside of a ) and submenus within a menu: | | | Submenu Label | | | I believe you already state that elements are hidden until activated when they have a label, so I don't see the problem. > Also not quite sure how to make all this styleable, especially for the > toolbar type of . Although... maybe with XBL2's xbl:pseudo="" stuff > we can make use of that. Hmm. Should we be using for toolbars at all?
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: > My current thinking is to have an attribute on the to distinguish > the type of menu, from a list of three types: context menu (hidden until > activated), tool bar/menu bar/menu button/whatever you call it (turns each > command into a button, and each submenu into a menu button), and the > default, which is to display as a (like today). I don't know, I kinda like having separate markup for menus and menubars: | | | Menu Label 1 | | | Menu Label 1 | | | Menu Label 1 | | Part of the benefit of this system is the ability to call menus that are outside the : | | Menu Label 1 | Menu Label 2 | Menu Label 3 | I'm a little shakey on the use case, but it seems useful. For toolbars, something similar to that takes or children seems in order. I prefer doing this as opposed to , especially since has receive some resistance. It also creates specific elements they have to support rather than attribute values, which makes it harder for vendors to falsely claim support. I think it also increases visibility. Thought: Is the distinction between a menubar and a toolbar entirely presentational? Use one element? ? If you notice, my version of is both a menu label and a menu button. Aside from situations where you have floating, persistent menus with per-character styling in the title, I don't see a need for the two concepts to be separate. Is there even a significant use case for to have a |label| attribute? Seems to me that all menus made visible by an input event. You may be able to see items in menu /bars/, but in all other situations, you're clicking on a button or right clicking. 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. Perhaps an attribute |type| with the possible values "menu" and "list", where "list" is the default. Then again, toolbars often have separators, so maybe they're a type of list anyways and require -type markup, thus making more appropriate. Hmm... | Above, the type "menu" is assumed to be a sort of context menu activated either by a true context menu feature or by a . Then again, -type elements are flat, and while they may have groupings/separators (for toolbars, at least), they don't have multilevel groupings. /me trails off into deep thought...
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Sun, 4 Dec 2005, Matthew Raymond wrote: > > The more I look at the current spec, the better thought out it > appears to be. Heh. Thanks. :-) My main problems with the current spec are that it is aethetically unpleasing, IMHO. One of the things I don't like (sorry Matthew!) is the whole sibling- thing. It just doesn't feel right. (Adding a for="" attribute doesn't really save it either, IMHO.) It just feels like there are too many ways that it could go wrong -- e.g. the sibling isn't there, or whatever. BTW the goal of reducing the markup isn't to reduce the bandwidth or the size of the document or whatever. Bandwidth is cheap. Disk is cheap. The idea is to make the whole thing look simpler and cleaner to the author, and to make it easier to type. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Fri, 2 Dec 2005, Matthew Raymond wrote: > > That's not a menu. It's a MENUBAR. What's the difference? I would argue that the following are all the same: * menubars * pull-down menus * drop-down menus * context menus * toolbars They're just different presentations of the same underlying concept: lists of commands or options. menu n. A list of available options. This is why I think it makes sense to use one menu to describe all of them. Now, there is a small difference between context menus and the others in the list above in that context menus are irrelevant until activated on specific items, so we need a way to mark them. There's also a practical difference between as implemented today and as we want it to work (with natively implemented dynamic UI), so we need a way to mark those too. This is why I was thinking of an attribute on . -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Wed, 7 Dec 2005, Lachlan Hunt wrote: > > > > > > I just had a thought that maybe this could be marked up by including > > > the within the element... However, this would only be > > > possible in XHTML documents. > > > > Yeah, in HTML it would force the to open. An option for XHTML, > > indeed. > > It could still be done in HTML by modifying the DOM to move it from the > body to the head using a script. UAs without script would just get a > regular menu within the page, which isn't bad fallback. True. This isn't really in scope for HTML5 IMHO, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
> menu n. A list of available options. If the definition of menu is too vague then couldn't we include and ? Especially since people make dynamic menus with these right now. However, imho ideally the menubar would be powerful enough to turn into something like MS Office 12's ribbon. When I consider how that might look in html I think that ultaflexible menus within menus would work nicely. N -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: December 7, 2005 4:17 PM To: Matthew Raymond Cc: [EMAIL PROTECTED]; Lachlan Hunt Subject: Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted On Fri, 2 Dec 2005, Matthew Raymond wrote: > > That's not a menu. It's a MENUBAR. What's the difference? I would argue that the following are all the same: * menubars * pull-down menus * drop-down menus * context menus * toolbars They're just different presentations of the same underlying concept: lists of commands or options. menu n. A list of available options. This is why I think it makes sense to use one menu to describe all of them. Now, there is a small difference between context menus and the others in the list above in that context menus are irrelevant until activated on specific items, so we need a way to mark them. There's also a practical difference between as implemented today and as we want it to work (with natively implemented dynamic UI), so we need a way to mark those too. This is why I was thinking of an attribute on . -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Wed, 7 Dec 2005, Matthew Raymond wrote: > > > > > > > > > > > > > >Doesn't the following do the same? > > > > > > 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 ; it would overload and that element is already having plenty enough fun with , , , form submission, "am i control or am i not" schizophrenia, etc. > We can just use elements instead of when we need to > hide menus. If we're going to support elements as menu fallback > markup, will have to support elements anyways. This > frees up to be used specifically in the . I don't see any reason why can't be used in the head anyway. Basically I think the way that will have to support is separate and distinct from the way that it will have to support other commands. I don't expect to support everything that might. Do you disagree? > Sort of. I'm leaning towards having all elements but nested > in an 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 , a type="checkbox"> and a in the same to create a menu item > with a checkbox and an icon. Oh I certainly agree that we want to allow . > > Not quite sure how to get the label for nested elements yet. > > I fail to see what's wrong with using the activation of 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 : Yes, we want to keep that functionality. There might be neater ways to do this than , though. Maybe even or something. > For toolbars, something similar to that takes or > children seems in order. I prefer doing this as opposed to > , especially since has > receive some resistance. So the main problem with is that one element is used for things that need to be implemented in fundamentally different ways. The proposal with is not as bad. Specifically, we have these cases: * is dumb (can just be styled by CSS). * is hidden. * is replaced by a toolbar. In addition, any can be used to generate a native menu. This isn't something relevant to itself, though -- much like the fact that you can generate an outline from s, etc, is not really that relevant to the 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? ? I don't think there is any difference at all between and , really, hence wanting to just use . > 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 -type markup, thus making more > appropriate. Hmm... 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 . Then again, > -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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Shipping Safari actually supports as separators in dropdowns now. We needed this for Dashboard widgets that wanted to be able to put separators into their select UI. dave On Dec 7, 2005, at 4:00 PM, Ian Hickson wrote: Then again, toolbars often have separators, so maybe they're a type of list anyways and require -type markup, thus making more appropriate. Hmm... 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 . Then again, -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. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Thu, 8 Dec 2005, Lachlan Hunt wrote: > > > > I don't really want to add a lot of new attributes to ; > > What new attributes are you talking about? Option already has a label > attribute in HTML4. All the ones that has. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Wed, 7 Dec 2005, Nathan Heagy wrote: > > > > menu n. A list of available options. > > If the definition of menu is too vague then couldn't we include and > ? Especially since people make dynamic menus with these right now. is an unordered list of items. is an ordered list of items. is an unordered list of name-value tuples. is an unordered list of available command options. They seem separate to me, I'm not sure we need to merge them further. > However, imho ideally the menubar would be powerful enough to turn into > something like MS Office 12's ribbon. When I consider how that might > look in html I think that ultaflexible menus within menus would work > nicely. As I understand it the two key things about the Ribbon are that effects are instantly previewed (requires an "onmouseover"/"onmouseout" set of events on all commands, though not limited to mice of course) and the fact that the ribbon is context sensitive (not hard just by showing/hiding commands on the fly). I haven't seen it first hand though so I may be mistaken. It seems that it should be possible to implement that kind of UI with almost any toolbar-like solution that we come up with. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: On Wed, 7 Dec 2005, Matthew Raymond wrote: I don't really want to add a lot of new attributes to ; What new attributes are you talking about? Option already has a label attribute in HTML4. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
David Hyatt wrote: > Shipping Safari actually supports as separators in > dropdowns now. We needed this for Dashboard widgets that wanted to > be able to put separators into their select UI. Is that inside an or as a direct child of ?
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
As a child of a or . dave On Dec 7, 2005, at 8:47 PM, Matthew Raymond wrote: David Hyatt wrote: Shipping Safari actually supports as separators in dropdowns now. We needed this for Dashboard widgets that wanted to be able to put separators into their select UI. Is that inside an or as a direct child of ?
