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

On Mon, 9 Jan 2006, Sander Tekelenburg wrote: > >> > >> Authors can only suggest presentation, in the end the *user* decides > >> on it. That's the essence of the Web. Thus we should not be thinking > >> merely about what authors want, but at least as much, and probably > >> more, about what use

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

On Mon, 9 Jan 2006, Sander Tekelenburg wrote: > At 01:21 + UTC, on 2006-01-09, Ian Hickson wrote: > >> > >> I constantly see friends, family, clients, strangers, colleagues > >> struggle to figure out how to navigate through sites they don't know > >> yet. > > > > Well sure, I struggle throug

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

Hi, From: Sander Tekelenburg <[EMAIL PROTECTED]> [nav {display:meta}] >> It wouldn't need to take up *any* room. > > Um. I'd rather like to see the navigation somewhere! Just click your device's "nav" button, or whatever implementation it offers, and WHOOSH, there it is ;) I believ

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

At 05:19 + UTC, on 2006-01-09, Ian Hickson wrote: > 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 a

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

At 01:21 + UTC, on 2006-01-09, Ian Hickson wrote: > On Sun, 1 Jan 2006, Sander Tekelenburg 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 s

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

On Mon, 9 Jan 2006, Sander Tekelenburg wrote: > > Authors can only suggest presentation, in the end the *user* decides on > it. That's the essence of the Web. Thus we should not be thinking merely > about what authors want, but at least as much, and probably more, about > what users want. As a

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

At 01:01 + UTC, on 2006-01-09, Ian Hickson wrote: [...] > 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. Authors can only suggest presentation, in the end the *user

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

At 17:07 + UTC, on 2006-01-01, Jim Ley wrote: > On 1/1/06, Sander Tekelenburg <[EMAIL PROTECTED]> wrote: [...] > help - how many sites does this apply to? Maybe not that many today, but we could think out of the box: in a situation where browsers recognise it as a standard navigation item,

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

On Sun, 1 Jan 2006, Sander Tekelenburg wrote: > > > > I'm not convinced the problem you describe is real. For example, you > > say "Ask any WWW newbie; ask any experienced Web surfer; ask any Web > > site developer "what are the biggest problems with Web sites?" and > > chances are "navigation"

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

On Sun, 1 Jan 2006, Alexey Feldgendler wrote: > > I once noticed that my wife, who is a university student and volunteers > to maintain a simple informational web site for other students in her > group, makes external links from the site like this: > > http://example.com/some-page";>http://examp

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

On Sun, 1 Jan 2006, Sander Tekelenburg wrote: > > > > If we're trying to solve the "problem" of displaying the link > > navigation twice (once in the page and once in the browser UI) then > > I'm not convinced that's a problem, or that we should be solving it. > > It's a problem because it wast

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

On 1/1/06, Sander Tekelenburg <[EMAIL PROTECTED]> wrote: I'm a 100% with Ian here, LINK is dead. > It could offer "shortcuts" (key combo's) to standard LINKs like > next, previous, help, search, home. Etc. next/previous - most pages on the internet don't have a meaningful next/previous state, an

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

On Sun, 01 Jan 2006 21:24:51 +0600, Sander Tekelenburg <[EMAIL PROTECTED]> wrote: 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. A little offtopic: this isn't speci

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

At 01:03 + UTC, on 2005/12/31, Ian Hickson wrote: [...] > If we're trying to solve the problem of _sending_ the data twice We're not. >, that is > easily solvable, by using rel="" on elements instead of > elements. Yes, but only if browsers would support display:meta. > If we're trying

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

At 01:21 + UTC, on 2005/12/20, Ian Hickson wrote: > On Thu, 15 Dec 2005, 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; as

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

On 12/31/05, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Wed, 21 Dec 2005, Alexey Feldgendler wrote: > > > > > > It may just be me, but I perceive a great deal of difference between > > > "IE supports CSS poorly" and "IE doesn't support CSS at all", only the > > > latter of which seems relevant in

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

