replicating tables with CSS and Divs

Discussion in 'HTML' started by Tom, Aug 22, 2004.

  1. Tom

    Tom Guest

    Hi,

    I have been told that using tables for layout is no longer advised, due to
    accessibility considerations. Instead of tables, I should be using DIVs.

    However, I was wondering how can I replicate the behaviour of various cells
    on the same row, increasing in height at the same time and taking the height
    of the biggest one.

    I have three "cells":

    +------------+ +---------------+ +--------------+
    | | | | |
    |
    | | | | |
    |
    +------------+ +---------------+ +--------------+

    I don't want one of the cell becoming higher than the other two when more
    content is inserted:

    +------------+ +---------------+ +--------------+
    | | | | |
    |
    | | | | |
    |
    +------------+ | | +--------------+
    | |
    +---------------+

    Thanks!

    Tom
     
    Tom, Aug 22, 2004
    #1
    1. Advertising

  2. Tom

    Neal Guest

    On Sun, 22 Aug 2004 15:39:00 +0100, Tom <> wrote:

    > I have been told that using tables for layout is no longer advised, due
    > to
    > accessibility considerations. Instead of tables, I should be using DIVs.


    Yes, but if the content is tabular - if each row and each column groups
    and compares similar data - then table markup is fine, even appropriate.

    > However, I was wondering how can I replicate the behaviour of various
    > cells
    > on the same row, increasing in height at the same time and taking the
    > height
    > of the biggest one.


    This gets a little tricky. You're expecting a div to size itself based on
    a sibling div's content, which isn't how CSS works. Technically, this is
    impossible. We'd need some way of asking the browser which of the 3
    columns is rendered as tallest, and then going back and resetting the two
    smaller heights to the larger value.

    Here's a workaround, which unfortunately requires pixel-fixed widths. Use
    a background image in the CSS for a container div which holds all 3 divs.
    This image is 1 pixel high and as wide as all 3 columns, like this:
    ===+++=== Set it to repeat-y. It should continue to the bottom of the
    parent div like so:

    ===+++===
    ===+++===
    ===+++===
    ===+++===
    ===+++===

    .... giving the illusion of columns. (Be sure to include in the HTML some
    real content within the container div but after the floated columns - use
    a div set to clear. <div class="clear">&nbsp;</div> is what I usually use.

    Another option allows for more flexibility in widths but relies on the
    center column being the longest if there is a longest one. Here, use the
    left and right borders of the center column as background foir the left
    and right column, which are positioned over the borders, again creating
    the illusion of columns.

    Though, if this effect is required for usability, rather than simply
    desired, the data might in fact be in such a relationship that it would
    indeed be table data. In that case table markup would be appropriate for
    these 3 columns.

    Followups set to alt.html.
     
    Neal, Aug 22, 2004
    #2
    1. Advertising

  3. Tom

    Tom Guest

    Neal,

    thank you for the answer. It looks like not using tables will involve lots
    of "tweaking"...

    I must admit I am still a bit unclear about the W3C accessibility
    guidelines: is it OK to use tables for layout or is it forbidden???

    Tom

    "Neal" <> wrote in message
    news:eek:...
    > On Sun, 22 Aug 2004 15:39:00 +0100, Tom <> wrote:
    >
    >> I have been told that using tables for layout is no longer advised, due
    >> to
    >> accessibility considerations. Instead of tables, I should be using DIVs.

    >
    > Yes, but if the content is tabular - if each row and each column groups
    > and compares similar data - then table markup is fine, even appropriate.
    >
    >> However, I was wondering how can I replicate the behaviour of various
    >> cells
    >> on the same row, increasing in height at the same time and taking the
    >> height
    >> of the biggest one.

    >
    > This gets a little tricky. You're expecting a div to size itself based on
    > a sibling div's content, which isn't how CSS works. Technically, this is
    > impossible. We'd need some way of asking the browser which of the 3
    > columns is rendered as tallest, and then going back and resetting the two
    > smaller heights to the larger value.
    >
    > Here's a workaround, which unfortunately requires pixel-fixed widths. Use
    > a background image in the CSS for a container div which holds all 3 divs.
    > This image is 1 pixel high and as wide as all 3 columns, like this:
    > ===+++=== Set it to repeat-y. It should continue to the bottom of the
    > parent div like so:
    >
    > ===+++===
    > ===+++===
    > ===+++===
    > ===+++===
    > ===+++===
    >
    > ... giving the illusion of columns. (Be sure to include in the HTML some
    > real content within the container div but after the floated columns - use
    > a div set to clear. <div class="clear">&nbsp;</div> is what I usually use.
    >
    > Another option allows for more flexibility in widths but relies on the
    > center column being the longest if there is a longest one. Here, use the
    > left and right borders of the center column as background foir the left
    > and right column, which are positioned over the borders, again creating
    > the illusion of columns.
    >
    > Though, if this effect is required for usability, rather than simply
    > desired, the data might in fact be in such a relationship that it would
    > indeed be table data. In that case table markup would be appropriate for
    > these 3 columns.
    >
    > Followups set to alt.html.
     
    Tom, Aug 25, 2004
    #3
  4. Tom

    Neal Guest

    On Wed, 25 Aug 2004 07:29:33 +0100, Tom <> wrote:

    > I must admit I am still a bit unclear about the W3C accessibility
    > guidelines: is it OK to use tables for layout or is it forbidden???


    It is... up for interpretation.

    Certainly if you accept the concept of semantic HTML - that the HTML code
    should be solely used to describe the role of each part of the page,
    rather than its appearance - table markup should only be applied in
    situations where you have row and column relationships you want to compare
    for the visitor.

    Whether W3C makes this clear or not has been debated ad infinitum. Many
    here, though, are proponents of semantic markup, and reserving all
    presentational ideas to the CSS. Google for - "barry pearson" frames
    group:comp.infosystems.www.authoring.html - for a pro-table layout
    perspective.
     
    Neal, Aug 25, 2004
    #4
  5. Tom

    jake Guest

    In message <412c3199$0$20244$>, Tom
    <> writes
    [snip]

    >
    >I must admit I am still a bit unclear about the W3C accessibility
    >guidelines: is it OK to use tables for layout or is it forbidden???
    >

    [snip]

    Yes. It's fine -- so long as the content linearizes properly.

    The W3C recommendation is to use CSS, but the W3C is also pragmatic
    enough to realize that tables-based layouts will be with us for the
    foreseeable future.

    Incidentally -- referring to your original post -- tables-based layouts
    don't have any inherent accessibility problems.

    regards.

    --
    Jake
     
    jake, Aug 25, 2004
    #5
  6. Tom

    Spartanicus Guest

    jake <> wrote:

    >tables-based layouts
    >don't have any inherent accessibility problems.


    Incorrect, any proper [1] talking browser would announce the start of
    tabular data when it encounters a table element.

    [1] Most talking browsers are crap, most assume that nobody uses tables
    correctly. Following this strategy is admitting defeat, don't let bad
    coding win. Don't use tables for layout.

    --
    Spartanicus
     
    Spartanicus, Aug 25, 2004
    #6
  7. Tom

    Kris Guest

    In article
    <>,
    Spartanicus <> wrote:

    > >tables-based layouts
    > >don't have any inherent accessibility problems.

    >
    > Incorrect, any proper [1] talking browser would announce the start of
    > tabular data when it encounters a table element.
    >
    > [1] Most talking browsers are crap, most assume that nobody uses tables
    > correctly. Following this strategy is admitting defeat, don't let bad
    > coding win. Don't use tables for layout.


    Does that mean they do a horrible job at tabular data? I cannot imagine
    that consumers would stick with such a program then. How would they be
    able to read a timetable, for instance?

    --
    Kris
    <> (nl)
     
    Kris, Aug 25, 2004
    #7
  8. Tom

    jake Guest

    In message
    <>,
    Spartanicus <> writes
    >jake <> wrote:
    >
    >>tables-based layouts
    >>don't have any inherent accessibility problems.

    >
    >Incorrect,


    Nope

    >any proper [1] talking browser would announce the start of
    >tabular data when it encounters a table element.
    >
    >[1] Most talking browsers are crap, most assume that nobody uses tables
    >correctly. Following this strategy is admitting defeat, don't let bad
    >coding win. Don't use tables for layout.
    >

    Most modern talking browsers and screen readers handle tables (layout
    and data) just fine.

    Please tell me how you think the use of tables for layout gives a site
    accessibility problems.

    regards.
    --
    Jake
     
    jake, Aug 25, 2004
    #8
  9. Tom

    jake Guest

    In message <4all.nl>, Kris
    <> writes
    >In article
    ><>,
    > Spartanicus <> wrote:
    >
    >> >tables-based layouts
    >> >don't have any inherent accessibility problems.

    >>
    >> Incorrect, any proper [1] talking browser would announce the start of
    >> tabular data when it encounters a table element.
    >>
    >> [1] Most talking browsers are crap, most assume that nobody uses tables
    >> correctly. Following this strategy is admitting defeat, don't let bad
    >> coding win. Don't use tables for layout.

    >
    >Does that mean they do a horrible job at tabular data? I cannot imagine
    >that consumers would stick with such a program then. How would they be
    >able to read a timetable, for instance?
    >

    Most modern ones handle tabular data really well.

    Of course it helps if data tables are marked-up correctly (seemingly an
    art or science that too many people are well versed in).


    regards.
    --
    Jake
     
    jake, Aug 25, 2004
    #9
  10. Tom

    Spartanicus Guest

    jake <> wrote:

    >>[1] Most talking browsers are crap, most assume that nobody uses tables
    >>correctly. Following this strategy is admitting defeat, don't let bad
    >>coding win. Don't use tables for layout.
    >>

    >Most modern talking browsers and screen readers handle tables (layout
    >and data) just fine.


    Name one that announces the start of tabular content correctly whilst
    staying silent on a table used for layout.

    >Please tell me how you think the use of tables for layout gives a site
    >accessibility problems.


    I already did, try reading it again if you didn't understand it.

    --
    Spartanicus
     
    Spartanicus, Aug 25, 2004
    #10
  11. Tom

    jake Guest

    In message
    <>,
    Spartanicus <> writes
    >jake <> wrote:
    >
    >>>[1] Most talking browsers are crap, most assume that nobody uses tables
    >>>correctly. Following this strategy is admitting defeat, don't let bad
    >>>coding win. Don't use tables for layout.
    >>>

    >>Most modern talking browsers and screen readers handle tables (layout
    >>and data) just fine.

    >
    >Name one that announces the start of tabular content correctly whilst
    >staying silent on a table used for layout.


    None that I know of says 'Hey -- here's a data table'. But so what? How
    does this affect accessibility?
    >
    >>Please tell me how you think the use of tables for layout gives a site
    >>accessibility problems.

    >
    >I already did, try reading it again if you didn't understand it.
    >

    Give me the url of *one* page whose information content I cannot access
    because they are using tables for layout.

    Regards.

    --
    Jake
     
    jake, Aug 25, 2004
    #11
  12. Tom

    Spartanicus Guest

    jake <> wrote:

    >>>Most modern talking browsers and screen readers handle tables (layout
    >>>and data) just fine.

    >>
    >>Name one that announces the start of tabular content correctly whilst
    >>staying silent on a table used for layout.

    >
    >None that I know of says 'Hey -- here's a data table'. But so what? How
    >does this affect accessibility?


    If that isn't obvious to you, then I'm afraid it's beyond your ability
    to understand.

    >Give me the url of *one* page whose information content I cannot access
    >because they are using tables for layout.


    Oh dear, another case of the above. Against better judgement I'll try
    anyway: accessibility does not end with the ability to access content.
    It extends to providing coding that enables UAs to distinguish between
    visual layout elements and tabular data without the introduction of
    kludges that attempt to circumvent the problem you've created. Kludges
    like that create new problems.

    Your posts in alt.html.critique demonstrate that you have been able to
    download a talking browser, the mistake you then made was to think that
    therefore you understood accessibility, you don't.

    --
    Spartanicus
     
    Spartanicus, Aug 25, 2004
    #12
  13. Tom

    Neal Guest

    On Wed, 25 Aug 2004 14:03:34 +0100, Spartanicus <> wrote:

    > jake <> wrote:
    >> Give me the url of *one* page whose information content I cannot access
    >> because they are using tables for layout.

    > Your posts in alt.html.critique demonstrate that you have been able to
    > download a talking browser, the mistake you then made was to think that
    > therefore you understood accessibility, you don't.
    >


    Having neither a talking browser nor the expertise in accessibility, I'd
    sure like to see live examples of table layouts which screw up
    accessibility for the talkies, and an explanation of why...
     
    Neal, Aug 25, 2004
    #13
  14. Tom

    jake Guest

    In message
    <>,
    Spartanicus <> writes
    >jake <> wrote:
    >
    >>>>Most modern talking browsers and screen readers handle tables (layout
    >>>>and data) just fine.
    >>>
    >>>Name one that announces the start of tabular content correctly whilst
    >>>staying silent on a table used for layout.

    >>
    >>None that I know of says 'Hey -- here's a data table'. But so what? How
    >>does this affect accessibility?

    >
    >If that isn't obvious to you, then I'm afraid it's beyond your ability
    >to understand.


    Stuck for an answer? Don't worry, I'll let you off this one -- as I can
    see that to press the point would only be to embarrass you further.
    >
    >>Give me the url of *one* page whose information content I cannot access
    >>because they are using tables for layout.

    >
    >Oh dear, another case of the above. Against better judgement I'll try
    >anyway: accessibility does not end with the ability to access content.
    >It extends to providing coding that enables UAs to distinguish between
    >visual layout elements and tabular data without the introduction of
    >kludges that attempt to circumvent the problem you've created. Kludges
    >like that create new problems.



    Ah. Is that the best you can come up with?

    You really must start getting together some proper arguments to
    substantiate your statements.

    (I'd ask you to explain these 'new problems' that the 'kludges' you talk
    about create, but I fear that such an attempt to elicit something useful
    from you would be doomed to failure.)
    >
    >Your posts in alt.html.critique demonstrate that you have been able to
    >download a talking browser, the mistake you then made was to think that
    >therefore you understood accessibility, you don't.


    I'll let the jury decide on that one ;-)
    >

    Anyway. I can see that your knowledge on the subject is somewhat
    limited, so sadly I don't think we're going to move this discussion
    along much further. But if you ever do manage to figure out a coherent
    argument as to how table-based layouts affect accessibility ... well,
    don't be a stranger.

    In the meanwhile, I have an idea. Why not contact the manufacturers of
    the leading AT UAs and demand they take you on as a consultant? You
    could explain that you obviously know more than they do ......

    And then let me know how you get on ;-)

    regards.

    --
    Jake
     
    jake, Aug 25, 2004
    #14
  15. Tom

    Chris Morris Guest

    jake <> writes:
    > Incidentally -- referring to your original post -- tables-based
    > layouts don't have any inherent accessibility problems.


    [Assuming properly linearising ones, of course]

    Yes they do. Try viewing an even slightly complex table layout in
    links, w3m, OpenWave or WebTV. The first two give horizontal scrolling
    which is far more of an inconvenience in text mode than in graphics
    mode. The latter two (especially OpenWave) don't allow horizontal
    scrolling, and so give columns two characters wide.

    All of this is tolerable for data tables (on anything except OpenWave
    rarely a problem anyway), though still irritating on the wider
    ones. It's unnecessarily introducing a problem otherwise.

    There's other more minor side effects, but they can make sites very
    difficult to use in those four browsers.

    Some might argue that this isn't an accessibility issue because none
    of those four browsers are designed for users with disabilities, but I
    would say that that was taking an unnecessarily narrow definition of
    accessibility.

    --
    Chris
     
    Chris Morris, Aug 25, 2004
    #15
  16. Tom

    Chris Morris Guest

    Neal <> writes:
    > On Wed, 25 Aug 2004 14:03:34 +0100, Spartanicus <> wrote:
    > > jake <> wrote:
    > >> Give me the url of *one* page whose information content I cannot access
    > >> because they are using tables for layout.

    > > Your posts in alt.html.critique demonstrate that you have been able to
    > > download a talking browser, the mistake you then made was to think that
    > > therefore you understood accessibility, you don't.

    >
    > Having neither a talking browser nor the expertise in accessibility,


    30 day trial of IBM Home Page Reader is available. Definitely worth using.

    > I'd sure like to see live examples of table layouts which screw up
    > accessibility for the talkies, and an explanation of why...


    Any that don't linearise properly, for exactly the same reason that
    they'd mess up accessibility in Lynx.

    Ones that linearise in a sensible fashion generally aren't a problem
    for speech browsers, but they can be a problem for others (see my
    other post).

    Spartanicus' point that speech browsers could deal far better with
    data tables if they could be sure that the majority of tables were for
    data is true, but applies to non-speech browsers as well [1].

    [1] Wouldn't it be nice if you could select a table column and get the
    average, standard deviation and total calculated automatically -
    convert data tables into a mini read-only spreadsheet through the UA?
    On a typical tables-for-layout page the additional screen furniture to
    do this would clutter things up.

    --
    Chris
     
    Chris Morris, Aug 25, 2004
    #16
  17. Tom

    Spartanicus Guest

    Neal <> wrote:

    >Having neither a talking browser nor the expertise in accessibility, I'd
    >sure like to see live examples of table layouts which screw up
    >accessibility for the talkies, and an explanation of why...


    The most important objection against using tables for layout is that
    they usually wreck content linearization. If you want a demonstration of
    this then it's best to download an aural renderer. It's the best way to
    get a feel for how linear one dimensional access to content differs from
    2 dimensional visual access.

    In some cases content linearization issues caused by using tables for
    layout can be solved without having to ditch the layout tables. This is
    typically done by using multiple tables, for example one table holds the
    top navbar, another table holds a left side bar, yet another table holds
    the content.

    The statement I challenged was that there were no accessibility issues
    with using tables for layout apart from content linearization.

    Chunks of content like list items cannot be interpreted correctly unless
    we mark them up as such. A UA is then able to display them in a
    recognizable manner for visual access, or aurally announce the
    structure. The way to do this for an aural renderer would be to speak
    something like:

    LIST
    item 1
    item 2
    END LIST

    It's no different for tabular content, users who access the content
    aurally need to know before tabular content is read out that what is
    about to follow *is* tabular data, thus an aural render *should* do
    something like this:

    TABLE
    ROW 1
    data
    data
    ROW 2
    data
    data
    END TABLE

    Doing this results in problems since a UA cannot possibly distinguish a
    table used for layout from a table used to hold genuine tabular data.
    That leaves 2 choices for the aural renderer:
    1) Don't announce structural table elements.
    2) Announce all structural table elements.

    (1) Prevents aural users from being informed about, and interact with
    tabular content (e.g. navigate table rows). (2) Confuses aural users by
    announcing tables used for layout as tabular data.

    A kludge for aural renderers that announce structural table elements is
    to add something that may be rendered aurally by a UA that announces a
    table used for layout by speaking something like "table used for
    layout". This alerts aural users, but it doesn't prevent the pointless
    reading out of the structural table elements of the tables used for
    layout.

    The current crop of aural UAs are really poor, not least because most of
    them are speech agents tacked onto renderers like IE with deficient
    support for css media rules. The popular IBM Home Page Reader (HPR) is
    such an example.

    Certain current aural UAs don't announce structural table elements at
    all, nor do they provide table navigation. This has lead to the notion
    amongst some that it therefore doesn't matter if tables are used for
    layout, as long as the content linearizes. This is foolish, it presumes
    that aural renderers will always be as poor as they are currently.

    Content authors should mark up content so that it can be identified
    correctly. Using tables for layout prevents that.

    --
    Spartanicus
     
    Spartanicus, Aug 25, 2004
    #17
  18. Tom

    Neal Guest

    On Wed, 25 Aug 2004 20:09:03 +0100, Spartanicus <> wrote:

    > Certain current aural UAs don't announce structural table elements at
    > all, nor do they provide table navigation. This has lead to the notion
    > amongst some that it therefore doesn't matter if tables are used for
    > layout, as long as the content linearizes. This is foolish, it presumes
    > that aural renderers will always be as poor as they are currently.


    As this leads to more need for semantic markup and clearer more accessible
    pages in general, I want to believe. But one question is niggling me: if
    the UAs won't recognize semantic table use, why would authors change to
    meet them? And if authors continue to use table markup presentationally,
    why would UAs ever change? This catch-22 is a poser regarding the goal of
    more semantic markup and more semantic UAs.

    Short of more universally applied (and enforced) laws requiring pages to
    demonstrate specific accessibility features which are best gained through
    semantic markup, I can't see anyone changing soon. :(
     
    Neal, Aug 25, 2004
    #18
  19. Tom

    jake Guest

    In message <>, Neal
    <> writes
    >On Wed, 25 Aug 2004 14:03:34 +0100, Spartanicus <> wrote:
    >
    >> jake <> wrote:
    >>> Give me the url of *one* page whose information content I cannot access
    >>> because they are using tables for layout.

    >> Your posts in alt.html.critique demonstrate that you have been able to
    >> download a talking browser, the mistake you then made was to think that
    >> therefore you understood accessibility, you don't.
    >>

    >
    >Having neither a talking browser nor the expertise in accessibility,
    >I'd sure like to see live examples of table layouts which screw up
    >accessibility for the talkies, and an explanation of why...


    There really aren't any accessibility problems using tables for layout
    providing that the tables linearize properly (as noted by W3C in their
    Web Content Accessibility Guidelines).

    In practice, linearization is rarely a problem, so you may have
    difficulties in getting someone to give you some live examples ;-)

    If you want to have some idea of the linearization process, just load a
    Web page into Opera, set the Style to 'User mode' and then disable
    Tables.

    UAs do not announce tables so there is no extraneous verbiage to confuse
    the listener when processing a page which uses layout tables (most of
    the Web still uses tables for layout).

    However, the listener can navigate a data table via keyboard with ease,
    assuming it's marked up correctly.

    AT UAs (screen-readers, talking browsers, etc.) have now reached quite a
    high level of sophistication (even if the general-purpose ones can be
    rather expensive to buy) making the Web readily available to the
    visually impaired, the dyslexic, etc..

    Why not download a reader and see for your self?

    regards.


    --
    Jake
     
    jake, Aug 25, 2004
    #19
  20. Tom

    Neal Guest

    On Wed, 25 Aug 2004 21:43:44 +0100, jake <> wrote:

    > Why not download a reader and see for your self?


    If you or another can recommend one that's free (or has a trial long
    enough to allow me to get used to it) and can be reasonably downloaded
    with dialup, and doesn't require me to compile it, AND is worth the time,
    I will do exactly that.
     
    Neal, Aug 25, 2004
    #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. Tim Smith
    Replies:
    2
    Views:
    412
    bruce barker
    Feb 24, 2004
  2. =?Utf-8?B?QmFyZW4=?=

    Replicating XML Node

    =?Utf-8?B?QmFyZW4=?=, Jun 10, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    345
    =?Utf-8?B?QmFyZW4=?=
    Jun 10, 2005
  3. kamalesh
    Replies:
    0
    Views:
    403
    kamalesh
    Feb 19, 2006
  4. rich
    Replies:
    0
    Views:
    724
  5. maya
    Replies:
    4
    Views:
    243
Loading...

Share This Page