Is there a preferred structure for navigation links?

M

Mike Silva

Newbie question so bear with me. I'm wondering if there is a
preferred underlying structure for encoding menus (either vertical or
horizontal) of navigation links. I've seen references to using tables
and also to using lists (using CSS to make them not look like lists).
So what's recommended and what is to be avoided? Or is the question
itself malformed?

Mike
 
J

Jonathan N. Little

Mike said:
Newbie question so bear with me. I'm wondering if there is a
preferred underlying structure for encoding menus (either vertical or
horizontal) of navigation links. I've seen references to using tables
and also to using lists (using CSS to make them not look like lists).
So what's recommended and what is to be avoided? Or is the question
itself malformed?

Well if a nav menu is a *list* of links, then a *list* seems link a
reasonable choice. How it is styled is up to you and the page's
requirements.

Tables have been used because of many factors, mostly because of the
lack of CSS support in legacy browsers and other times because of legacy
mindset of designers. In defense, some effects can problematic with IE,
most can be overcome.
 
T

Tim Greer

Mike said:
Newbie question so bear with me. I'm wondering if there is a
preferred underlying structure for encoding menus (either vertical or
horizontal) of navigation links. I've seen references to using tables
and also to using lists (using CSS to make them not look like lists).
So what's recommended and what is to be avoided? Or is the question
itself malformed?

Mike

CSS/divs usually work well, but I've seen some issues in some browsers
and had to revert to using tables at times. Of course, out of all of
the stuff I do, I'm not a designer type of person and I only care that
the layout works for most browsers and people without requiring
anything that could make any portion of the site not work (i.e., it
should work in even text browsers), so take that for what it's worth.
 
D

dorayme

Tim Greer said:
CSS/divs usually work well, but I've seen some issues in some browsers
and had to revert to using tables at times. Of course, out of all of
the stuff I do, I'm not a designer type of person and I only care that
the layout works for most browsers and people without requiring
anything that could make any portion of the site not work (i.e., it
should work in even text browsers), so take that for what it's worth.

Well, what is it worth? <g>

Let's see now. Why would you fail to mention the one element that is
almost exclusively used for navigational displays by good web designers?
The list element!

The reason it is best to use a list where it looks good cross browser is
that it is the simplest, most specialist element for the job. Tables are
not necessarily incorrect for displaying lists because tables are
essentially a tool for organising lists. But it is wrong to use them
when the specialist list tool will do. A bit like it is wasteful and
cumbersome in to use the truck to ferry grandma to church when you could
drive her in the car (or push her in a wheeled chair).

The specialist tools of lists have certain advantages of flexibility
that tables do not have. List items, for example, in a horiz list can
wrap and this is often a very good thing. They can also be made not to
wrap, no need for a table yet on this score! They have in built nifty
features like default bulleting which you might want (but which are
often turned off for navigation).

Jonathan Little's earlier post has it right and he hints at why
sometimes tables have been used.
 
T

Tim Greer

dorayme said:
Well, what is it worth? <g>

Not too much. :)
Let's see now. Why would you fail to mention the one element that is
almost exclusively used for navigational displays by good web
designers? The list element!

I was speaking in reply to the tables comment, but yeah, if it'll work
better as a list, then that's the way to go.
 
M

Mike Silva

Newbie question so bear with me.  I'm wondering if there is a
preferred underlying structure for encoding menus (either vertical or
horizontal) of navigation links.  I've seen references to using tables
and also to using lists (using CSS to make them not look like lists).
So what's recommended and what is to be avoided?  Or is the question
itself malformed?

OK then, I gather that lists are a good solution, and tables are an
acceptable fallback solution. I just wanted to get some confidence
that what I was reading was in the mainstream and not just one
person's quirky viewpoint - after all, to somebody without knowledge
and experience, anything can be made to sound reasonable. :-\

Thanks to all.

Mike
 
N

nice.guy.nige

While the city slept, Mike Silva feverishly typed:
OK then, I gather that lists are a good solution,

Yes they are.
and tables are an acceptable fallback solution.

No they're not.

Tables are used to present tabular data. Your list of links is *not* tabular
data, it is a *list* and should be marked up as such.

It really isn't that hard to produce some really funky looking menus, just
using an unordered list and some CSS. Have a google and have fun
experimenting :)

Cheers,
Nige
 
A

asdf

dorayme said:
This is simply untrue.

I'm with Nige on this one... a menu is a list of items from which the user
may choose, and *semantically* *should* be coded as a list. If one
subscribes adheres to the 'semantic markup' ethos, then tables are not
acceptable for menu construction, IMHO.
 
