«

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

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,

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

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.

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

In article
< us.utvinternet.ie>,
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)

In message
< us.utvinternet.ie>,
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

In message <kristiaan->, Kris
<> writes
>In article
>< cus.utvinternet.ie>,
> 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 <> 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