On Thu, 15 Dec 2005, Sander Tekelenburg wrote: > > I can't follow that. (Btw, meta data doesn't have to be "visible", it > has to be *accessible*.) You seem to mean to say that there is something > wrong with LINK itself, while I think the problem is with > implementations in user-agents. The o

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

On Wed, 21 Dec 2005, Alexey Feldgendler wrote: > > > > It may just be me, but I perceive a great deal of difference between > > "IE supports CSS poorly" and "IE doesn't support CSS at all", only the > > latter of which seems relevant in the context of the `link` element. > > Here is a practical

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

On Tue, 20 Dec 2005, Sander Tekelenburg wrote: > > Maybe I'm misunderstanding what you mean, but it seems to me that the > only way server-side includes can help with this in in the sense of > authors not having to define the same content twice. The user-agent will > still *receive* it twice, r

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

On Tue, 20 Dec 2005, Alexey Feldgendler wrote: > > > > It's less abstract as far as the authors are concerned, because to > > them there is a direct relationship between the document.write() and > > what they see on their screen, as opposed to an indirect one that > > depends on the UA implemen

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

At 10:33 +0530 UTC, on 2005/12/21, Aankhen wrote: > On 12/20/05, Sander Tekelenburg <[EMAIL PROTECTED]> wrote: >> Thus again it is an issue of Microsoft's relative monopoly in the browser >> world. But I don't see many people arguing to declare CSS dead just because >> IE's CSS support sucks. So w

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

On Wed, 21 Dec 2005 11:03:09 +0600, Aankhen <[EMAIL PROTECTED]> wrote: Thus again it is an issue of Microsoft's relative monopoly in the browser world. But I don't see many people arguing to declare CSS dead just because IE's CSS support sucks. So why should we look that way at LINK? It may

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

On 12/20/05, Sander Tekelenburg <[EMAIL PROTECTED]> wrote: > Thus again it is an issue of Microsoft's relative monopoly in the browser > world. But I don't see many people arguing to declare CSS dead just because > IE's CSS support sucks. So why should we look that way at LINK? It may just be me,

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

At 01:07 + UTC, on 2005/12/20, Ian Hickson wrote: > On Thu, 15 Dec 2005, Alexey Feldgendler wrote: [...] >> Currently, we have which works great in browsers which understand it. > > Which is roughly none of them. Depends on how you look at it. My perception is that roughly all browsers sup

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