D

dorayme

"asdf said:
I'm with Nige on this one... a menu is a list of items from which the user
may choose, and *semantically* *should* be coded as a list. If one
subscribes adheres to the 'semantic markup' ethos, then tables are not
acceptable for menu construction, IMHO.

Nearly everyone is 'with Nige' on this one and that is why it is a
spectacle for me.

But since you do not refer to all my previous efforts and arguments to
explain all this stuff, I suppose I owe it to you and me and everyone
else here not to repeat the whole business. But perhaps I should say a
little something since I assume you are more than merely interested in
lining up on one side or other?

1. It is wrong (and would be very surprising) that the 'semantic markup'
ethos implies you should *never* *ever* use a one col or one row table.
a consequence of your assertion above.

2. A table is essentially a convenient way to organise lists, a one col
or one row table being a limiting case of organising one list.

3. A two col table is very much a thoroughly correct *option* (not
requirement) for an ordered list, the order being in one col and the
list items in the other.
 
A

asdf

dorayme said:
Nearly everyone is 'with Nige' on this one and that is why it is a
spectacle for me.

But since you do not refer to all my previous efforts and arguments to
explain all this stuff, I suppose I owe it to you and me and everyone
else here not to repeat the whole business. But perhaps I should say a
little something since I assume you are more than merely interested in
lining up on one side or other?

I never take sides... like everyone here, I'm just trying to make sense of
all this 'esoterica' nonsense that surrounds our profession :)
1. It is wrong (and would be very surprising) that the 'semantic markup'
ethos implies you should *never* *ever* use a one col or one row table.
a consequence of your assertion above.

No, because from *accessibility and semantic* standpoints, a menu is not by
nature tabular data. Arranging menu items using tables implies
(semantically) that the coder is presenting data rather than UI elements.

If, on the other hand, you DID have some tabluar data to display (like maybe
database records containing a single field (your example) or single record),
then it is perfectly acceptable, indeed it would be CORRECT to use a table.
Note that tables, semantically speaking *should* contain 'header' rows as a
minimum to explain what the data actually is, even if you style them to be
invisible.

I guess what I'm talking about here is 'best practice' as opposed to
'acceptable practice'.

I still stand by Nigel's assertion that tables are not an acceptable
fallback position, since it is so very, very easy to do it better through
styled lists, even if it's technically *possible* to do it. If tables are
acceptable *to you* to organise nav links then good luck to you.

I'm sure you've already read all that stuff on www.alistapart.com, and
especially http://www.alistapart.com/articles/taminglists/ but I include the
link here for others that may be interested.
2. A table is essentially a convenient way to organise lists, a one col
or one row table being a limiting case of organising one list.

It may be convenient (debatable), but it is still, in my view, semantically
incorrect (see 1).
3. A two col table is very much a thoroughly correct *option* (not
requirement) for an ordered list, the order being in one col and the
list items in the other.

