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

2007-11-01 Thread Ian Hickson
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

2007-11-01 Thread Ian Hickson
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

2006-01-08 Thread Ian Hickson
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

2006-01-08 Thread Ian Hickson
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

2006-01-08 Thread Ian Hickson
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

2005-12-30 Thread Ian Hickson
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

2005-12-19 Thread Ian Hickson
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

2005-12-19 Thread Ian Hickson
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

2005-12-19 Thread Ian Hickson
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

2005-12-19 Thread Ian Hickson
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

2005-12-16 Thread Nate H.
 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

2005-12-15 Thread Nate H.
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

2005-12-15 Thread Sander Tekelenburg
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

2005-12-14 Thread Nate H.
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

2005-12-14 Thread Lachlan Hunt

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

2005-12-14 Thread Matthew Raymond
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

2005-12-14 Thread Ian Hickson
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

2005-12-14 Thread Lachlan Hunt

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

2005-12-14 Thread Ian Hickson
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

2005-12-14 Thread Ian Hickson
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

2005-12-14 Thread Ian Hickson
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

2005-12-14 Thread Lachlan Hunt

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

2005-12-14 Thread Alexey Feldgendler
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

2005-12-14 Thread Alexey Feldgendler

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

2005-12-13 Thread Alexey Feldgendler

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

2005-12-13 Thread Matthew Raymond
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

2005-12-13 Thread Ian Hickson
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

2005-12-13 Thread Ian Hickson
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

2005-12-12 Thread Ian Hickson
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

2005-12-10 Thread Sander Tekelenburg
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

2005-12-08 Thread Nathan Heagy
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

2005-12-07 Thread Matthew Raymond
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

2005-12-07 Thread Matthew Raymond
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

2005-12-07 Thread Matthew Raymond
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

2005-12-07 Thread Ian Hickson
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

2005-12-07 Thread Ian Hickson
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

2005-12-07 Thread Nathan Heagy

  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

2005-12-07 Thread Ian Hickson
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

2005-12-07 Thread David Hyatt
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

2005-12-07 Thread Ian Hickson
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

2005-12-07 Thread Ian Hickson
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

2005-12-07 Thread Lachlan Hunt

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

2005-12-07 Thread Matthew Raymond
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

2005-12-07 Thread David Hyatt

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

2005-12-06 Thread Ian Hickson
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

2005-12-06 Thread Ian Hickson
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

2005-12-06 Thread Ian Hickson
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

2005-12-06 Thread Ian Hickson
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

2005-12-06 Thread Ian Hickson
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

2005-12-06 Thread Ian Hickson
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

2005-12-06 Thread Lachlan Hunt

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

2005-12-03 Thread Matthew Raymond
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

2005-12-03 Thread Anne van Kesteren

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

2005-12-03 Thread Matthew Raymond
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

2005-12-02 Thread Anne van Kesteren

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

2005-12-02 Thread Matthew Raymond
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

2005-12-02 Thread Matthew Raymond
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

2005-12-02 Thread Anne van Kesteren

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

2005-12-01 Thread Lachlan Hunt

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

2005-12-01 Thread Matthew Raymond
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

2005-11-30 Thread Matthew Raymond
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

2005-11-29 Thread Lachlan Hunt

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

2005-11-28 Thread Ian Hickson
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

2005-11-28 Thread Lachlan Hunt

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

2005-11-27 Thread Anne van Kesteren

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/