On Tue, 2005-12-20 at 10:32 +0600, Alexey Feldgendler wrote: > On Tue, 20 Dec 2005 06:58:08 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: > > > (Though could be replaced by

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

On Tue, 20 Dec 2005, Alexey Feldgendler wrote: > > is only for XSLT stylesheets, isn't it? No, is exactly equivalent to with the same attributes except the alternate="" attribute, except if it has alternate="yes", in which case it is exactly equivalent to with the same attributes except the

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

On Tue, 20 Dec 2005 07:07:29 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: 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

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

On Tue, 20 Dec 2005 06:58:08 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: (Though could be replaced by

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

On Thu, 15 Dec 2005, Alexey Feldgendler wrote: > > 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

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

On Thu, 15 Dec 2005, Nate H. wrote: > > > > > Many people have tried this kind of thing in the past, with little > > > success. As far as I can tell, there is little interest from Web > > > authors in describing their site map (which is more a graph than a > > > tree, and which is getting all th

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

On Thu, 15 Dec 2005, Alexey Feldgendler wrote: > > On Thu, 15 Dec 2005 04:31:05 +0600, Lachlan Hunt <[EMAIL PROTECTED]> > wrote: > > > > I'm guessing nesting a within another will break current > > > UAs. > > > > Sub-menus like that will be handled with nested elements. > > Are current browse

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

On Thu, 15 Dec 2005, Lachlan Hunt wrote: > > > > I think the fact that supports rel="" gives us a way to drop > > altogether, actually. > > What about ? I don't expect > to perform the same function. I didn't mean "altogether", my bad. There are various rel= values that still make sense o

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

On Thu, 15 Dec 2005, Lachlan Hunt wrote: > > > > > > > > > >> onchange="if (this.options[this.selectedIndex].value) > > location = > > this.options[this.selectedIndex].value"> > > Select site: > >http://www.apple.com/

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

> Google sitemap does not describe the graph at all, it's just a linear list > of pages on the site, nothing more. I still think it's prefereable to have the graph XML that authors can get "for free" otherwise I'm not sure they'll use it. It seems logical to use a site map to map the navigation bu

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

At 02:21 + UTC, on 2005/12/15, Ian Hickson wrote: > 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.

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

At 11:39 +0600 UTC, on 2005/12/15, Alexey Feldgendler wrote: [...] > 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 >

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

At 00:42 + UTC, on 2005/12/15, Ian Hickson wrote: > On Tue, 13 Dec 2005, Alexey Feldgendler wrote: [...] >> One possible solution that comes to my mind is describing a site map >> with some tree of nested elements, with page titles, URIs and other meta >> information, but without any present

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

On 12/14/05, Alexey Feldgendler <[EMAIL PROTECTED]> wrote: > On Thu, 15 Dec 2005 06:42:37 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: > > >> One possible solution that comes to my mind is describing a site map > >> with some tree of nested elements, with page titles, URIs and other meta > >> info

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

On Thu, 15 Dec 2005 06:42:37 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is co

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

On Thu, 15 Dec 2005 04:31:05 +0600, Lachlan Hunt <[EMAIL PROTECTED]> wrote: I'm guessing nesting a within another will break current UAs. Sub-menus like that will be handled with nested elements. Are current browsers ready for nested ? -- Opera M2 9.0 TP1 on Debian Linux 2.6.12-1-k7

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

Ian Hickson wrote: On Wed, 14 Dec 2005, Sander Tekelenburg wrote: But then still, until they all do, authors will have to continue providing in-body navigational content. One of the key concepts Tantek often pushes in the microformats forums is the idea that metadata should be visible. viola

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

On Wed, 14 Dec 2005, Nate H. wrote: > > Not too ugly, just a little bit ugly. Would this be able to handle menus > within menus? I'm guessing nesting a within another > will break current UAs. Submenus in this context would be done using (if the container is ) or nested s (if it is not). --

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

On Wed, 14 Dec 2005, Sander Tekelenburg wrote: > > Personally I wouldn't mind upgrading LINK to something that user-agents > must support :) The spec can require whatever it likes, that won't in any way make browsers support things. :-) > But then still, until they all do, authors will have t

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

On Wed, 14 Dec 2005, Matthew Raymond wrote: > > > > What I really want is an attribute whose values convey "acts as a ul > > with no magic", > > I prefer "list". Yeah, I agree "list" makes sense here. > > "declares a menu for use elsewhere", > > "resource"? "submenu"? "slave"? (Don't entirel

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

On Tue, 13 Dec 2005, Nate H. wrote: > > > > First of all, my suggestion is that submenus always have an > > associated . > > 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

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

On Tue, 13 Dec 2005, Alexey Feldgendler wrote: > > I think there's nothing wrong in using the menus for navigation except > that such a solution makes an impression of something presentational > rather than semantic. No more so, IMHO, than a aragraph of links, or a ist of links, is presentat

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

On Tue, 13 Dec 2005, Matthew Raymond wrote: > > First of all, my suggestion is that submenus always have an associated > . 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:

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

Ian Hickson wrote: How about: Select site: http://www.apple.com/";> Apple http://www.mozilla.org/";> Mozilla http://www.opera.com/";> Opera Ignoring this abuse of select as a navigational menu which would be b

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

Nate H. wrote: >> First of all, my suggestion is that submenus always have an >>associated . > > I've taken 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 t

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

Nate H. wrote: I'm guessing nesting a within another will break current UAs. Sub-menus like that will be handled with nested elements. -- Lachlan Hunt http://lachy.id.au/

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

Not too ugly, just a little bit ugly. Would this be able to handle menus within menus? I'm guessing nesting a within another will break current UAs. N > > > > onchange="if (this.options[this.selectedIndex].value) > location = this.o

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

On Wed, 14 Dec 2005, Ian Hickson wrote: > > > > > > > > > How about: Select site: http://www.apple.com/";> Apple http://www.mozilla.org/";> Mozilla http://www.opera.com/";> Opera

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

>First of all, my suggestion is that submenus always have an > associated . I've taken 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: > N

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

At 02:05 + UTC, on 2005/12/13, Ian Hickson 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. Exactly. I think that's a good rea

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

Ian Hickson wrote: > I'm not attached to "context". (I'm not particularly fond of "popup", > though). Pretty much my exact thoughts on the matter. > What I really want is an attribute whose values convey "acts as a > ul with no magic", I prefer "list". > "declares a menu for use elsewher

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

On Mon, 28 Nov 2005, Ian Hickson wrote: > On Mon, 28 Nov 2005, Lachlan Hunt wrote: > > > > How about this, or some variation of: > > > > > > > > Foo > > > > ... > > > > > > Bar > > > > ... > > > > > > > > > > > > -- Behaviour in Current U

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

On Tue, 13 Dec 2005, Matthew Raymond wrote: > > > > The problem with > > > > > > foo > > ... > > > > > > ...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 . Simple. You don't

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

On Tue, 13 Dec 2005, Matthew Raymond wrote: > >Hmm. The name "context" as a menu |type| is more semantic, but less > accurate in non-context-menu cases, such as popup menus and submenus. > The name "popup" is more general, but more presentational. I'm not attached to "context". (I'm not par

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

Nathan Heagy wrote: > While it is true that authors will want to style their menu buttons it's > not true that every menu item would need a label. In that case nesting > inside its label becomes quite ugly with a menu of menus only > some of which have labels: > > > > Foo >

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

On Tue, 13 Dec 2005 08:05:45 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: Well, the menu feature is not being _designed_ for navigation, but I'm sure that authors would try to use it for navigation. There is a clear demand on Web sites today for menu-based navigation. A side note about naviga

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

005 7:24 AM To: Ian Hickson Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted Ian Hickson wrote: > In the case of , the presence or absence of the attribute > directly affects the immediate rendering of the other element, and any > re

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

Ian Hickson wrote: > In the case of , the presence or absence of the attribute > directly affects the immediate rendering of the other element, and any > reference to one element requires examining the other element. It's a much > closer relationship, and one that happens continually, not just a

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

On Sun, 11 Dec 2005, Matthew Raymond wrote: > > > > My main problems with the current spec are that it is aethetically > > unpleasing, IMHO. One of the things I don't like (sorry Matthew!) is > > the whole sibling- thing. It just doesn't feel right. > > (Adding a for="" attribute doesn't really

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

On Sat, 10 Dec 2005, Sander Tekelenburg wrote: > > Ah. Maybe I misunderstood your aim then. I got the impression there was > also talk of "navigation menus" in this thread. Is the idea then that > may contain , to define a menu to be for navigation? (I'll > assume this for the example below.)

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

Ian Hickson wrote: > On Sun, 4 Dec 2005, Matthew Raymond wrote: > My main problems with the current spec are that it is aethetically > unpleasing, IMHO. One of the things I don't like (sorry Matthew!) is the > whole sibling- thing. It just doesn't feel right. (Adding a > for="" attribute doesn't

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

At 20:38 + UTC, on 2005/12/09, Ian Hickson wrote: > On Fri, 9 Dec 2005, Sander Tekelenburg wrote: [...] > 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

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

On Fri, 9 Dec 2005, Sander Tekelenburg wrote: > > How does all this menus stuff relate to the LINK element? I'm getting > the feeling that this might kill the best of what the LINK element has > to offer: ease of navigation through recognisability. has had ten years to prove itself. It failed.

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

How does all this menus stuff relate to the LINK element? I'm getting the feeling that this might kill the best of what the LINK element has to offer: ease of navigation through recognisability. Most websites use "menus" for navigation. Every website presents this differently, even though often se

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

On Thu, 8 Dec 2005, Nathan Heagy wrote: > > I wasn't actually suggesting be merged with , just that your > definition of menu as "A list of available options" was too broad to be > the criteria for defining . Ah, indeed. Yes, I agree my definition was too broad, I was just trying to show that

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

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, fallba

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

As a child of a or . dave On Dec 7, 2005, at 8:47 PM, Matthew Raymond wrote: David Hyatt wrote: Shipping Safari actually supports as separators in dropdowns now. We needed this for Dashboard widgets that wanted to be able to put separators into their select UI. Is that inside an or

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

David Hyatt wrote: > Shipping Safari actually supports as separators in > dropdowns now. We needed this for Dashboard widgets that wanted to > be able to put separators into their select UI. Is that inside an or as a direct child of ?

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

On Wed, 7 Dec 2005, Nathan Heagy wrote: > > > > menu n. A list of available options. > > If the definition of menu is too vague then couldn't we include and > ? Especially since people make dynamic menus with these right now. is an unordered list of items. is an ordered list of items. is

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

On Thu, 8 Dec 2005, Lachlan Hunt wrote: > > > > I don't really want to add a lot of new attributes to ; > > What new attributes are you talking about? Option already has a label > attribute in HTML4. All the ones that has. -- Ian Hickson U+1047E)\._.,--,'``

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

Ian Hickson wrote: On Wed, 7 Dec 2005, Matthew Raymond wrote: I don't really want to add a lot of new attributes to ; What new attributes are you talking about? Option already has a label attribute in HTML4. -- Lachlan Hunt http://lachy.id.au/

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

Shipping Safari actually supports as separators in dropdowns now. We needed this for Dashboard widgets that wanted to be able to put separators into their select UI. dave On Dec 7, 2005, at 4:00 PM, Ian Hickson wrote: Then again, toolbars often have separators, so maybe they're a ty

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

On Wed, 7 Dec 2005, Matthew Raymond wrote: > > > > > > > > > > > > > >Doesn't the following do the same? > > > > > > It does if we say it does. Why would we do this? I don't really want to add a lot of new attributes to ; it would overload and that el

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

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 m

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

On Wed, 7 Dec 2005, Lachlan Hunt wrote: > > > > > > I just had a thought that maybe this could be marked up by including > > > the within the element... However, this would only be > > > possible in XHTML documents. > > > > Yeah, in HTML it would force the to open. An option for XHTML, > > i

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

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

On Sun, 4 Dec 2005, Matthew Raymond wrote: > > The more I look at the current spec, the better thought out it > appears to be. Heh. Thanks. :-) My main problems with the current spec are that it is aethetically unpleasing, IMHO. One of the things I don't like (sorry Matthew!) is the whole sibl

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

Ian Hickson wrote: > My current thinking is to have an attribute on the to distinguish > the type of menu, from a list of three types: context menu (hidden until > activated), tool bar/menu bar/menu button/whatever you call it (turns each > command into a button, and each submenu into a menu bu

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

Ian Hickson wrote: > On Tue, 29 Nov 2005, Matthew Raymond wrote: > >>Well, what I don't like about this scenario is that we end up with a lot >>of different markup in : >> >>| >>| >>| >>| >>| >>| >>| >>| > > > So the situation would be: > > > Z > Z > Z

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

Ian Hickson wrote: > On Thu, 1 Dec 2005, Matthew Raymond wrote: >>Thought: >> >>| >>| Menu Item 1 >>| ... >>| >> >>Hmm. > > That could work. It's an advanced feature though. (Anything involving > indirection is going to be harder for users; the more indirection, the > harder it is, IMHO. T

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

Ian Hickson wrote: On Sat, 3 Dec 2005, Lachlan Hunt wrote: Earlier, Ian Hickson wrote: 1. Providing a menu bar for the entire window (or application, on Mac)... I just had a thought that maybe this could be marked up by including the within the element... However, this would only be possibl

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

On Sat, 3 Dec 2005, Lachlan Hunt wrote: > > I wouldn't mind requiring li for content other than cmd, since we > already use it within ul for menus, and other than reduced markup, I see > no other benefit in leaving it out. Reduced markup is quite an important goal. Another important goal is bei

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

On Thu, 1 Dec 2005, Matthew Raymond wrote: >>> >>> You're mistaken. The caption actually isn't the menu label in >>> many cases. >> >> Since the button itself wouldn't act

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

On Tue, 29 Nov 2005, Matthew Raymond wrote: > > Well, what I don't like about this scenario is that we end up with a lot > of different markup in : > > | > | > | > | > | > | > | > | So the situation would be: Z Z Z ...or: Z Z Z

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

On Tue, 29 Nov 2005, Lachlan Hunt wrote: > > After much though, I've refined my original idea and also gone back to > Ian's original idea that navigation menus and command are the same > structure, only differing in their functionality. > > Each command menu is marked up like this: > > > >

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

On Tue, 29 Nov 2005, Matthew Raymond wrote: Foo ... ... >>> Interesting idea. I like the non-JS fallback potential. Pity about the >>> being necessary to get the to disappear, but I >>> guess we need that... > > I

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

On Tue, 29 Nov 2005, Lachlan Hunt wrote: > > Couldn't the for attribute used to associate> the button with the the > select, be used to determine how to render the controls without the > menu/menubar/etc. wrapper? Making one element render or not render according to an attribute on another elem

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

Anne van Kesteren wrote: > Quoting Matthew Raymond <[EMAIL PROTECTED]>: >>Without fallback, this would be the following: >> >>| Menu Label >>| >>| >>| Item 1 >>| Item 2 >>| Item 3 >>| > > Too much markup imho. Especially for the one with fallback. We're talking about this... | | Menu L

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

Quoting Matthew Raymond <[EMAIL PROTECTED]>: Without fallback, this would be the following: | Menu Label | | | Item 1 | Item 2 | Item 3 | Too much markup imho. Especially for the one with fallback. As you can see, uses the |list| attribute from Web Forms 2.0 to load data from a . Sin

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

Anne van Kesteren wrote: > Another idea I had was to make the first element when it has a > particular ancestor element a label. So instead of saying it explicitly > it gets > its semantics from where it appears. > > > this is the label > >this is not > > I don't see why we can't

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

Quoting Matthew Raymond <[EMAIL PROTECTED]>: First, I don't like the idea of abuse of legacy markup any more than I like abuse of current markup. Second, already has a |label| attribute. Indeed, it has. Somehow I missed that. Another idea I had was to make the first element when it has a par

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

Quoting Lachlan Hunt <[EMAIL PROTECTED]>: My phone's built in browser doesn't support javascript at all. Users with limited or no JS support isn't just limited to those that choose to disable it or accessibility clients. Phones are an entirely different beast. If you want to build real applic

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

Lachlan Hunt wrote: > Anne van Kesteren wrote: >>I wonder if there always is a element. There was also this suggestion: >> >># >># Action ... >># Select All >># Deselect All >># Archive Selected >># > > > That's an interesting idea, and kind of fits with the existing abuse of > the first

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

Lachlan Hunt wrote: > Matthew Raymond wrote: | Label Text | | | | >>> >>>We already have 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 overloadin

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

Anne van Kesteren wrote: 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. It's not a form in the traditional sense, it is designed as a standalone widget. The form is just there for fallback to give server side process

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

Quoting Lachlan Hunt <[EMAIL PROTECTED]>: My point is that this command menu is basically made up of a label, a select control and a button, and that we already have a element for associating with select elements. Therefore, we don't need to use another type of label element for that. is f

  1   2   >