Re: Is there a preferred structure for navigation links?

In article
<49abc8ef$0$4227$5a62ac22@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"asdf" <asdf@xxxxxxxx> wrote:

"dorayme" <doraymeRidThis@xxxxxxxxxxxxxxx> wrote in message
news:doraymeRidThis-C9CD26.19041202032009@xxxxxxxxxxxxxxxxxxxx
In article
<49ab637d$0$4211$5a62ac22@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"asdf" <asdf@xxxxxxxx> 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
.

Relevant Pages

  • Re: Im sure I shall regret this.............
    ... The html was last overhauled to make use of tables, ... lists of the same facts about a large number ... So that's not what HTML is for, it's for saying what _sort_ of ... thing Dave was saying and you could have got here for SFP (these things ...
    (uk.rec.sheds)
  • Re: Why do people detest top posting so much?
    ... "tell" about me based on the fact that I posted in HTML? ... with Noberto's remark about people "from Outlook" feeling top-posting is ... defaulted for *top posting*. ... You just happened to rub a raw wound on the lists. ...
    (Ubuntu)
  • Re: Font specifications
    ... In most cases I readily agree to 'stop wanting that' but in this case ... among other things lists the fonts one has on their ... his options in HTML so he can ... "Is there a way to display these fonts directly from within an html ...
    (comp.infosystems.www.authoring.html)
  • Re: [SLE] Empty Trash
    ... using html, my ISP inbox would fill up easily: some have 3 Mb, some 25Mb. ... Perhaps Novell is more enlightened than the old SuSE ... I simply don't care, here, about what other lists do, or other users do ... > the best email client I've ever used. ...
    (SuSE)
  • A flexible multi-level UL/LI constructor
    ... fairly simple two-level HTML list but where conditional output depending on ... Sub heading 1.3 ... The above examples shows the basic UL/LI nesting which the Perl script needs ... an appropriate method to generate these type of menu lists? ...
    (comp.lang.perl.misc)
Loading