Re: Is there a preferred structure for navigation links?


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


.

Relevant Pages

  • Re: Time to shut down this list?
    ... These reasons are correct, ... "if we can't talk about FreeBSD ... I think it's probably human nature; ... There are plenty of other FreeBSD mailing lists, ...
    (freebsd-newbies)
  • Re: shootout: implementing an interpreter for a simple procedural language Minim
    ... About the internal representation (store as ints or lists of ... This is the nature ... of abstraction. ...
    (comp.lang.functional)
  • Re: Removing self.
    ... r> nature to me but does that mean it is really needed?? ... Bruce Eckel proposes removing self from argument lists: ... Guido responds: ...
    (comp.lang.python)
  • [opensuse] Unable to get matrox G550 in dualscreen
    ... There are also so many lists added, so if there is another list better ... The goal of nature ... is to build better mice. ... To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx ...
    (SuSE)
  • Re: vertical size calculation
    ... but as long as you understand what tabular data is. ... from tables to lists and immediately found that the list box height is ... How do you calculate table heights? ... should be the exact same height as they use the same CSS style class. ...
    (alt.html)
Loading