Ah no. A table by it's very nature should not rely on order of data
necessarily, since data can be displayed in any order you choose, where its
meaning is contained in the actual data, and not its order. An ordered list,
however does. (Though why you would have an 'ordered list' for menu items
escapes me.
 
D

dorayme

I never take sides...

cf. your statements above, my naughty editing bringing the contradiction
out in relief... said:
No, because from *accessibility and semantic* standpoints, a menu is not by
nature tabular data. Arranging menu items using tables implies
(semantically) that the coder is presenting data rather than UI elements.

How do you come to the idea that a menu is not tabular data?
If, on the other hand, you DID have some tabluar data to display (like maybe
database records containing a single field (your example) or single record),
then it is perfectly acceptable, indeed it would be CORRECT to use a table.

So why is a menu not suitable for a col or row? What is suitable? The
sizes of planets from Mercury to Neptune? (which I have urged, read
earlier, post in this thread to use an OL *preferably* Are you on "my
side" in this urging? or did you miss my urging for ULs and OLs as a
first choice).

Let's say the planet size figures are at least kosher on your reckoning
for a table.

So why not a menu exactly? Why not, really why? What is the argument
besides the utterance "it is not tabular data". It is the data of the
main menu items on the site. or it is the data on the local menu items
on the page.
Note that tables, semantically speaking *should* contain 'header' rows as a
minimum to explain what the data actually is, even if you style them to be
invisible.
I would say this is untrue but I am willing to hear your argument for
this. No quotes from authority figures please, not interested in these
unless you tell them to talk to me directly. The context alone could be
all the information a user would need to understand what is going on
without <TH>s (assuming you are talking these latter). If you had a
paragraph beforehand to give context or a heading saying "Planet sizes",
there would be no need. Same with menu items not needing any particular
formal heading preceding. It can be obvious.
I guess what I'm talking about here is 'best practice' as opposed to
'acceptable practice'.
Best practice is not on the same road that leads to people refusing to
use tables when tables are in fact kosher. Pretty well every week in
some periods, we get examples of these thoroughly frightened
individuals. Your's and Nige's mistake is subtler but no less an error
imo.

....
Ah no. A table by it's very nature should not rely on order of data
necessarily,

This is either too vague, irrelevant or plain wrong. The orders of many
of the lists in a table are very much *necessarily ordered*. Take a two
col table of products and prices. Once the products are set out in
whatever arbitrary fashion, the list of prices is then extremely ordered
or false info will result.
 
A

asdf

dorayme said:
cf. your statements above, my naughty editing bringing the contradiction
out in relief... <g>

Oh come on... agreeing with someone is not the same as 'taking sides' ffs.

How do you come to the idea that a menu is not tabular data?

Because it's a *list* of links. Believe me- I understand your point of view,
but lists make so much more sense for a menu.
So why is a menu not suitable for a col or row? What is suitable? The
sizes of planets from Mercury to Neptune? (which I have urged, read
earlier, post in this thread to use an OL *preferably* Are you on "my
side" in this urging? or did you miss my urging for ULs and OLs as a
first choice).

Can we stop this 'sides' rubbish now please.

No, I didn't miss it... I was responding to your advocacy on using tables as
a menu structure, not on your prior post.
Let's say the planet size figures are at least kosher on your reckoning
for a table.

So why not a menu exactly? Why not, really why? What is the argument
besides the utterance "it is not tabular data". It is the data of the
main menu items on the site. or it is the data on the local menu items
on the page.

A menu is a list by it's very nature. A representation of planets is data.
Pretty simple really.
I would say this is untrue but I am willing to hear your argument for
this. No quotes from authority figures please, not interested in these
unless you tell them to talk to me directly.
Ridiculous.

The context alone could be
all the information a user would need to understand what is going on
without <TH>s (assuming you are talking these latter). If you had a
paragraph beforehand to give context or a heading saying "Planet sizes",
there would be no need. Same with menu items not needing any particular
formal heading preceding. It can be obvious.

Not necessarily to a 'screen reader'.

Context alone does NOT explain content. Any reading about accessibility
issues in web design will tell you this.
Best practice is not on the same road that leads to people refusing to
use tables when tables are in fact kosher. Pretty well every week in
some periods, we get examples of these thoroughly frightened
individuals. Your's and Nige's mistake is subtler but no less an error
imo.

I'm sorry, but it's just nonsense to reject quality for the sake of
convenience, especially when the quality solution is actually easier (and,
importantly, smaller) to implement.

I never said that tables aren't "kosher", merely that there's a better
alternative.
...

This is either too vague, irrelevant or plain wrong. The orders of many
of the lists in a table are very much *necessarily ordered*. Take a two
col table of products and prices. Once the products are set out in
whatever arbitrary fashion, the list of prices is then extremely ordered
or false info will result.

But of course! Ok- it was vague. You're talking about mixing up the order of
fields, not of records, which, as you well know, is not what was meant.
Ok... maybe I should have spelled it out for you. For that I apologise for
making the assumption that you would understand the difference between a
field and a record (in relational db parlance), without explicitly stating
same.

Please allow me to rephrase... the order of *records* presented in a table
need not be important.

In any case, we're getting off the track here... For the purposes of a menu,
 
A

Adrienne Boswell

Gazing into my crystal ball I observed dorayme
How do you come to the idea that a menu is not tabular data?

I wasn't going to jump into this thread... but here I go!

There are a few kinds of menus. A menu in a restaurant, or a menu
provided by your cable/satellite provider are definately tabular data
because there is a corresponding value for each item in a grid, eg:

<table>
<caption>7 am</caption>
<thead>
<tr>
<th>Channel</th><th>Program</th>
</tr>
</thead>
<tbody>
<tr>
<td>2</td><td>News</td>
</tr>
<tr>
<td>28</td><td>Sesame Street</td>
</tr>
</tbody>
</table>

or

<table>
<caption>Lunch</caption>
<thead>
<tr>
<th>Item</th><th>Price</th>
</tr>
</thead>
<tbody>
<tr>
<td>Hamburger</td><td>$5.00</td>
</tr>
<tr>
<td>Salad</td><td>$6.00</td>
</tr>
</tbody>
</table>

Whereas a menu for a web site is a _List of Choices_ that usually do not
have a name/value pair relationship, eg:

<ul>
<li><a href="index.php">Home</li>
<li><a href="contact.php">Contact</li>
</ul>

Which brings me to the use of tables and forms. Before data is
submitted by the user, there is no name/value pair relationship, so use
label and input. When the data comes back from the user, you have your
name/value pair relationship, and you could display the data in tabular
format.

Okay, gotta go... I have to feed my son and take him to Kindergarten...
see you...
 
D

dorayme

OK asdf, no more jokes from me about "sides" from now on, promise!
Because it's a *list* of links. Believe me- I understand your point of view,
but lists make so much more sense for a menu.
That is the trouble, what is the sense in your "lists make so much more
sense for a menu" *beyond* my earlier recommendation to use <ul> rather
No, I didn't miss it... I was responding to your advocacy on using tables as
a menu structure, not on your prior post.

I am saying that you cannot leave out *why* I advocate a formal html
list (ul or ol) over a table for menu items and not misunderstand me. I
have a certain view of what semantic meaning is in relation to html
elements and what a table is and what a list is and the idea that a
table is not semantically wrong follows from what i imagine are these
first principles.
A menu is a list by it's very nature. A representation of planets is data.
Pretty simple really.

Time to say what your idea of data is that excludes the possibility of
menu items being data. A number of things relating to planets is
information. So is a number of menu items, information; with the usually
added linking mechanism (except sometimes for the 'current').

Why is a series of points of information in the one so datarish in the
one case and not the other?
Not necessarily to a 'screen reader'.

Not necessarily to a 'screen reader' where the context is clear for a
list but not a table? Always happy to learn about screen readers. Tell
me: Why would a list of menu items that said "Home" and "About us" be
more intelligible than a table with cells via a screen reader?
Context alone does NOT explain content. Any reading about accessibility
issues in web design will tell you this.

Will it now? I must have missed the bleeding obvious it in spite of
reading my fair share. I just can't see how a table relating prices to
products needs content *explained*. It is often bleeding obvious. I
can't see how a list of planet sizes is *explained* by being in a list.

I don't think many people realise *sufficiently* that users do not get
to see mark-up and would not know if a list was in an HTML list, a table
or in divs or other elements.

The whole idea of the appropriate element to use has, contrary to many
people's ideas, to do with what presentation will best communicate the
information. And you have said nothing to show that an HTML table can
*never ever* be as good for this purpose as an HTML list for a list.
I'm sorry, but it's just nonsense to reject quality for the sake of
convenience, especially when the quality solution is actually easier (and,
importantly, smaller) to implement.
I am not rejecting quality. You are assuming what we are debating. You
are wrong to suppose that a table is *always* inferior. There are cases
where ordered list information is easier to style in some ways in a two
col table rather than an OL. There is an increase in quality, not a
decrease.
I never said that tables aren't "kosher", merely that there's a better
alternative.
You are saying that they are not quite the correct thing to use out of
two choices, no matter what the circumstances. I am saying they can be
quite the correct thing. You are not saying merely that one is generally
a better way than the other. That's me that says this.

Gee asdf, let's remember that you are you and I am me. You are a fine
upstanding commonsensical fellow. I am an out of control ET freak
stalking cinema houses for decent films. We could not be more different.
 
D

dorayme

Adrienne Boswell said:
Gazing into my crystal ball I observed dorayme


I wasn't going to jump into this thread... but here I go!
I was thinking about you, Adrienne and was wondering when you might come
in and teach this grandma here how to suck eggs. You have tried before
on this one. But simple nostrums cannot really the cure the disease of
understanding that those who "side with Nige" seem to think I suffer
from. <g>

Anyway, while here, just a comment or two from me since you went to the
trouble.
There are a few kinds of menus. A menu in a restaurant, or a menu
provided by your cable/satellite provider are definately tabular data
because there is a corresponding value for each item in a grid, eg: ....
You leave out mentioning the one col or one row table. And since you
cannot leave this out of the discussion, your simple repetition of the
very thing I have argued against time and time again in some detail is
not at all helpful. You are merely assuming and repeating what I deny.
Whereas a menu for a web site is a _List of Choices_ that usually do not
have a name/value pair relationship, eg:
....

Perhaps you might deepen your argument by denying that a one row or a
one col table is semantically meaningful?

Interested in a little bet with a field test to see how many people are
inconvenienced in a context of my choosing where the comparison is
between a page they see or hear or feel of 3 little menu items in an
HTML list compared with same in a one col table?

Or here is another little bet proposal to all you folk who 'side with
Nige': Let's compare the effect on real people in two web pages one in
which an ordered list is presented visually, aurally or braillerly (I am
willing to include smellerly too because I am confident!) in an OL as
compared to in a table.
 
A

asdf

dorayme said:
OK asdf, no more jokes from me about "sides" from now on, promise!

That is the trouble, what is the sense in your "lists make so much more
sense for a menu" *beyond* my earlier recommendation to use <ul> rather



I am saying that you cannot leave out *why* I advocate a formal html
list (ul or ol) over a table for menu items and not misunderstand me. I
have a certain view of what semantic meaning is in relation to html
elements and what a table is and what a list is and the idea that a
table is not semantically wrong follows from what i imagine are these
first principles.


Time to say what your idea of data is that excludes the possibility of
menu items being data. A number of things relating to planets is
information. So is a number of menu items, information; with the usually
added linking mechanism (except sometimes for the 'current').

Why is a series of points of information in the one so datarish in the
one case and not the other?


Not necessarily to a 'screen reader' where the context is clear for a
list but not a table? Always happy to learn about screen readers. Tell
me: Why would a list of menu items that said "Home" and "About us" be
more intelligible than a table with cells via a screen reader?


Will it now? I must have missed the bleeding obvious it in spite of
reading my fair share. I just can't see how a table relating prices to
products needs content *explained*. It is often bleeding obvious. I
can't see how a list of planet sizes is *explained* by being in a list.

I don't think many people realise *sufficiently* that users do not get
to see mark-up and would not know if a list was in an HTML list, a table
or in divs or other elements.

The whole idea of the appropriate element to use has, contrary to many
people's ideas, to do with what presentation will best communicate the
information. And you have said nothing to show that an HTML table can
*never ever* be as good for this purpose as an HTML list for a list.

I am not rejecting quality. You are assuming what we are debating. You
are wrong to suppose that a table is *always* inferior. There are cases
where ordered list information is easier to style in some ways in a two
col table rather than an OL. There is an increase in quality, not a
decrease.

You are saying that they are not quite the correct thing to use out of
two choices, no matter what the circumstances. I am saying they can be
quite the correct thing. You are not saying merely that one is generally
a better way than the other. That's me that says this.

Gee asdf, let's remember that you are you and I am me. You are a fine
upstanding commonsensical fellow. I am an out of control ET freak
stalking cinema houses for decent films. We could not be more different.

Haha... ok then... we're agree then :)

 
A

Awful Dog Autry

Gazing into my crystal ball I observed dorayme


I wasn't going to jump into this thread... but here I go!

There are a few kinds of menus. A menu in a restaurant, or a menu
provided by your cable/satellite provider are definately tabular data
because there is a corresponding value for each item in a grid, eg:

<table>
<caption>7 am</caption>
<thead>
<tr>
<th>Channel</th><th>Program</th>
</tr>
</thead>
<tbody>
<tr>
<td>2</td><td>News</td>
</tr>
<tr>
<td>28</td><td>Sesame Street</td>
</tr>
</tbody>
</table>

or

<table>
<caption>Lunch</caption>
<thead>
<tr>
<th>Item</th><th>Price</th>
</tr>
</thead>
<tbody>
<tr>
<td>Hamburger</td><td>$5.00</td>
</tr>
<tr>
<td>Salad</td><td>$6.00</td>
</tr>
</tbody>
</table>

Whereas a menu for a web site is a _List of Choices_ that usually do
not have a name/value pair relationship, eg:

<ul>
<li><a href="index.php">Home</li>
<li><a href="contact.php">Contact</li>
</ul>

Which brings me to the use of tables and forms. Before data is
submitted by the user, there is no name/value pair relationship, so
use label and input. When the data comes back from the user, you
have your name/value pair relationship, and you could display the
data in tabular format.

Okay, gotta go... I have to feed my son and take him to
Kindergarten... see you...

I think that's it. You need a correspondence between 2 or more values
for really tabular data. Most website menus are just a list of
categories, singular apiece and not tabular.
 
D

dorayme

Awful Dog Autry said:
I think that's it. You need a correspondence between 2 or more values
for really tabular data.

Then you either think wrong, along with Nige, asdf and Adrienne or else
it is kosher to use tables for 'non-tabular data' as long as it is not
for mere page layout.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top