Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Mon, 9 Jan 2006, Sander Tekelenburg wrote: At 01:21 + UTC, on 2006-01-09, Ian Hickson wrote: I constantly see friends, family, clients, strangers, colleagues struggle to figure out how to navigate through sites they don't know yet. Well sure, I struggle through such sites myself. The problem would not be aleviated by having a single point for site navigation, because the problem is just that the sites have poor structure. It doesn't matter how you _present_ the structure, if the structure itself is broken. True, that can also be a cause. But imagine for a moment a situation where at least the majority of browsers in use would have a nice NAV display:meta implementation, making it *visible* to people how they can organize the data they publish. Wouldn't that work as a guide, helping those who are not that well-organized realize how to publish their content in a more organised manner? No, not really, IMHO. Sites already have a big area where they can see their site, yet they make sites that are ugly and slow and unusable. Why would a tree (or other navigation representation) be any different? They might well think Ah, I can do like that other site: make a contact and a help page and tag 'm with display:meta to put them in that navigation thingy. I can even make sections that way to different parts of my site. k3wl. Why would they care? We haven't seen any evidence to suggest they would. That's how it works with most things: some technique becomes available in a nice and obvious form and suddenly people start using it. Usually, there's at least a rumbling of desire before it's made available. For navigation toolbars, there's been basically nothing. Browsers have implemented them, shipped them, then removed them because nobody cared. [display:meta] could be interesting if (and it's a big if!) you could convince browsers to implement it. I imagine it would be a logical step for Opera and Safari to take, given their activity in the hand-held/small screen market where something like this would probably be very useful. Well go and convince them and when you have some implementations we can add it to the spec. :-) My impression was that representatives of most browsers subscribe to this list. So I'm assuming they've already heard me. Maybe they're silently laughing at the nonsense I'm talking. Maybe they're already enthusiastically implementing it. I've no idea. I'm guessing not the latter, since it's been more than 18 months and we haven't seen anything new in this space. Anyway, I don't think we want to go back to the days where a browser defines its own new standards which other browsers are then forced to copy, faults included because by then too many authors/users are relying on that specific implementation. Makes more sense to me to all of us try to agree on something we think could work, and only then start work on (experimental) implementations and a spec. Experimental implementations and spec work should happen in parallel, otherwise we end up with standards that are theoretically perfect and practically useless. -- 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 Mon, 9 Jan 2006, Sander Tekelenburg wrote:
Authors can only suggest presentation, in the end the *user* decides
on it. That's the essence of the Web. Thus we should not be thinking
merely about what authors want, but at least as much, and probably
more, about what users want.
As a user on a dual monitor 1600x1200 system, I certainly don't have
any issues with space for navigation...
{shrug} You still have the same problem: namely that the author of the
site cannot know that you have those 2 large screens.
Actually media queries make this information quite accessible.
At the moment, sites can (and do!) provide a view of their site,
customised to their site, on pages as appropriate for that page and
that site. For example:
http://www.google.com/support
...has links to other major Google pages in a sidebar at the top left,
links to related pages in the mid-left sidebar area, links to related
features at the bottom of the left sidebar, links to major subsections
in the middle of the page, a search form at the top right, links to
popular subpages in the sidebar to the right, alternative suggestions
below that, links to other related pages below _that_, and at the
bottom has links to links only loosely related to the main topic.
How would that page look if authored with your proposal?
The page wouldn't exist ;) It *is* entirely a navigation menu. There is
no other content there. In 'my proposal', Google wouldn't have to do
that anymore. It could offer all that navigational information on pages
that do have 'actual' content and leave it up to the user-agent to
present it in a useful manner.
That aside, I imagine your point is that there are so many links on that
page, and that they are grouped in sections. But I see no problem with
that. All those links together (assuming they all have a rel attribute
and are set to display meta) would in a simplest form be displayed
through some meta presentational mechanism as a long 'flat' list of
links to other sections. That list might be presented as a shorter list,
each with sublists - thus keeping the sections, provided sections are
marked up that way. But instead of a list it could be presented as
objects (iconized and/or text perhaps) for the 'root' items, each
offering their sub items through a contextual menu. Display the current
page in the center of the screen, with everything else around it. Arrows
pointing from the current page in the center could make the rel
concept quite visual. Whatever. All up to the browser vendor's
imagination. (I imagine objects with contextual menus pointing to sub
items could work well on a small screen, like with a hand-held device.
But it might work well with large-screen desktops too.) For extra
coolness it could be implemented like Mac OS X's Expose feature: hit
some F key and have the entire screen filled with floating objects
representing the pages the site's menu points to ;)
You could even turn it around. Imagine a Web page that offers both
actual content and such a complex navigation menu as your Google example
contains. A user-agent could present those navigational links as a Web
page in a separate browser window, maybe looking exactly like this
Google page. After all, display:meta would not require a Toolbar. It
would merely require *some* 'meta-mechanism' for presentating content.
(Consider lynx' LINK implementation for example - no toolbar, but it
works fine. Or consider iCab's Link Manager, which brings up a browser
window with a list of all links found in the currrent page.)
It would help to see an actual implementation of all this, to show that it
would in fact be better than Web pages having their own stuff.
Or take this page:
http://buzz.yahoo.com/buzz_log/entry/2006/01/07/2100/?fr=fp-buzz-img
[...] How would that page look if authored with your proposal?
Same as that Google page. (Except of course the links within the actual
text would remain there.)
These pages are very different from each other. Saying they should be
authored the same (especially when you've said one shouldn't exist)
seems very vague, and not at all concrete enough for me to spec something.
--
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 Sun, 1 Jan 2006, Sander Tekelenburg wrote:
If we're trying to solve the problem of displaying the link
navigation twice (once in the page and once in the browser UI) then
I'm not convinced that's a problem, or that we should be solving it.
It's a problem because it wastes valuable screen space and as long as it
does waste valuable screen space there is not enough incentive for Web
publishers to bother to offer something like LINK or nav {display:meta}.
I'm not convinced that authors feel that screen space is valuable, or
that they would want to hide their navigation if the navigation was
integrated into the UA's chrome. Nor am I convinced that if it was
integrated into the UA's chrome in a usable fashion, that it would take
less room than it would if styled by the author of the page.
--
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 Sun, 1 Jan 2006, Alexey Feldgendler wrote: I once noticed that my wife, who is a university student and volunteers to maintain a simple informational web site for other students in her group, makes external links from the site like this: a href=http://example.com/some-page;http://example.com/some-page/a I asked: Why are you doing this? Why don't you put something meaningful inside a instead of repeating the URL? And she said: If they can see the URL in the page body, they can memorize it or write it down [on paper] in case they need to visit that page once more. I've seen people follow a hyperlink, find that the linked resource is interesting, and then each time they want to return to that resource, they would type the URL of the site that has the link (if it luckily remains there) and follow the link. I was shocked. This means that people don't know about bookmarks or find them too hard to use. That is indeed a worrying anecdote, but it is probably one that Web browser vendors need to worry about more than us. (Though if anyone has any ideas of ways we can extend HTML to help with this, please don't hesitate to come forward with them.) -- 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 Sun, 1 Jan 2006, Sander Tekelenburg wrote: I'm not convinced the problem you describe is real. For example, you say Ask any WWW newbie; ask any experienced Web surfer; ask any Web site developer what are the biggest problems with Web sites? and chances are navigation will rank in their top 3. but have you actually tried this? In a non-scientific manner, yes. I constantly see friends, family, clients, strangers, colleagues struggle to figure out how to navigate through sites they don't know yet. Well sure, I struggle through such sites myself. The problem would not be aleviated by having a single point for site navigation, because the problem is just that the sites have poor structure. It doesn't matter how you _present_ the structure, if the structure itself is broken. [display:meta] could be interesting if (and it's a big if!) you could convince browsers to implement it. I imagine it would be a logical step for Opera and Safari to take, given their activity in the hand-held/small screen market where something like this would probably be very useful. Well go and convince them and when you have some implementations we can add it to the spec. :-) I tried to get link reliably and widely implemented for around five years. I failed. I don't see why we would be more successful with display:meta. I understand your point about time, but I think you're forgetting a related and essential factor: situation. In the past 5 years the Web/browsers have matured somewhat. Standards-support is valued much more today. (Actually, this is a common mistunderstanding. It isn't standards support that is valued. It is interoperability. Standards support is merely one way to help foster interoperability.) In other words, the current situation is different from that of 5 years ago. I didn't say I tried to get link implement five years ago. I said I tried to get it implemented _for_ five years. About four of those five years were more recently than five years ago. Something like display:meta wouldn't have stood a chance back then, but it might today. I'm not convinced. Please prove me wrong. :-) As to us failing: 5 years ago only lynx and iCab offered LINK support. Today Opera and Mozilla do so too, even WinIE can, through a third-party tool, and last but not least some automated Web publishing systems generate LINKs. If I'd had to choose between labelling that as failure or success, I'd have to pick succes. The only thing we failed at is getting WinIE to support it natively - and I don't see how we could not have failed at that. Neither of the two biggest browsers (IE and Firefox) ship with support for link navigation as standard. Neither expects to do so in their next version. Thus some 98% or so of users don't have access to link navigation UI. Similarly, 98% or so of pages don't have any links for such UI to hook into in the first place, so even the few users who could use such a UI, rarely see it. CMS-based blogs and autogenerated documentation are the typical exception, but they aren't a big part of the Web (the blogosphere's collective ego notwithstanding). I couldn't call this a success without diluting the meaning of the word. -- 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 Tue, 20 Dec 2005, Alexey Feldgendler wrote: It's less abstract as far as the authors are concerned, because to them there is a direct relationship between the document.write() and what they see on their screen, as opposed to an indirect one that depends on the UA implementor's idea of navigation. Yes! I think that's the point, that's why I skipped quotation of most text above this. Draw it by hand in the viewport or Let the browser show it to the user. It's the same old story. Authors tend to describe every aspect of visualization in their CSS. Why? Because different browsers have different default rules, and the author wants the page to look the same in all browsers. The author wants it so much that he would never trust the browser to draw a menu without having full control about the fonts, colors, sizes etc. And it would miss the entire point of having a site's menu integrated into the browser's UI: the browser should show the site's menu items just like it shows its own menu items, so they seem intergrated. The browser's menu isn't an extension of the viewport. It isn't clear to me that it is either possible or desirable to standardise a navigation mechanism for Web pages. That isn't to say that we'll be removing the possibility to annotate link relationships in HTML5 -- quite the opposite. But I don't see what we can do in the spec that would improve matters for the user. Current implementations of browser-hosted site navigation are terrible (and I say this as someone who has been heavily involved in their development over the years). Until this problem is solved, I don't see any point in requiring UAs to implement such a mechanism (especially since UAs would just ignore the requirement anyway, making a farce of the specification). -- 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, 15 Dec 2005, Lachlan Hunt wrote: form action=redirect.cgi menu type=commands menu label=Select site... select name=goto onchange=if (this.options[this.selectedIndex].value) location = this.options[this.selectedIndex].value option value= selected=selected Select site: /option option value=http://www.apple.com/; Apple /option option value=http://www.mozilla.org/; Mozilla /option option value=http://www.opera.com/; Opera /option /select spaninput type=submit value=Go/span /menu /menu /form Ignoring this abuse of select as a navigational menu which would be better handled with a href, that handles the following cases fine: * Legacy UAs, with script * Legacy UAs, without script * New UAs, with script But, because the button will be hidden, it doesn't handle new UAs, without script. They'll only be able to select the menu item, but nothing will happen. Good point. (Though I still think scripting being optional is something that will become less and less realistic as time progresses.) The original idea I posted in this thread was that selecting an option would implicitly activate the associated submit button and that scripts (if supported) could capture the onsubmit event and deal with it appropriately. The idea is somewhat like having an implied command attribute on the option elements pointing to the submit button. The problem is determining when a select is a real select and when it is one of these autosubmit selects. (I don't want to add an attribute or something, because that would be almost legitimising this use.) The span/span hides the input from the menu. The value= hides that option from the menu. What semantics does the span have in this case to make it do that? None. What happens is that the semantics of menu are to only look at the element's direct children (with some fudging around for lis). The span is not special inside menu, so it (and its children) are ignored by the menu generation code. I think an attribute on the button that says this is the default action to be performed when a menu item is selected and that it should not be rendered by default would be better. Hmm. We could do that, true... button and input have so many attributes already though... Hmm... Hmm... how about this?: form action=redirect.cgi menu type=commands autosubmit !-- -- menu label=Select site... select name=goto onchange=if (this.options[this.selectedIndex].value) location = this.options[this.selectedIndex].value option value= selected=selected Select site: /option option value=http://www.apple.com/; Apple /option option value=http://www.mozilla.org/; Mozilla /option option value=http://www.opera.com/; Opera /option /select spaninput type=submit value=Go/span /menu /menu /form When a command is selected from a menu with type=autosubmit, and that command has an associated form (i.e. it is an input, button, or option whose 'form' DOM attribute is not null) then that form's submission behaviour must be invoked after the command completes. Top-level (not in menus) menu elements then act as follows: type=commands: treat as toolbar type=commands autosubmit: treat as toolbar, with autosubmit type=declare: hide type=declare autosubmit: hide, with autosubmit other: treat as ul When nested, the behaviour depends on the context. In a menu, if there is a label attribute then it creates a submenu. In a toolbar, if there is a label attribute then it creates a menu button. If there is no label attribute then it is treated as if its contents were there instead of the menu, but with an hr before and an hr after. In addition, if type is either autosubmit, declare autosubmit, or commands autosubmit, then the submenu/menu part/menu button has the autosubmit behaviour. -- 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, 15 Dec 2005, Lachlan Hunt wrote: I think the fact that a supports rel= gives us a way to drop link altogether, actually. What about link rel=stylesheet? I don't expect a rel=stylesheet to perform the same function. I didn't mean altogether, my bad. There are various rel= values that still make sense on link. (Though link rel=stylesheet could be replaced by style src= -- already supported by browsers -- or obsoleted only for XHTML, in favour of ?xml-stylesheet, as far as stylesheets go.) style@import;/style could have been an acceptable alternative to link if IE didn't have annoying bugs with it. It's not like IE doesn't have bugs with link rel=stylesheet... -- 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, 15 Dec 2005, Alexey Feldgendler wrote: On Thu, 15 Dec 2005 04:31:05 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote: I'm guessing nesting a select within another select will break current UAs. Sub-menus like that will be handled with nested optgroup elements. Are current browsers ready for nested optgroup? As I recall, when we decided to include it Web Forms 2, browsers failed relatively gracefully in the face of optgroup. There weren't any crashes or anything, at least. -- 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, 15 Dec 2005, Nate H. wrote: Many people have tried this kind of thing in the past, with little success. As far as I can tell, there is little interest from Web authors in describing their site map (which is more a graph than a tree, and which is getting all the more dynamic with things like wikis). Well, it's not necessary to describe the complete graph. Not many authors would want it. Any chance adopting google's sitemap format would be enough? If so then authors might be compelled to create the sitemap for google's benefit and then repeat the benefits of the what spec's usage as well. I'm not sure Google's sitemaps are really what Alexey was intending here. (Google's sitemaps are more a list of URIs than a map.) -- 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
Google sitemap does not describe the graph at all, it's just a linear list of pages on the site, nothing more. I still think it's prefereable to have the graph XML that authors can get for free otherwise I'm not sure they'll use it. It seems logical to use a site map to map the navigation but if google's sitemap isn't doing it - and for some reason when I glanced at it yesterday I thought it was - then that won't work. Perhaps the best way for authors to get their graph free is to hope the CMS they use generates it automatically. -- Nate --- heagy.com
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On 12/14/05, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Thu, 15 Dec 2005 06:42:37 +0600, Ian Hickson [EMAIL PROTECTED] wrote: One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is common for all or most pages of a site, it could be included as an external XML resource. Many people have tried this kind of thing in the past, with little success. As far as I can tell, there is little interest from Web authors in describing their site map (which is more a graph than a tree, and which is getting all the more dynamic with things like wikis). Well, it's not necessary to describe the complete graph. Not many authors would want it. Any chance adopting google's sitemap format would be enough? If so then authors might be compelled to create the sitemap for google's benefit and then repeat the benefits of the what spec's usage as well. https://www.google.com/webmasters/sitemaps/docs/en/protocol.html -- Nate --- heagy.com
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
At 00:42 + UTC, on 2005/12/15, Ian Hickson wrote: On Tue, 13 Dec 2005, Alexey Feldgendler wrote: [...] One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is common for all or most pages of a site, it could be included as an external XML resource. Many people have tried this kind of thing in the past, with little success. As far as I can tell, there is little interest from Web authors in describing their site map (which is more a graph than a tree, and which is getting all the more dynamic with things like wikis). My theory is that there is an inverse relationship between the level of abstraction involved and the level of interest from authors. Site maps in external files are a kind of abstraction beyond most authors. While that is certainly true, at the same time there appears to be a strong trend towards using automated Web publishing systems (CMSs, wikis, blogs, forums, etc.). Such a system will often 'know' already what the sitemap 'is' and could thus probably easily generate it automagically. I think it would make sense to adjust a spec not only to what human HTML authors can/will use, but also take into account what automated systems can/will. (Btw, I don't know if it would have to be a 'sitemap'. The profile attribute to HEAD seems to apply to this.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
First of all, my suggestion is that submenus always have an associated menulabel. I've taken menulabel to be a text label specifically and wonder about menus opened from an icon-only, such as would be found on a toolbar. -- Nate --- heagy.com On 12/13/05, Matthew Raymond [EMAIL PROTECTED] wrote: Nathan Heagy wrote: 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 First of all, my suggestion is that submenus always have an associated menulabel. If the |type| is popup (or context, as Ian calls it), then the menu doesn't display unless activated by the associated menu label element. Additionally, a |for| element can be used to avoid nesting: | menu type=menubar | li | menulabel for=menu1Foo/menulabel | menu id=menu1 type=popup | ... | /menu | /li | li | a href=frobozz.htmlFrobozz/a | /li | li | menulabel for=menu2Bar/menulabel | menu id=menu2 type=popup | ... | /menu | /li | /menu With this model, you can even pull the menus out nesting altogether: | menu type=menubar | limenulabel for=menu1Foo/menulabel/li | lia href=frobozz.htmlFrobozz/a/li | limenulabel for=menu2Bar/menulabel/li | /menu | | menu id=menu1 type=popup | ... | /menu | | menu id=menu2 type=popup | ... | /menu Hmm. The name context as a menu |type| is more semantic, but less accurate in non-context-menu cases, such as popup menus and submenus. The name popup is more general, but more presentational. -- Nate --- heagy.com
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Nate H. wrote: I'm guessing nesting a select within another select will break current UAs. Sub-menus like that will be handled with nested optgroup elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Nate H. wrote: First of all, my suggestion is that submenus always have an associated menulabel. I've taken menulabel to be a text label specifically and wonder about menus opened from an icon-only, such as would be found on a toolbar. I think it's up to the user agent to decide what to do with the contents of a menulabel. Since menulabel is a new element, we can always add the command element's |icon| attribute from the current spec, or allow the use of img and other markup within menulabel. That seems to be a step ahead of what we're discussing at the moment, though. Right now, we're just trying to figure out general menu markup structure. Also, keep in mind that the user agent should be free to ignore some attributes/elements if the platform of the user agent doesn't support the features they use. An example would be a device that can't display images inside menus. As a result, it's better to provide a wide array of should features in markup than give the web authors too few options.
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Tue, 13 Dec 2005, Matthew Raymond wrote: First of all, my suggestion is that submenus always have an associated menulabel. So what do you do when there isn't one? FWIW, I propose that a menu with no title inside another menu just ends up treated as if it had a separator each side. As in: menu ... command/ menu command/ /menu command/ /menu ...would be equivalent to: menu ... command/ hr/ command/ hr/ command/ /menu | menu type=menubar | li | menulabel for=menu1Foo/menulabel | menu id=menu1 type=popup | ... | /menu | /li | li | a href=frobozz.htmlFrobozz/a | /li | li | menulabel for=menu2Bar/menulabel | menu id=menu2 type=popup | ... | /menu | /li | /menu Here's how I'm thinking that would look: menu type=commands li menu label=Foo ... /menu /li li a href=frobozz.htmlFrobozz/a /li li menu label=Bar ... /menu /li /menu With this model, you can even pull the menus out nesting altogether: | menu type=menubar | limenulabel for=menu1Foo/menulabel/li | lia href=frobozz.htmlFrobozz/a/li | limenulabel for=menu2Bar/menulabel/li | /menu | | menu id=menu1 type=popup | ... | /menu | | menu id=menu2 type=popup | ... | /menu Hmm. There are several ways we can do this, though they all basically boil down to doing the same as in your example -- having an element with an attribute that refers to another menu element. The real question is which element to use: one specifically for this, menu, command, label, a, or something else? -- 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: How about: form action=redirect.cgi menu type=commands menu label=Select site... select name=goto onchange=if (this.options[this.selectedIndex].value) location = this.options[this.selectedIndex].value option value= selected=selected Select site: /option option value=http://www.apple.com/; Apple /option option value=http://www.mozilla.org/; Mozilla /option option value=http://www.opera.com/; Opera /option /select spaninput type=submit value=Go/span /menu /menu /form Ignoring this abuse of select as a navigational menu which would be better handled with a href, that handles the following cases fine: * Legacy UAs, with script * Legacy UAs, without script * New UAs, with script But, because the button will be hidden, it doesn't handle new UAs, without script. They'll only be able to select the menu item, but nothing will happen. The original idea I posted in this thread was that selecting an option would implicitly activate the associated submit button and that scripts (if supported) could capture the onsubmit event and deal with it appropriately. The idea is somewhat like having an implied command attribute on the option elements pointing to the submit button. The outer menu makes the toolbar, the inner menu is a drop-down button on that toolbar. That's fine, I like it better than using a new menubar element. The span/span hides the input from the menu. The value= hides that option from the menu. What semantics does the span have in this case to make it do that? I think an attribute on the button that says this is the default action to be performed when a menu item is selected and that it should not be rendered by default would be better. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Tue, 13 Dec 2005, Alexey Feldgendler wrote: I think there's nothing wrong in using the menus for navigation except that such a solution makes an impression of something presentational rather than semantic. No more so, IMHO, than a paragraph of a links, or a ulist of a links, is presentational rather than semantic. The semantics are in the a elements, which I fully suggest we support in menu as a kind of command. One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is common for all or most pages of a site, it could be included as an external XML resource. Many people have tried this kind of thing in the past, with little success. As far as I can tell, there is little interest from Web authors in describing their site map (which is more a graph than a tree, and which is getting all the more dynamic with things like wikis). My theory is that there is an inverse relationship between the level of abstraction involved and the level of interest from authors. Site maps in external files are a kind of abstraction beyond most authors. -- 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 Tue, 13 Dec 2005, Nate H. wrote: First of all, my suggestion is that submenus always have an associated menulabel. I realise you've made that assumption but I'm not sure that icon-only menus/toolbars would work that way. The icon-only-ness of a menu is a presentational detail. Even the ribbons in Office have titles for the various parts of the ribbon; they are used when the ribbon is collapsed (and presumably used by accessibility tools too, for that matter). But yes, I agree that we need to address the ability to create buttons that are icon-only in the default visual presentation. In the default audio presentation, the icons are, of course, irrelevant. My intent is to first work out what we want the markup to be, then once we've got that sorted out, to work out how to style it (which might need changes to CSS, but that's another matter). -- 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, 14 Dec 2005, Sander Tekelenburg wrote: Personally I wouldn't mind upgrading LINK to something that user-agents must support :) The spec can require whatever it likes, that won't in any way make browsers support things. :-) But then still, until they all do, authors will have to continue providing in-body navigational content. One of the key concepts Tantek often pushes in the microformats forums is the idea that metadata should be visible. link violates this concept in most UAs today. I think that's why it hasn't really taken off. -- that is, something that would be better addressed using CSS Agreed, except that I don't see how :) Can you elaborate? Is this a proposal for something like display:link or display:meta? No proposal yet, but yeah, something like that. Here's an alternative proposal to do the same thing: nav menu type=commands label=Navigation a rel=home href=index.htmlHome/a a rel=contents href=toc.htmlTOC/a a rel=help href=help.htmlHelp/a a rel=search href=search.htmlSearch/a a rel=address href=addressContact/a /menu /nav Yes. This includes exactly what I omitted, but in a much nicer way even :) I hadn't thought of the possibility to use REL for this. I think the fact that a supports rel= gives us a way to drop link altogether, actually. The UA can still take the link types out and make the toolbar, if it wants to do so, as the semantics are still there. Agreed. This seems more elegant than what I suggested. However, assuming LINK won't be deprecated, authors would probably have to then chose between - using this construction instead of LINK elements, thus essentially deprecating LINK, or - using this construction *and* repeating their content in LINK elements, for user-agents that don't support navmenu type=commands label=Navigation. Maybe we should deprecate link for this kind of thing. Therefore: what if the spec would state that in such situations the value of the REL attribute would be authorative for such a comparison? That, if a LINK's REL value equals that of an A's REL value (provided the anchor is embeded in navmenu type=commands label=Navigation), a user-agent may choose to not render the conten inline, but through a meta mechanism such as the LINKs Toolbar that some browsers offer? I think you're trying to solve a problem that doesn't exist. Authors like having the links in their content area. We're not going to convince them to remove them. IMHO. -- 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, 14 Dec 2005, Sander Tekelenburg wrote: But then still, until they all do, authors will have to continue providing in-body navigational content. One of the key concepts Tantek often pushes in the microformats forums is the idea that metadata should be visible. link violates this concept in most UAs today. I think that's why it hasn't really taken off. Link was never intended to be invisible metadata, it's just that UAs never really implemented them beyond linking to stylesheets, and those that did (Mozilla Suite, Opera and Lynx), didn't to anything very creative with them. I think the fact that a supports rel= gives us a way to drop link altogether, actually. What about link rel=stylesheet? I don't expect a rel=stylesheet to perform the same function. style@import;/style could have been an acceptable alternative to link if IE didn't have annoying bugs with it. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Thu, 15 Dec 2005 04:31:05 +0600, Lachlan Hunt [EMAIL PROTECTED] wrote: I'm guessing nesting a select within another select will break current UAs. Sub-menus like that will be handled with nested optgroup elements. Are current browsers ready for nested optgroup? -- Opera M2 9.0 TP1 on Debian Linux 2.6.12-1-k7 * Origin: X-Man's Station at SW-Soft, Inc. [ICQ: 115226275] [EMAIL PROTECTED]
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Thu, 15 Dec 2005 06:42:37 +0600, Ian Hickson [EMAIL PROTECTED] wrote: One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is common for all or most pages of a site, it could be included as an external XML resource. Many people have tried this kind of thing in the past, with little success. As far as I can tell, there is little interest from Web authors in describing their site map (which is more a graph than a tree, and which is getting all the more dynamic with things like wikis). Well, it's not necessary to describe the complete graph. Not many authors would want it. In my opinion, there are two kinds of systematic navigation usually included on the pages of a site. I'll refer to them as relative and absolute. Relative navigation includes links to pages which bear a specific fixed relation to the current page. For example, it's common for a page to include a link to the next page. Following a relative link is like moving to an adjacent vertex in a graph, or resolving a relative pathname on a filesystem. The relative navigation is pretty decently covered with the link mechanism because there's not many possible relations. Absolute navigation includes links to fixed pages, the same on all pages of the site. Usually these are links to top-level sections and subsections thereof. Following an absolute link is like skipping to a fixed vertex in a graph, or resolving an absolute pathname on a filesystem. The absolute navigation is somewhat covered with the link mechanism (rel=toc, for example), but it's not enough because the fixed nodes referenced by absolute navigation is rarely described with specific roles like TOC; more often, these are just top-level sections of the site. Currently, we have link which works great in browsers which understand it. For those who don't, authors usually duplicate relative navigation in the page body. For absolute navigation, though, they have no choice because there is no appropriate mechanism similar to link to instruct browsers to include absolute navigation somewhere in its UI outside the viewport. My theory is that there is an inverse relationship between the level of abstraction involved and the level of interest from authors. Site maps in external files are a kind of abstraction beyond most authors. Why? Everyone puts CSS and JS in external files -- just to avoid repeating the same text on all or most pages of the site. And, well, everyone puts links to top-level sections of the site on every page, which is actually repetition. Also many authors put links to subsections of the top-level sections, which is even more repetition. To avoid the repetition, some use external JS to generate the menus, with JS arrays actually describing the site map. It's an ad-hoc solution to the same problem (how to not write the site map on every page), it's effectively the same level of abstraction, and it's just worse because it's not semantic, requires programmatic evaluation of JS, and is not standardized. -- Opera M2 9.0 TP1 on Debian Linux 2.6.12-1-k7 * Origin: X-Man's Station at SW-Soft, Inc. [ICQ: 115226275] [EMAIL PROTECTED]
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Tue, 13 Dec 2005 08:05:45 +0600, Ian Hickson [EMAIL PROTECTED] wrote: Well, the menu feature is not being _designed_ for navigation, but I'm sure that authors would try to use it for navigation. There is a clear demand on Web sites today for menu-based navigation. A side note about navigation. I think there's nothing wrong in using the menus for navigation except that such a solution makes an impression of something presentational rather than semantic. This means that a semantic facility for expression navigation information should probably be considered. One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is common for all or most pages of a site, it could be included as an external XML resource. Then, two possible approaches can be used for presentation: a) Apply CSS styling directly to the elements comprising the site map. Maybe the CSS can convert them even to something visible outside the viewport, such as browser menus. This involves introduction of new selectors to CSS which allow to apply properties to site map elements basing on the link elements of the current page. For example, there can be a rule which highlights the parent page of the current page (given that the pagent page is referenced from the current page as link rel=up). And another CSS selector is needed to highlight the current page (basing on the matching URI). b) Use JavaScript to generate a menu from the site map. Actually, not all pages should probably be directly accessible from any page. Some measure of relevance can be implemented by JavaScript. These are just raw ideas, they require a lot more thinking over. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Nathan Heagy wrote: 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 First of all, my suggestion is that submenus always have an associated menulabel. If the |type| is popup (or context, as Ian calls it), then the menu doesn't display unless activated by the associated menu label element. Additionally, a |for| element can be used to avoid nesting: | menu type=menubar | li | menulabel for=menu1Foo/menulabel | menu id=menu1 type=popup | ... | /menu | /li | li | a href=frobozz.htmlFrobozz/a | /li | li | menulabel for=menu2Bar/menulabel | menu id=menu2 type=popup | ... | /menu | /li | /menu With this model, you can even pull the menus out nesting altogether: | menu type=menubar | limenulabel for=menu1Foo/menulabel/li | lia href=frobozz.htmlFrobozz/a/li | limenulabel for=menu2Bar/menulabel/li | /menu | | menu id=menu1 type=popup | ... | /menu | | menu id=menu2 type=popup | ... | /menu Hmm. The name context as a menu |type| is more semantic, but less accurate in non-context-menu cases, such as popup menus and submenus. The name popup is more general, but more presentational.
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Tue, 13 Dec 2005, Matthew Raymond wrote: Hmm. The name context as a menu |type| is more semantic, but less accurate in non-context-menu cases, such as popup menus and submenus. The name popup is more general, but more presentational. I'm not attached to context. (I'm not particularly fond of popup, though). What I really want is an attribute whose values convey acts as a ul with no magic, declares a menu for use elsewhere, and turns into a toolbar, menu bar, or other command list displayed inline. -- 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 Tue, 13 Dec 2005, Matthew Raymond wrote: The problem with menulabel foo menu.../menu /menulabel ...is that finding the actual string that corresponds to the title is non-trivial. I don't see how it's any more difficult than dealing with a label. Simple. You don't have to do it for label. :-) User agents don't analyse label elements to determine what the label is, they just render everything using CSS. For menus, we want to be able to get a string out of whatever represents the label so that we can pass them to the OS. 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. I meant the semantic problem. x y/ /x implies that y is part of x -- but the control or menu is not part of its label, conceptually. menu type=commands label=Menulabel/ 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. Well, the above is no less stylable than: input type=menu value=Menulabel/ ...or whatever. I mean, it's one element. No? As for toolbars or similar menus, just use |title|. The title attribute is for the tooltip/hint, not the label. 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/ Yes. (It's also similar to some of your suggested button/menu/ examples, for that matter.) 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. True. 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. Sure. Also, I like the idea of decoupling the label from the target element. It allows for multiple labels to target the same element. Yeah, this is something that I'd like to support too. I'm not sure the right concept to decouple is label, though. Showing the menu could also be considered a command of kinds. I'm still vague about this. -- 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 Sat, 10 Dec 2005, Sander Tekelenburg wrote: Ah. Maybe I misunderstood your aim then. I got the impression there was also talk of navigation menus in this thread. Is the idea then that nav may contain menu, to define a menu to be for navigation? (I'll assume this for the example below.) Or did I completely misunderstand and is menu not meant to be used for navigation at all? Well, the menu feature is not being _designed_ for navigation, but I'm sure that authors would try to use it for navigation. There is a clear demand on Web sites today for menu-based navigation. menu attributes: type, etc. type attribute values: - import Informs the user agent that the document's LINK elements are to be imported (as list items) into the menu. If the menu element is empty, user-agents may choose to not draw the menu at all but instead provide access to the LINK elements through a meta mechanism, such as a LINKs Toolbar for example. Example markup: head link rel=home HREF=index.html title=Home link rel=contents HREF=toc.html title=TOC link rel=help HREF=help.html title=Help link rel=search HREF=search.html title=Search link rel=address HREF=address title=Contact /head body nav menu type=import /menu /nav /body This seems like a highly presentational idea -- that is, something that would be better addressed using CSS or XBL, or a server-side transform mechanism. It also would not degrade very gracefully -- UAs that support neither link nor menu type=import would show nothing. Here's an alternative proposal to do the same thing: nav menu type=commands label=Navigation a rel=home href=index.htmlHome/a a rel=contents href=toc.htmlTOC/a a rel=help href=help.htmlHelp/a a rel=search href=search.htmlSearch/a a rel=address href=addressContact/a /menu /nav The UA can still take the link types out and make the toolbar, if it wants to do so, as the semantics are still there. (Note to eager menu spec designers: no, I have no idea if that's what I want it to look like.) -- 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
At 20:38 + UTC, on 2005/12/09, Ian Hickson wrote: On Fri, 9 Dec 2005, Sander Tekelenburg wrote: [...] link has had ten years to prove itself. It failed. We should learn from this and not force ourselves to give it another ten years. :-) Indeed we should learn from this, but my conclusion would rather be that what we should learn from it is that we need to be a little bit more ambitious ;) menu is not really primarily for navigation (that's what nav is for). The main use case I'm considering is command menus, as seen in applications like Yahoo Mail, Hotmail, etc. Ah. Maybe I misunderstood your aim then. I got the impression there was also talk of navigation menus in this thread. Is the idea then that nav may contain menu, to define a menu to be for navigation? (I'll assume this for the example below.) Or did I completely misunderstand and is menu not meant to be used for navigation at all? [...] That way web publishers wouldn't need to dupicate navigational links anymore and user-agents could allow users to decide whether to present such menus inline in accordance with the site's suggested presentation (CSS), or in the sort of toolbar that current browsers offer for LINK. I'm not really sure how this would work. Could you give a more concrete specification for your idea? menu attributes: type, etc. type attribute values: - import Informs the user agent that the document's LINK elements are to be imported (as list items) into the menu. If the menu element is empty, user-agents may choose to not draw the menu at all but instead provide access to the LINK elements through a meta mechanism, such as a LINKs Toolbar for example. Example markup: head link rel=home HREF=index.html title=Home link rel=contents HREF=toc.html title=TOC link rel=help HREF=help.html title=Help link rel=search HREF=search.html title=Search link rel=address HREF=address title=Contact /head body nav menu type=import /menu /nav /body The user-agent would parse this as either: body /body and providing access to the LINKs through, for example, a LINKs Toolbar or, if no such LINKs Toolbar is available, as: body nav menu type=import liA HREF=index.htmlHome/A/li liA HREF=toc.htmlTOC/A/li liA HREF=help.htmlHelp/A/li liA HREF=search.htmlSearch/A/li liA HREF=address.htmlContact/A/li /menu /nav /body -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
I wasn't actually suggesting li be merged with menu, just that your definition of menu as A list of available options was too broad to be the criteria for defining menu. The feature of ribbon I was specifically thinking of was the way chunks collapse when space isn't available. The ribbon is segmented into smaller toolbars such as arrange. When the window is narrow and it can't display all the chunks some of them collapse into a single menu. It doesn't make sense for a menubar to behave like a menu based on available space but if everything is a menu it's logical. More information on this aspect of ribbon here: http://blogs.msdn.com/jensenh/archive/2005/10/18/482233.aspx N -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: December 7, 2005 6:26 PM To: Nathan Heagy Cc: [EMAIL PROTECTED] Subject: 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 ul and ol? Especially since people make dynamic menus with these right now. ul is an unordered list of items. ol is an ordered list of items. dl is an unordered list of name-value tuples. menu 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 Thu, 1 Dec 2005, Matthew Raymond wrote: Thought: | menu | li command=cmd_in_head1Menu Item 1/li | ... | /menu 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 font is easier than CSS.) I'd expect use of the command= attribute to be much rarer than just use of command itself: menu command .../ command .../ command .../ /menu (Falls back to a line break.) Doesn't the following do the same? menu option label=1/ option label=2/ option label=3/ /menu 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.
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 menu: | menu | a/ | cmd/ | command/ | li/ | menulabel/ | menu label=/ | /menu So the situation would be: menu x=y li Z /li li Z /li li Z /li /menu ...or: menu x=y Z Z Z /menu ...where Z is one of the following: command a button input [1] menu select option /select [2] [1] assuming type= is one of radio, checkbox, button, submit, reset, move-up, move-down, add, or remove. [2] (optionally with a button/, input/, or label/ element) ...and all other content is ignored (and could be used for fallback). Sort of. I'm leaning towards having all elements but option nested in an li 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 img, a input type=checkbox and a label in the same li to create a menu item with a checkbox and an icon. 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. It allows handling of both menus that appear when you press a button (which could be the default styling of menulabel outside of a menu) and submenus within a menu: | menu | li | menulabel for=submenuSubmenu Label/menulabel | menu id=submenu/ | /li | /menu I believe you already state that menu 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 menu. Although... maybe with XBL2's xbl:pseudo= stuff we can make use of that. Hmm. Should we be using menu 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 menu 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 ul (like today). I don't know, I kinda like having separate markup for menus and menubars: | menubar | !-- Note: Sibling Association Used. -- | menulabelMenu Label 1/menulabel | menu/ | | menulabelMenu Label 1/menulabel | menu/ | | menulabelMenu Label 1/menulabel | menu/ | /menubar Part of the benefit of this system is the ability to call menus that are outside the menubar: | menubar | menulabel for=extMenu1Menu Label 1/menulabel | menulabel for=extMenu2Menu Label 2/menulabel | menulabel for=extMenu3Menu Label 3/menulabel | /menubar I'm a little shakey on the use case, but it seems useful. 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. 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? commandbar? If you notice, my version of menulabel 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 menu 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 li-type markup, thus making menu type more appropriate. Hmm... | menu type=list|menu|commandbar 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. /me trails off into deep thought...
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 menu as implemented today and menu 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 menu. -- 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 menu within the head element... However, this would only be possible in XHTML documents. Yeah, in HTML it would force the body 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 ul and ol? 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 menu as implemented today and menu 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 menu. -- 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: 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 h1s, 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Shipping Safari actually supports hr as separators in select 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 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. `._.-(,_..'-- (,_..'`-.;.'
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 option; What new attributes are you talking about? Option already has a label attribute in HTML4. All the ones that command 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 ul and ol? Especially since people make dynamic menus with these right now. ul is an unordered list of items. ol is an ordered list of items. dl is an unordered list of name-value tuples. menu 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: menu option label=1/ option label=2/ option label=3/ /menu I don't really want to add a lot of new attributes to option; 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 hr as separators in select dropdowns now. We needed this for Dashboard widgets that wanted to be able to put separators into their select UI. Is that inside an option or as a direct child of select?
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
As a child of a select or optgroup. dave On Dec 7, 2005, at 8:47 PM, Matthew Raymond wrote: David Hyatt wrote: Shipping Safari actually supports hr as separators in select dropdowns now. We needed this for Dashboard widgets that wanted to be able to put separators into their select UI. Is that inside an option or as a direct child of select?
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Tue, 29 Nov 2005, Lachlan Hunt wrote: Couldn't the for attribute used to associate the button with the the select, be used to determine how to render the controls without the menu/menubar/etc. wrapper? Making one element render or not render according to an attribute on another element is not really workable (especially in the face of dynamic changes). It makes good sense semantically, but it would be a pain to implement sanely. It's unfortunate about the button being first, too. From an implementation perspective, is there any reason why it couldn't work with the order of the button and select elements swapped? At the moment, I thinking it should work if the button and select are just immediate siblings of each other in any order, though I'm not sure if it should work if there were other content in between. Right, that's what I meant when I wrote: I guess we could change that if we say that in the new world in an li any selects are ignored and just the button is looked for... Hmm. I'm not sure I understand. Wouldn't that break many existing documents which do have select and buttons inside li elements? I only meant inside menubar. -- 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 Tue, 29 Nov 2005, Matthew Raymond wrote: menubar libutton type=submit for=foo name=menuFoo/button select id=foo name=foo ... /select /li ... /menubar /form Interesting idea. I like the non-JS fallback potential. Pity about the menubar being necessary to get the select to disappear, but I guess we need that... If we must exclude the use of actual menu bars It wasn't the menubar element I had a particular aversion to, it was requiring some sort of container element in general. I'd prefer the following: [extraneous markup removed -IH] | menulabel | menu | select | ... | /select | /menu | button type=submit name=menuFoo/button | /menulabel That's basically the same thing. | label for=foobuttonFoo/button/label | select id=foo | ... | /select IMHO we can't rely on solutions that involve an element being hidden due to the presence of an attribute on another element. [snip other solutions that have this problem] | x | menu | select | ... | /select | /menu | buttonFoo/button | /x This could work. Basically in a new UA if you hit an x element you render it as a menu button, and you use the contents to determine the menu and the button label according to some algorithm. (I've renamed menulabel to x to remove any mention of what we call new elements for now. The structure is what I'm looking at here.) -- 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 Tue, 29 Nov 2005, Lachlan Hunt wrote: After much though, I've refined my original idea and also gone back to Ian's original idea that navigation menus and command are the same structure, only differing in their functionality. Each command menu is marked up like this: cmd select/ button/ /cmd or with the button and select switched: cmd button/ select/ /cmd or with input instead: cmd input type=submit/ select/ /cmd ...or with a, or with input on its own, or with any number of other types of commands that are described in the draft right now. menu cmd select/ button/ /cmd cmd select/ button/ /cmd cmd select/ button/ /cmd /menu (where each cmd contains a select and a button, as above) Why not just: menu li select/ button/ /li li select/ button/ /li li select/ button/ /li /menu ...? Which is basically the same as: menu lia.../a/li lia.../a/li lia.../a/li /menu The only problem is that we can't do that, because menu is an existing element and there is no way to distinguish the above from today's menus. My current thinking is to have an attribute on the menu 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 ul (like today). -- 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 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 menu: | menu | a/ | cmd/ | command/ | li/ | menulabel/ | menu label=/ | /menu So the situation would be: menu x=y li Z /li li Z /li li Z /li /menu ...or: menu x=y Z Z Z /menu ...where Z is one of the following: command a button input [1] menu select option /select [2] [1] assuming type= is one of radio, checkbox, button, submit, reset, move-up, move-down, add, or remove. [2] (optionally with a button/, input/, or label/ element) ...and all other content is ignored (and could be used for fallback). Not quite sure how to get the label for nested menu elements yet. Also not quite sure how to make all this styleable, especially for the toolbar type of menu. Although... maybe with XBL2's xbl:pseudo= stuff we can make use of that. Hmm. -- 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, 1 Dec 2005, Matthew Raymond wrote: menu cmd !-- Menu command item -- button/!-- [Label] for command menu -- select/!-- The menu items -- /cmd li !-- Menu list item (e.g. navigational list) -- menulabel/ !-- Label for nav menu -- menu/ !-- The menu items -- /li /menu You're mistaken. The button caption actually isn't the menu label in many cases. Since the button itself wouldn't actually be visible in WA1 UAs, it's really only there for fallback, why can't it be used as the menu's label? Because, semantically, it's not actually a label for the select. In fact, semantically, the two controls are only related indirectly via the form. Well, they have semantic if we say they do. We could easily say in the spec that if a button and a select both are in an li of a menu with an attribute foopy with value barpy, that they are in fact related in that the select represents commands and the button represents the activation of the command and has a label that says can be used as a label for a menu button of the same set of commands. You could use the button as a menu label if the label is absent, but the web author should not be required to use the button as a label, because that forces them to use inferior fallback. The button as a label in a fallback scenario just doesn't seem that common to me. Yeah I agree that it should be possible to provide a label instead of a button. It can be argued, however, that the overloading of menu is undesirable, I agree. It could be argued. I still think it's an opportunity we shouldn't pass up, though. We want an element to render menus, and we have menu with convenient fallback characteristic that happens to already be deprecated. Thought: | menu | li command=cmd_in_head1Menu Item 1/li | ... | /menu 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 font is easier than CSS.) I'd expect use of the command= attribute to be much rarer than just use of command itself: menu command .../ command .../ command .../ /menu (Falls back to a line break.) In that case, could we just require li like we do for ul and ol? Perhaps even replace menu with nl, making it more like the XHTML 2.0 element? nl doesn't have convenient fallback characteristics. -- 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 Sat, 3 Dec 2005, Lachlan Hunt wrote: I wouldn't mind requiring li for content other than cmd, since we already use it within ul for menus, and other than reduced markup, I see no other benefit in leaving it out. Reduced markup is quite an important goal. Another important goal is being able to get just the right kind of fallback. Most toolbars these days don't have bullets before every command button. :-) Earlier, Ian Hickson wrote: 1. Providing a menu bar for the entire window (or application, on Mac), so that the application can be a native-like application. This, IMHO, isout of scope for HTML5 and should maybe be revisited in HTML6 bywhoever does the work on taking HTML out of the browser, if that everhappens. I just had a thought that maybe this could be marked up by including the menu within the head element, since the content of the head element contains metadata applying to the whole document, and an application menu bar applies to the whole application, it makes sense for such a menu to be marked up like that. However, this would only be possible in XHTML documents. Yeah, in HTML it would force the body to open. An option for XHTML, indeed. -- 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 Sat, 3 Dec 2005, Lachlan Hunt wrote: Earlier, Ian Hickson wrote: 1. Providing a menu bar for the entire window (or application, on Mac)... I just had a thought that maybe this could be marked up by including the menu within the head element... However, this would only be possible in XHTML documents. Yeah, in HTML it would force the body 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. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
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 optionthis is the label select optionthis 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=foolabel for=sel1Menu Label/label/menulabel | | cmd id=foo | select id=select |optionItem 1 |optionItem 2 |optionItem 3 | /select | buttonGo/button | /cmd Without fallback, this would be the following: | menulabel for=fooMenu Label/menulabel | | cmd id=foo | optionItem 1 | optionItem 2 | optionItem 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=barLabel for Menu/label | menu list=foo/ | /menulabel | | datalist id=foo | select id=bar | optionItem 1/option | optionItem 2/option | optionItem 3/option | /select | button type=submitGo/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 optionthis 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 menuselect//menu, only using cmd as the parent instead. Why not just return to using menuselect//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] | liItem Name/li | lilabelinput type=radio | checkboxItem Name/label/li | li | input type=radio | checkbox | label forItem Name/label | /li | liinput type=submit value=Item Name/li | libutton type=submitItem Name/button/li | lia hrefItem Name/a/li | limenulabelItem Namemenu/menu/menulabel/li | limenulabel forItem Name/menulabel[menu/menu]/li | lihr/li | [/commandset] | /menu
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Quoting Matthew Raymond [EMAIL PROTECTED]: Without fallback, this would be the following: | menulabel for=fooMenu Label/menulabel | | cmd id=foo | optionItem 1 | optionItem 2 | optionItem 3 | /cmd Too much markup imho. Especially for the one with fallback. 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... 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.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Anne van Kesteren wrote:
Quoting Matthew Raymond [EMAIL PROTECTED]:
Without fallback, this would be the following:
| menulabel for=fooMenu Label/menulabel
|
| cmd id=foo
| optionItem 1
| optionItem 2
| optionItem 3
| /cmd
Too much markup imho. Especially for the one with fallback.
We're talking about this...
| menulabel
| label for=sel1Menu Label/label
| cmd
| select id=sel1
| optionItem 1
| optionItem 2
| optionItem 3
| /select
| buttonGo/button
| /cmd
| /menulabel
...versus this:
| cmd
| label for=sel1Menu Label/label
| select id=sel1
|optionItem 1
|optionItem 2
|optionItem 3
| /select
| buttonGo/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=fooMenu Label/menulabel
| cmd id=foo
| optionItem 1
| optionItem 2
| optionItem 3
| /cmd
...Is mildly more verbose than the first-option-as-label solution...
| cmd
| optionMenu Label
| optionItem 1
| optionItem 2
| optionItem 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=fooMenu Label/menulabel
| menu id=foo
| optionItem 1
| optionItem 2
| optionItem 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]
| liItem Name/li
| lilabelinput type=radio | checkboxItem Name/label/li
| li
| input type=radio | checkbox
| label forItem Name/label
| /li
| liinput type=submit value=Item Name/li
| libutton type=submitItem Name/button/li
| lia hrefItem Name/a/li
| limenulabelItem Namemenu/menu/menulabel/li
| limenulabel forItem Name/menulabel[menu/menu]/li
| lihr/li
| optionItem 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.
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Quoting Lachlan Hunt [EMAIL PROTECTED]: My point is that this command menu is basically made up of a label, a select control and a button, and that we already have a label element for associating with select elements. Therefore, we don't need to use another type of label element for that. menulabel is fine for navigational menus. That would also require a form element around the command menu. Is there a problem with that? My initial suggestion in this thread included the form element, subsequent discussion assumed it would be present in the surrounding document. Fair enough. I just don't see the thing as it is used in Gmail for example as a form. More as a standalone widget separate from the form. I wonder if there always is a form element. There was also this suggestion: # select # option labelAction ... # optionSelect All # optionDeselect All # optionArchive Selected # /select That's an interesting idea, and kind of fits with the existing abuse of the first option as a label, rather than an actual option, as in: select optionPlease Select optionfoo /select Now assuming scripting is more or less required for applications Why should script be required for applications? I believe this was one of the baselines once mentioned here on this list by Ian. I kind of agree with that. Making everything fallback is just not going to work. And accessibility clients can just build on top of the DOM (what they should do anyway). I believe there should be fallback for users with JS disabled, unsupported or even in older UAs which may have script enabled, but for some reason, the script might be broken for them. We are talking about applications here. I think you can assume JS should be enabled and I don't think they should work in Netscape 4 either or some other browser that is no longer in use. (eg. existing UAs don't support the new DOM methods introduced in this spec, and if the author doesn't handle such conditions, then it's effectively another UA without script support. Well yeah, but that is always the case. If you use 'application/xhtml+xml' as media type for your site you're also excluding people from using your site. Perhaps put some additional container element around it and make select optional for fallback (same as with datalist) and you have some kind of solution. Do you mean like this: cmd optionfoo optionbar /cmd would be the same as: cmd select optionfoo optionbar /select button/ /cmd Since the first would only be supported by new UAs with no good fallback, the button would be completely unnecessary. Yeah, I meant that. And I like it now I see it :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Lachlan Hunt wrote: Matthew Raymond wrote: | menulabel for=menu1Label Text/menulabel | menu id=menu1 | select/ | button/ | /menu We already have label for form controls, I don't think we need a new element for that especially when it's basically still associating a label with a form control. I also think you're overloading the use of the menu element too. The menulabel is associated with a menu, so unless you have a opposition to that, I don't see your point. It can be argued, however, that the overloading of menu is undesirable, I agree. My point is that this command menu is basically made up of a label, a select control and a button, and that we already have a label element for associating with select elements. Therefore, we don't need to use another type of label element for that. menulabel is fine for navigational menus. I would agree, with one condition: The label must be inside the cmd element. 3. cmd labelJump to select//label buttonGo/button /cmd This is fine. 4. cmd label for=jumpJump to/label select id=jump/ buttonGo/button /cmd Same here. They're the ones I preferred too. Note that we could also do something similar to this: | form ismenu | label for=jumpJump to/label | select id=jump/ | buttonGo/button | /form Just a thought... There's something that still just bugs me about cmd, and it's not the name, because actually I'm starting to warm to that. What bothers me is that we have an element specifically designed to convert markup content into WA1 content without serving any other function. As a result, the markup will become obsolete once WA1 is widely in use because people will start directly using the standard menu markup. Hmm, then again, do we currently have a way of submitting a form with current menu markup? Let's see... | form | menu | libutton type=submit/button/li | liinput type=submit value=Item 2/li | liinput type=submit value=Item 3/li | /menu | /form If there isn't a use case for having cmd as a direct child of menu, why allow it to be the direct child of menu??? Furthermore, if cmd supports multiple submenu levels, you can just use it for the whole menu structure rather than a submenu. (Or, cmd could be require to be a child of li. See below.) I thought there was a use case, where cmds as direct children of a menu element would form the menu bar, and the select/button elements would form each individual menu: menu cmd labelFile select name=file//label button name=menu value=fileGo/button /cmd cmd labelEdit select name=edit//label button name=menu value=editGo/button /cmd cmd labelView select name=view//label button name=menu value=viewGo/button /cmd /menu That might be rendered like this: _ |File Edit View | |-|___| | New... | | Open... | |_| That's not a menu. It's a MENUBAR. You should be using menubar as the parent element. Otherwise, you could do the whole thing with a div and CSS and wouldn't need the menu at all. We don't need a special case of menu to display buttons next to each other in a row. | div class=fakebarcmd/cmd/cmd//div Hmm. In that case, could we just require li like we do for ul and ol? Perhaps even replace menu with nl, making it more like the XHTML 2.0 element? That would be an alternative, but menuli is already supported by existing UAs. I wouldn't mind requiring li for content other than cmd, since we already use it within ul for menus, and other than reduced markup, I see no other benefit in leaving it out. That would make the content model for menu look somethink like this: menu cmd !-- Menu command item -- label/ !-- Label for command menu -- select/!-- The menu items -- button/ /cmd li !-- Menu list item (e.g. navigational list) -- menulabel/ !-- Label for nav menu -- menu/ !-- The menu items -- /li lia href=//li /menu Requiring an li around cmd would just be extra markup for no good reason. A menu command item is just as much a list item as the menulabel/menu combination and therefore should be in an li. Here's both the cmd and the menulabel/menu pair at the root level: | cmd | label/ !-- Label for command menu -- | select/ !-- The menu items -- | button/ | /cmd | | menulabel/ !-- Label for nav menu -- | menu/ !-- The menu items -- Note that menu and menulabel are not the children of an li, just like cmd, yet they are excluded from being direct children of menu. That's inconsistent. Furthermore, li part of the fallback markup. Without it, the select menu doesn't have the same presentation as the other items. Worse is that all the elements in cmd default to being inline, so they all stack up on the same line if you don't use an li. If you don't believe me,
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Lachlan Hunt wrote: Anne van Kesteren wrote: I wonder if there always is a form element. There was also this suggestion: # select # option labelAction ... # optionSelect All # optionDeselect All # optionArchive Selected # /select That's an interesting idea, and kind of fits with the existing abuse of the first option as a label, rather than an actual option, as in: select optionPlease Select optionfoo /select First, I don't like the idea of abuse of legacy markup any more than I like abuse of current markup. Second, option already has a |label| attribute. Perhaps put some additional container element around it and make select optional for fallback (same as with datalist) and you have some kind of solution. Do you mean like this: cmd optionfoo optionbar /cmd would be the same as: cmd select optionfoo optionbar /select button/ /cmd Since the first would only be supported by new UAs with no good fallback, the button would be completely unnecessary. So we've completely reinvented menuselect//menu, only using cmd as the parent instead. Why not just return to using menuselect//menu then? | menu |select | optionfoo | optionbar |/select |button/ | /menu
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Quoting Matthew Raymond [EMAIL PROTECTED]: First, I don't like the idea of abuse of legacy markup any more than I like abuse of current markup. Second, option already has a |label| attribute. Indeed, it has. Somehow I missed that. 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 optionthis is the label select optionthis is not /select /cmd ... or: cmd select optionthis is the label /select /cmd So we've completely reinvented menuselect//menu, only using cmd as the parent instead. Why not just return to using menuselect//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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Matthew Raymond wrote: Lachlan Hunt wrote: No, command in the current spec represents an abstract form control for sharing features among several real form controls. The command element is most certainly not a form control, since it can't be submitted I know that, I said *abstract* form control, though perhaps I should have omitted the word form. AIUI, the difference between them can be illustrated as follows: menu cmd !-- Menu command item -- button/!-- [Label] for command menu -- select/!-- The menu items -- /cmd li !-- Menu list item (e.g. navigational list) -- menulabel/ !-- Label for nav menu -- menu/ !-- The menu items -- /li /menu You're mistaken. The button caption actually isn't the menu label in many cases. Since the button itself wouldn't actually be visible in WA1 UAs, it's really only there for fallback, why can't it be used as the menu's label? You would only use the button for submission. Here's a stripped down version of what Ian has on his weblog: | form action=./ method=get | p | label | Jump to | select name=start/ | /label | input name=order value=-1 type=hidden | input name=count value=5 type=hidden | input value=Go type=submit | /p | /form Also, as you point out, the input element could be used instead. So you'd need either a label or child text, as you see Ian using above. Why? input type=submit is still a button, what difference does it make from the button element? But, if you really don't like overloading the use of the button as the menu label as well, then I guess we could add a label, but I think just using the button itself has the advantage of less markup and if the button isn't required to get the menu, authors won't bother including it, which reduces accessibility. | menulabel for=menu1Label Text/menulabel | menu id=menu1 | select/ | button/ | /menu We already have label for form controls, I don't think we need a new element for that especially when it's basically still associating a label with a form control. I also think you're overloading the use of the menu element too. Do you like the structure of any of these alternatives? (with the actual element names still up for discussion) 1. cmd buttonJump to/button select/ /cmd 2. cmd Jump to select/ buttonGo/button /cmd 3. cmd labelJump to select//label buttonGo/button /cmd 4. cmd label for=jumpJump to/label select id=jump/ buttonGo/button /cmd 5. cmd labelJump to select/ buttonGo/button/label /cmd 6. label cmdJump to select/ buttonGo/button/cmd /label 7. label for=jumpJump to/label cmd id=jump select/ buttonGo/button /cmd Hmm... Is there really a use case where we'd be using select elements for submenus? Not that I can think of, but select elements could have submenus using the optgroup element, as currently described in the spec. Not menus, mind you, but menus within menus. If not, then we could drop cmd from the list of possible children for menu while keeping the element itself. I don't understand your logic behind this. | menu | ... | command/ | /menu Why does command need to be a child of menu at all? It's really more of an abstraction, rather than a physical control for the user to use. Wouldn't it be better for them to be declared within the head or early within the body and then referenced by other controls as needed? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Lachlan Hunt wrote: Matthew Raymond wrote: Lachlan Hunt wrote: AIUI, the difference between them can be illustrated as follows: menu cmd !-- Menu command item -- button/!-- [Label] for command menu -- select/!-- The menu items -- /cmd li !-- Menu list item (e.g. navigational list) -- menulabel/ !-- Label for nav menu -- menu/ !-- The menu items -- /li /menu You're mistaken. The button caption actually isn't the menu label in many cases. Since the button itself wouldn't actually be visible in WA1 UAs, it's really only there for fallback, why can't it be used as the menu's label? Because, semantically, it's not actually a label for the select. In fact, semantically, the two controls are only related indirectly via the form. You would only use the button for submission. Here's a stripped down version of what Ian has on his weblog: | form action=./ method=get | p | label | Jump to | select name=start/ | /label | input name=order value=-1 type=hidden | input name=count value=5 type=hidden | input value=Go type=submit | /p | /form Also, as you point out, the input element could be used instead. So you'd need either a label or child text, as you see Ian using above. Why? input type=submit is still a button, what difference does it make from the button element? It doesn't matter if it's a button or an input type=submit, because neither have label semantics for anything external to themselves. But, if you really don't like overloading the use of the button as the menu label as well, then I guess we could add a label, but I think just using the button itself has the advantage of less markup and if the button isn't required to get the menu, authors won't bother including it, which reduces accessibility. You could use the button as a menu label if the label is absent, but the web author should not be required to use the button as a label, because that forces them to use inferior fallback. The button as a label in a fallback scenario just doesn't seem that common to me. | menulabel for=menu1Label Text/menulabel | menu id=menu1 | select/ | button/ | /menu We already have label for form controls, I don't think we need a new element for that especially when it's basically still associating a label with a form control. I also think you're overloading the use of the menu element too. The menulabel is associated with a menu, so unless you have a opposition to that, I don't see your point. It can be argued, however, that the overloading of menu is undesirable, I agree. Do you like the structure of any of these alternatives? (with the actual element names still up for discussion) 1. cmd buttonJump to/button select/ /cmd Works, though not ideal. 2. cmd Jump to select/ buttonGo/button /cmd This works. A label would provide better fallback semantics, though. 3. cmd labelJump to select//label buttonGo/button /cmd This is fine. 4. cmd label for=jumpJump to/label select id=jump/ buttonGo/button /cmd Same here. 5. cmd labelJump to select/ buttonGo/button/label /cmd No. This has the same implicit association problems we spoke of earlier, and it's unnecessary, since cmd establishes any relationships between the elements that we need. 6. label cmdJump to select/ buttonGo/button/cmd /label If cmd is not a form control, they you're semantically overloading label. You're also using label in a way that's similar to menulabel, which could confuse web authors. If we merge the two, we still have the problem of label calling menus that aren't technically form controls, thus overloading label in a clearly semantic way. 7. label for=jumpJump to/label cmd id=jump select/ buttonGo/button /cmd Ditto here as well. Hmm... Is there really a use case where we'd be using select elements for submenus? Not that I can think of, but select elements could have submenus using the optgroup element, as currently described in the spec. That's true, and they have multiple levels if you allow optgroup nesting. Not menus, mind you, but menus within menus. If not, then we could drop cmd from the list of possible children for menu while keeping the element itself. I don't understand your logic behind this. If there isn't a use case for having cmd as a direct child of menu, why allow it to be the direct child of menu??? Furthermore, if cmd supports multiple submenu levels, you can just use it for the whole menu structure rather than a submenu. (Or, cmd could be require to be a child of li. See below.) | menu | ... | command/ | /menu Why does command need to be a child of menu at all? It's really more of an abstraction, rather than a physical control for the user to use. Wouldn't it be better for them to be declared
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Lachlan Hunt wrote: cmd button name=menuFile/button select name=filemenu optionNew... optionOpen... optionSave... /select /cmd (This explanation also applies equally to intention of my previous markup suggestions in this thread) This could be rendered as a single widget using the button text as the menu label. In this sense, button is acting like the menulabel element and the select like a menu element (as currently described in the spec for navigatoinal menus), but provides better fallback for the command in legacy UAs and with script disaabled or unsupported. From a functionality perspective, you could look at it as though there is an implied command attribute on each option element referring to the button and upon selection, performs the button's default action. (We'd need to define how to handle cases where there's an explicity command attribute too) However, it isn't actually changing the semantics of either the select (selection) or the button (submission) element, it's merely changing the presentation and user interaction. Without a script that cancels the form submission, the result of activation in future WA1 UAs would be identical that of current UAs. i.e. The form is submitted. Yeah, I wasn't thinking of it from a separation of semantics and behavior standpoint. Technically, it doesn't violate the semantics. No, command in the current spec represents an abstract form control for sharing features among several real form controls and my version of cmd doesn't. That could be confusing having similar names, perhaps command could be renamed to control or use an alternative name for cmd. The command element is most certainly not a form control, since it can't be submitted (unless you're using a |command| attribute on an input type=radio or something). Actually, command looks suspiciously like a modified version of the XUL element command... Well, what I don't like about this scenario is that we end up with a lot of different markup in menu: | menu | a/ | cmd/ | command/ | li/ | menulabel/ | menu label=/ | /menu Is that really a problem? Besides, there's already a lot without cmd, it just adds one more. I'm concerned about readability and people understanding the markup. As for a stand-alone cmd elements being drop down menus, it mirrors what I've been trying to do with menulabel. Thoughts: * Merge command and menulabel. What? How are they in any way similar? On second thought, they're not. /me crumples up a paper and throws it into the trash. * Merge cmd and menulabel. AIUI, the difference between them can be illustrated as follows: menu cmd !-- Menu command item -- button/!-- [Label] for command menu -- select/!-- The menu items -- /cmd li !-- Menu list item (e.g. navigational list) -- menulabel/ !-- Label for nav menu -- menu/ !-- The menu items -- /li /menu You're mistaken. The button caption actually isn't the menu label in many cases. You would only use the button for submission. Here's a stripped down version of what Ian has on his weblog: | form action=./ method=get | p | label | Jump to | select name=start/ | /label | input name=order value=-1 type=hidden | input name=count value=5 type=hidden | input value=Go type=submit | /p | /form Also, as you point out, the input element could be used instead. So you'd need either a label or child text, as you see Ian using above. If we were to continue using menu to wrap select, as in the current spec, we could just extent it to also wrap the button. Then we could just use menulabel for the menu label to create a complete solution: | menulabel | label for=select1Label Text/label | menu | select id=select1/ | button/ | /menu | /menulabel If we drop the label element, we get this : | menulabel for=menu1Label Text/menulabel | menu id=menu1 | select/ | button/ | /menu We get lesser fallback semantics with the above example, but the label doesn't really mean anything in the WA1 context, so we trade richer fallback for more readable markup. * Prohibit menu as an immediate child of menu (but not as a child of menulabel. I don't think that makes sense semantically, as the menu itself is not part of the label. It follows the existing conventions of the label element, which does implicit association by having the control as a child. However, explicit association should also be supported, so I retract the suggestion. * The li element (but not its contents) is ignored when menu is an actual menu, unless its only contents include immediate children other than a and menulabel. (List items should be treated as part of a separate list?) That doesn't make sense at all. As you know, the li elements are just there for fallback. Otherwise, they
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Matthew Raymond wrote: Lachlan Hunt wrote: I don't believe my suggestion was altering the semantics of any element. The intention was the use the semantics of existing controls in a way that can rendered as a single widget that performs the functions of both (selection and submission) to achieve the submit-on-activation behaviour required, with a very good, accessible fallback mechanism in current UAs. You're changing the button so that when activated, it passes activation to an invisible select that is then presented as a menu. Then when you click on an option, the submit is triggered. It sure sounds to me like the semantics have been altered. Ok, I think I see where you're misunderstanding me, let me try to explain it a little better. Given this markup: cmd button name=menuFile/button select name=filemenu optionNew... optionOpen... optionSave... /select /cmd (This explanation also applies equally to intention of my previous markup suggestions in this thread) This could be rendered as a single widget using the button text as the menu label. In this sense, button is acting like the menulabel element and the select like a menu element (as currently described in the spec for navigatoinal menus), but provides better fallback for the command in legacy UAs and with script disaabled or unsupported. From a functionality perspective, you could look at it as though there is an implied command attribute on each option element referring to the button and upon selection, performs the button's default action. (We'd need to define how to handle cases where there's an explicity command attribute too) However, it isn't actually changing the semantics of either the select (selection) or the button (submission) element, it's merely changing the presentation and user interaction. Without a script that cancels the form submission, the result of activation in future WA1 UAs would be identical that of current UAs. i.e. The form is submitted. Similarly, this is another solution: | menulabel | menu | select | ... | /select | /menu | buttonFoo/button | /menulabel Again, what's the point of the menu element? And, the menulabel don't make sense. Dude, read the bleeping spec! From http://whatwg.org/specs/web-apps/current-work/#tutorial : I have and my question still stands. The menu element seems completely superfluous in that context. The point is we should try to reduce the amount of unnecessary markup, not just use it because the current draft uses it in a section that, if I've understood correctly, is being significantly rewritten. For situations where the button isn't used, you can just drop it: | menulabelFoo | menu | select | ... | /select | /menu | /menulabel Without the button, I think it should just be an ordinary select element. There would be no submission semantics (from the button) and, therefore, it doesn't really satisfy the semantics of a command menu. Well, I was thinking about it having the same semantics as when you hit enter when a control is selected. Is a submit button required in that case? Firefox doesn't seem to submit a form when pressing enter on a select control regardless of whether a submit button is present. I didn't bother testing other browsers. cmd select/ button/ /cmd Well, if you create an element specifically to encapsulate the select menu situation, I guess that's fine... (Other alternative element names for cmd could be: menuitem, commandmenu, cmdmenu, command, but I like cmd because it's short, easy to type and to remember.) Is this supposed to be a version of command with contents? No, command in the current spec represents an abstract form control for sharing features among several real form controls and my version of cmd doesn't. That could be confusing having similar names, perhaps command could be renamed to control or use an alternative name for cmd. If there's just one command menu, that (with an associated form element) should be all the markup requried for a functional menu with good fallback abilities. But, for the cases where it's more like a menu bar comprising several menus (e.g. File, Edit, View, etc.) they can be contained within a menu element: menu cmd/ cmd/ cmd/ /menu (where each cmd contains a select and a button, as above) Well, what I don't like about this scenario is that we end up with a lot of different markup in menu: | menu | a/ | cmd/ | command/ | li/ | menulabel/ | menu label=/ | /menu Is that really a problem? Besides, there's already a lot without cmd, it just adds one more. As for a stand-alone cmd elements being drop down menus, it mirrors what I've been trying to do with menulabel. Thoughts: * Merge command and menulabel. What? How are they in any way similar? * Merge cmd and menulabel. AIUI, the difference between them can be
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Mon, 28 Nov 2005, Ian Bicking wrote: I think select isn't a very good basis for menus. Current (good) DHTML menus are richer than selects allow for, with things like nested menus. That can't be simulated with selects. Sure. As you point out, though, if the author is willing to do the leg work would probably be quite possible to take whatever markup we describe as being the menu markup and use it for DHTML menus. The reason I suggested that we should allow for easy fallback onto select is that for the menu-button use case, it's very easy to implement that kind of menu using select (and is done often today), and so it would allow for a seamless fallback (if we do it right). -- 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 Mon, 28 Nov 2005, Lachlan Hunt wrote: How about this, or some variation of: form ... menubar libutton type=submit for=foo name=menuFoo/button select id=foo name=foo ... /select /li ... /menubar /form Interesting idea. I like the non-JS fallback potential. Pity about the menubar being necessary to get the select to disappear, but I guess we need that... I originally just used menu, which is why the lis are there, but I'm not sure if its really is necessary. Couldn't the for attribute used to associate the button with the the select, be used to determine how to render the controls without the menu/menubar/etc. wrapper? It's unfortunate about the button being first, too. From an implementation perspective, is there any reason why it couldn't work with the order of the button and select elements swapped? At the moment, I thinking it should work if the button and select are just immediate siblings of each other in any order, though I'm not sure if it should work if there were other content in between. I guess we could change that if we say that in the new world in an li any selects are ignored and just the button is looked for... Hmm. I'm not sure I understand. Wouldn't that break many existing documents which do have select and buttons inside li elements? What if it were done like this: label button for=fooFoo/button select id=foo ... /select /label or label select id=foo ... /select button for=fooFoo/button /label In these cases, the button is acting as the label for the select menu which makes sense semantically and it probably wouldn't require any extraneous menu[bar] markup. There is, however, still the extra |for| attribute, but I think it (or something similar) is necessary so that we don't inadvertently break any existing documents that do have buttons and selects together in a label element. Alternatively, we could ditch the |for| attribute and substitute another element for label or, if possible, do as I suggested above and just use the |for| attribute to associate them regardless of their parent/ancestor elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Quoting Ian Hickson [EMAIL PROTECTED]: Matthew has pretty much convinced me that trying to grandfather the current DHTML menu syntaxes into the new markup is not worth it, so we can ignore that requirement. http://alistapart.com/articles/dropdowns is what can be done today with quite good markup. Only nested lists suck a bit as the html:a and html:ul are siblings. (One inline-level and on block-level.) Replacing html:ul with html:menu and it would be a real menu. How is: p menubar label for=x Action... /label select id=x onchange=... ... /select /menubar /p Good back-compat story, but far too heavy on the markup. Suboptimal element name menubar, with no obvious alternatives. ... much different from: menu label=Action Action... select onchange=... ... /select /menu It seems the html:p element suddenly wasn't necessary anymore, but otherwise... (html:label element versus label attribute.) These seem to be the better options. Or give the option element a boolean attribute label... I wonder though how you'd handle nested dropdown menu's inside a html:select element etc. Perhaps with optgroup etc. But with no better styling mechanism for form controls this idea is never going to make it. From that perspective using html:menu with html:li etc. is much better I guess. -- Anne van Kesteren http://annevankesteren.nl/
