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
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.
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
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
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
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
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 =
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=
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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 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
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
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
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
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.
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.)
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
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
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
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
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
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
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,
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
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
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
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
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.
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.
--
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?
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.
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
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
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/
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
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 --
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
So... menus.
I've spent the last few days carefully examining all the posts on context
menus that have been sent to the list (mainly Matthew Raymond's excellent
proposals), as well as looking at the current draft in the spec, and real-
world markup on major sites.
There are four main use
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
66 matches
Mail list logo
