Is there a preferred structure for navigation links?

Discussion in 'HTML' started by Mike Silva, Feb 28, 2009.

  1. Mike Silva

    Mike Silva Guest

    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
     
    Mike Silva, Feb 28, 2009
    #1
    1. Advertising

  2. Mike Silva wrote:
    > 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.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Feb 28, 2009
    #2
    1. Advertising

  3. Mike Silva

    Paul Guest

    "Mike Silva" <> ha scritto nel messaggio
    news:...
    > Newbie question so bear with me. I'm wondering if
    > cut


    I am a newbie too, and in my website I have used tables and css after the help of some friend in this news group.
    My "buttons" contain texts and/or images. This is the site:

    http://www.tortebomboniere.com/bomboniere/favourcake01.html

    Paul
     
    Paul, Feb 28, 2009
    #3
  4. Mike Silva

    Tim Greer Guest

    Mike Silva wrote:

    > 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.
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
     
    Tim Greer, Feb 28, 2009
    #4
  5. Mike Silva

    dorayme Guest

    In article <7egql.6752$>,
    Tim Greer <> wrote:

    > Mike Silva wrote:
    >
    > > 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?
    > >

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

    --
    dorayme
     
    dorayme, Feb 28, 2009
    #5
  6. Mike Silva

    Tim Greer Guest

    dorayme wrote:

    > 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.
    --
    Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
    Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
    and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
    Industry's most experienced staff! -- Web Hosting With Muscle!
     
    Tim Greer, Feb 28, 2009
    #6
  7. Mike Silva

    Mike Silva Guest

    On Feb 28, 12:22 pm, Mike Silva <> wrote:
    > 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
     
    Mike Silva, Mar 1, 2009
    #7
  8. 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

    --
    Nigel Moss | http://www.nigenet.org.uk
    Email not valid. - take the dog out!
    "You're mother ate my dog!", "Not all of him..."
     
    nice.guy.nige, Mar 2, 2009
    #8
  9. Mike Silva

    dorayme Guest

    In article <>,
    "nice.guy.nige" <> 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
     
    dorayme, Mar 2, 2009
    #9
  10. Mike Silva

    asdf Guest

    "dorayme" <> wrote in message
    news:...
    > In article <>,
    > "nice.guy.nige" <> 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.
     
    asdf, Mar 2, 2009
    #10
  11. Mike Silva

    dorayme Guest

    In article
    <49ab37d5$0$4234$>,
    "asdf" <> wrote:

    > "dorayme" <> wrote in message
    > news:...
    > > In article <>,
    > > "nice.guy.nige" <> 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
     
    dorayme, Mar 2, 2009
    #11
  12. Mike Silva

    asdf Guest

    "dorayme" <> wrote in message
    news:...
    > In article
    > <49ab37d5$0$4234$>,
    > "asdf" <> wrote:
    >
    >> "dorayme" <> wrote in message
    >> news:...
    >> > In article <>,
    >> > "nice.guy.nige" <> 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
     
    asdf, Mar 2, 2009
    #12
  13. Mike Silva

    dorayme Guest

    In article
    <49ab637d$0$4211$>,
    "asdf" <> 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
     
    dorayme, Mar 2, 2009
    #13
  14. Mike Silva

    asdf Guest

    "dorayme" <> wrote in message
    news:...
    > In article
    > <49ab637d$0$4211$>,
    > "asdf" <> 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
     
    asdf, Mar 2, 2009
    #14
  15. Gazing into my crystal ball I observed dorayme
    <> writing in
    news::

    >> 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
     
    Adrienne Boswell, Mar 2, 2009
    #15
  16. Mike Silva

    dorayme Guest

    In article
    <49abc8ef$0$4227$>,
    "asdf" <> wrote:

    > "dorayme" <> wrote in message
    > news:...
    > > In article
    > > <49ab637d$0$4211$>,
    > > "asdf" <> 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
     
    dorayme, Mar 2, 2009
    #16
  17. Mike Silva

    dorayme Guest

    In article <Xns9BC249F9598C3arbpenyahoocom@207.115.33.102>,
    Adrienne Boswell <> wrote:

    > Gazing into my crystal ball I observed dorayme
    > <> writing in
    > news::
    >
    > >> 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
     
    dorayme, Mar 2, 2009
    #17
  18. Mike Silva

    asdf Guest

    "dorayme" <> wrote in message
    news:...
    > In article
    > <49abc8ef$0$4227$>,
    > "asdf" <> wrote:
    >
    >> "dorayme" <> wrote in message
    >> news:...
    >> > In article
    >> > <49ab637d$0$4211$>,
    >> > "asdf" <> 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
     
    asdf, Mar 2, 2009
    #18
  19. On 02 Mar 2009, Adrienne Boswell <> wrote:

    > Gazing into my crystal ball I observed dorayme
    > <> writing in
    > news::
    >
    >>> 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
     
    Awful Dog Autry, Mar 2, 2009
    #19
  20. Mike Silva

    dorayme Guest

    In article <>,
    Awful Dog Autry <> 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
     
    dorayme, Mar 2, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. msnews.microsoft.com
    Replies:
    2
    Views:
    484
    Steven Cheng[MSFT]
    Apr 22, 2004
  2. Hardeep Rakhra
    Replies:
    6
    Views:
    409
    Hardeep Rakhra
    Jan 12, 2004
  3. Laurahn
    Replies:
    3
    Views:
    911
    Steven Cheng[MSFT]
    Feb 6, 2007
  4. Zeba
    Replies:
    0
    Views:
    435
  5. Andy B

    images on navigation links

    Andy B, Nov 19, 2008, in forum: ASP .Net
    Replies:
    3
    Views:
    306
    Andy B
    Nov 19, 2008
Loading...

Share This Page