Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Is there a preferred structure for navigation links?

Reply
Thread Tools

Is there a preferred structure for navigation links?

 
 
dorayme
Guest
Posts: n/a
 
      03-02-2009
In article
<49ab37d5$0$4234$(E-Mail Removed)>,
"asdf" <(E-Mail Removed)> wrote:

> "dorayme" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article <(E-Mail Removed)>,
> > "nice.guy.nige" <(E-Mail Removed)> wrote:
> >
> >> 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.

> >
> > This is simply untrue.
> >
> > --
> > dorayme

>
> 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.

--
dorayme
 
Reply With Quote
 
 
 
 
asdf
Guest
Posts: n/a
 
      03-02-2009

"dorayme" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article
> <49ab37d5$0$4234$(E-Mail Removed)>,
> "asdf" <(E-Mail Removed)> wrote:
>
>> "dorayme" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > In article <(E-Mail Removed)>,
>> > "nice.guy.nige" <(E-Mail Removed)> wrote:
>> >
>> >> 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.
>> >
>> > This is simply untrue.
>> >
>> > --
>> > dorayme

>>
>> 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?
>


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.

>
> --
> dorayme



 
Reply With Quote
 
 
 
 
dorayme
Guest
Posts: n/a
 
      03-02-2009
In article
<49ab637d$0$4211$(E-Mail Removed)>,
"asdf" <(E-Mail Removed)> wrote:


> >> I'm with Nige on this one...

>
> I never take sides...


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

> > 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.
>


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.

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


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.

--
dorayme
 
Reply With Quote
 
asdf
Guest
Posts: n/a
 
      03-02-2009

"dorayme" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article
> <49ab637d$0$4211$(E-Mail Removed)>,
> "asdf" <(E-Mail Removed)> wrote:
>
>
>> >> I'm with Nige on this one...

>>
>> I never take sides...

>
> 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.


>> > 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.
>>

>
> 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.

>
>> 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).
>


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.

>> 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.


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.

>> 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.
>


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.

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

>
> 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,
one needn't code as an <ol>. A <ul> makes more sense.

> --
> dorayme



 
Reply With Quote
 
Adrienne Boswell
Guest
Posts: n/a
 
      03-02-2009
Gazing into my crystal ball I observed dorayme
<(E-Mail Removed)> writing in
news:(E-Mail Removed):

>> 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?
>


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...
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      03-02-2009
In article
<49abc8ef$0$4227$(E-Mail Removed)>,
"asdf" <(E-Mail Removed)> wrote:

> "dorayme" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article
> > <49ab637d$0$4211$(E-Mail Removed)>,
> > "asdf" <(E-Mail Removed)> wrote:


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

> > 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.
>

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
than <table> for the reasons I indicated?

> > 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*...


>
> 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.

> > 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.
>


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?

> >> 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.

....
> > 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'.
>


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 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.
> >

>
> 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.

--
dorayme
 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      03-02-2009
In article <Xns9BC249F9598C3arbpenyahoocom@207.115.33.102>,
Adrienne Boswell <(E-Mail Removed)> wrote:

> Gazing into my crystal ball I observed dorayme
> <(E-Mail Removed)> writing in
> news:(E-Mail Removed):
>
> >> 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?
> >

>
> 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.

--
dorayme
 
Reply With Quote
 
asdf
Guest
Posts: n/a
 
      03-02-2009

"dorayme" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article
> <49abc8ef$0$4227$(E-Mail Removed)>,
> "asdf" <(E-Mail Removed)> wrote:
>
>> "dorayme" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > In article
>> > <49ab637d$0$4211$(E-Mail Removed)>,
>> > "asdf" <(E-Mail Removed)> wrote:

>
> OK asdf, no more jokes from me about "sides" from now on, promise!
>
>> > 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.
>>

> 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
> than <table> for the reasons I indicated?
>
>> > 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*...

>
>>
>> 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.
>
>> > 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.
>>

>
> 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?
>
>> >> 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.

> ...
>> > 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'.
>>

>
> 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 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.
>> >

>>
>> 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.
>


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


> --
> dorayme



 
Reply With Quote
 
Awful Dog Autry
Guest
Posts: n/a
 
      03-02-2009
On 02 Mar 2009, Adrienne Boswell <(E-Mail Removed)> wrote:

> Gazing into my crystal ball I observed dorayme
> <(E-Mail Removed)> writing in
> news:(E-Mail Removed):
>
>>> 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?
>>

>
> 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.

--
Awful Dog Autry
 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      03-02-2009
In article <(E-Mail Removed)>,
Awful Dog Autry <(E-Mail Removed)> wrote:

> 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.

--
dorayme
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Disable the navigation buttons for IE navigation toolbar Laurahn ASP .Net 3 02-06-2007 04:17 AM
Memory allocation in Structure to Structure pra_ramli@rediffmail.com C++ 2 03-09-2006 05:51 AM
Copy String structure "A" to string structure "B" Leo Nunez C Programming 3 02-09-2005 05:14 AM
Pointers to structure and array of structure. Excluded_Middle C Programming 4 10-26-2004 05:39 AM
DHTML javascipt-based navigation structure and flash: how to set the layer? Markus Mohr Javascript 2 10-31-2003 08:34 PM



Advertisments