When are tables appropriate, and when are they not?

[Alan Silver]

Hello,

I understand the issue that tables should be used for tabular data and
not for layout, but I would like some clarification as to exactly what
constitutes tabular data.

For example, if I have a form, in which the user is required to fill in
various bits of information, then laying out with a table makes it easy.
A basic example...

http://www.kidsinaction.org.uk/TableForm.html

[Please note that this is a very basic quick example knocked up for the
purpose of illustration. In a real example, more effort should be made
to ensure it is accessible, by using label tags, axis and pivot
attributes, etc. This was all omitted for brevity and clarity]

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.

Can this be done in CSS? I know I could treat each row individually, and
use a div, but then how would I get the second column (with the entry
boxes in) to line up? Using a table allows the browser (or whatever
rendering device is being used) to decide how much space to give each
row and column to allow the contents to fit. All the entry boxes line up
vertically in the table.

More to the point, is this actually an abuse of tables? I read a thread
here a while back in which someone suggested that this was reasonable.
It was suggested that this was a form of tabular data. No-one argued
with that, and it seemed a fair suggestion.

Any comments? This is a genuine question, not an intention to troll or
start an argument. I'm really not sure if this is an abuse of tables and
would like to hear the experts' opinion. If it is an abuse, is there a
sensible and simple CSS alternative? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

[Els]

Alan Silver wrote:

[table used to display form]

More to the point, is this actually an abuse of tables? I read a thread
here a while back in which someone suggested that this was reasonable.
It was suggested that this was a form of tabular data. No-one argued
with that, and it seemed a fair suggestion.

My opinion hasn't changed since then ;-) - I use tables for forms.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Gérard Talbot]

Alan Silver wrote :

Hello,

I understand the issue that tables should be used for tabular data and
not for layout, but I would like some clarification as to exactly what
constitutes tabular data.

For example, if I have a form, in which the user is required to fill in
various bits of information, then laying out with a table makes it easy.
A basic example...

http://www.kidsinaction.org.uk/TableForm.html

[Please note that this is a very basic quick example knocked up for the
purpose of illustration. In a real example, more effort should be made
to ensure it is accessible, by using label tags, axis and pivot
attributes, etc. This was all omitted for brevity and clarity]
Thanks for expliciting this. I was about to mention your lack of labels :)

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.
They line up horizontally. Any block-level elements will line up those
elements vertically.

E.g.:
Example of section 17.4.2 Examples of forms containing INPUT controls
http://www.w3.org/TR/html401/interac....html#h-17.4.2

Can this be done in CSS?
Probably. I think so, yes.
I know I could treat each row individually, and use a div, but then how would I get the second column (with the entry
boxes in) to line up? Using a table allows the browser (or whatever
rendering device is being used) to decide how much space to give each
row and column to allow the contents to fit. All the entry boxes line up
vertically in the table.

More to the point, is this actually an abuse of tables?
No, I wouldn't say abuse. Forms (like a subscription form) are often
formatted with tables. What's absolutely nonsense to me is
- use of nested tables
- using table for nothing that is remotedly close to tabular data
- using table with all kinds of spacer.gifs, dozens of   for
horizontal padding, dozens of <br> for vertical ventilation
- seeing a page that has 10, 30 or 50 tables

E.g. Just today, http://www.yahoo.com/ main entrance page has exactly
*_87 nested tables_*. Some days, yahoo.com has over 100 tables with 60
nested tables.
I read a thread here a while back in which someone suggested that this was reasonable.
It was suggested that this was a form of tabular data. No-one argued
with that, and it seemed a fair suggestion.

Any comments? This is a genuine question,
It's ok. It's called a discussion newsgroup. :)

not an intention to troll or start an argument. I'm really not sure if this is an abuse of tables and
would like to hear the experts' opinion. If it is an abuse, is there a
sensible and simple CSS alternative? TIA

I'm sure you will find possible CSS alternatives in the links of this page:

Table-based webpage design versus CSS-based webpage design: resources,
explanations and tutorials
http://www.gtalbot.org/NvuSection/Nv...CSSDesign.html

Gérard
--
remove blah to email me

[Stan Brown]

Sun, 5 Feb 2006 14:40:46 +0000 from Alan Silver <alan-
si****@nospam.thanx.invalid>:

I understand the issue that tables should be used for tabular data and
not for layout, but I would like some clarification as to exactly what
constitutes tabular data.

For example, if I have a form, in which the user is required to fill in
various bits of information, then laying out with a table makes it easy.

As soon as you state it to yourself as "laying it out", alarm bells
should go off in your head. That tells you're you've skipped over the
essential step of asking whether your data actually are tabular.
In the case of a form in particular, you might make a case that the
captions and the fill-ins (text boxes or option lists) are logically
a two-column table, with each caption tied to its fill-in. But that
breaks down if you have any fill-in without a caption.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Gérard Talbot]

Alan Silver wrote :

Hello,
[snipped]

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.

Can this be done in CSS?

In this page,
http://www.alistapart.com/articles/practicalcss/
search and find the section titled

"FORM(s) and Function"

"Another common use for table layout is lining up FORM elements with
their labels. While it could be argued that this is an appropriate use
of TABLEs, the CSS technique that I describe below will prove to be
useful (...)"

Gérard
--
remove blah to email me

[Els]

Stan Brown wrote:

[form being tabular data]

In the case of a form in particular, you might make a case that the
captions and the fill-ins (text boxes or option lists) are logically
a two-column table, with each caption tied to its fill-in. But that
breaks down if you have any fill-in without a caption.

So.. If I have a large table, full of tabular data, and there are some
empty cells in it, it's not a table anymore?

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

[Alan Silver]

>As soon as you state it to yourself as "laying it out", alarm bells

should go off in your head. That tells you're you've skipped over the
essential step of asking whether your data actually are tabular.
Which is why I asked the question ;-)
In the case of a form in particular, you might make a case that the
captions and the fill-ins (text boxes or option lists) are logically a
two-column table, with each caption tied to its fill-in.
Which was precisely the opinion that I quoted in my original post ;-)
But that breaks down if you have any fill-in without a caption.

Why? Even real, honest tabular data sometimes has gaps.

Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

Thanks for the reply. I have made some comments below. Please note that
these are *not* intended to be critical, just to try and explore the
idea further. I am not advocating tables, I am trying to decide if they
can be replacing, without loos of functionality.

<snip>

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.
They line up horizontally. Any block-level elements will line up those
elements vertically.

E.g.:
Example of section 17.4.2 Examples of forms containing INPUT controls
http://www.w3.org/TR/html401/interac....html#h-17.4.2

Yup, they line up horizontally, but *not* vertically. This was precisely
the problem I wish to avoid. This form looks awful, and will cause the
user to become confused. The table approach means that all the entry
boxes are vertically aligned.

Can this be done in CSS?

Probably. I think so, yes.

Please show me how ;-)

Before you do though, I should point out that another advantage of the
table approach is that you don't need to specify a width for either
column. The rendering device decides what width to give them, based on
the size of the available space, size of contents, font size, etc.
Fixing the width, even using ems does not give that flexibility.

<snip>No, I wouldn't say abuse. Forms (like a subscription form) are often
formatted with tables.
So are you saying that you feel this is an appropriate use of tables?
What's absolutely nonsense to me is
- use of nested tables
Depends on the context. I can think of plenty of times when this is
appropriate. Unfortunately, the vast majority of cases in the wild are
not ;-)
- using table for nothing that is remotedly close to tabular data
Agreed, hence my question. Can a form be called tabular?
- using table with all kinds of spacer.gifs, dozens of &nbsp; for
horizontal padding, dozens of <br> for vertical ventilation
- seeing a page that has 10, 30 or 50 tables
Agreed twice

<snip>

Any comments? This is a genuine question,

It's ok. It's called a discussion newsgroup. :)

Sure, but some people (not just here) treat these sort of issues as an
invitation to war!! I am genuinely interested in learning here, and
wanted to preclude any flames.

<snip>I'm sure you will find possible CSS alternatives in the links of this page:

Table-based webpage design versus CSS-based webpage design: resources,
explanations and tutorials
http://www.gtalbot.org/NvuSection/Nv...CSSDesign.html

With all due respect, I only found one link there that attempted to show
how to do layout without tables. There were plenty links to articles
explaining why I shouldn't use tables, but little on how to go about it.

The one link (a list apart) that did do so suffered from problems
mentioned above. Please see my reply to another poster who quoted that
link directly.

Thanks for the reply. Any further comments appreciated.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>> The main advantage of this (ab)use of tables is that the cells

automatically line up both horizontally and vertically.
Can this be done in CSS?

In this page,
http://www.alistapart.com/articles/practicalcss/
search and find the section titled

"FORM(s) and Function"

"Another common use for table layout is lining up FORM elements with
their labels. While it could be argued that this is an appropriate use
of TABLEs, the CSS technique that I describe below will prove to be
useful (...)"

Try increasing the font size of your browser and look again at that
form. The captions become bigger than the fixed space allocated to them,
and the second "column" entry goes down a line, destroying the neat
arrangement that a table would give.

Furthermore, if the user has a big monitor and maximises their browser
(using the common example of a computer user viewing the form in a web
browser), then the fixed width column stays the same width. They don't
get the benefit of the wider space that their big monitor allows. A
table will be resized to use as much space as it can. This is another
big advantage of using tables.

Please understand, I'm not advocating tables, nor am I being
argumentative, I'm just trying to explain why the solutions proposed so
far don't solve the problem as well as a table does. I would be very
happy if someone could propose a CSS solution that works as well.

Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Gérard Talbot]

Alan Silver wrote :

[snipped]

E.g.:
Example of section 17.4.2 Examples of forms containing INPUT controls
http://www.w3.org/TR/html401/interac....html#h-17.4.2
Yup, they line up horizontally, but *not* vertically. This was precisely
the problem I wish to avoid.

Is that vertical lining up problem so bad? really really bad?
This form looks awful, and will cause the user to become confused. The table approach means that all the entry
boxes are vertically aligned.

Can this be done in CSS?
Probably. I think so, yes.

Please show me how ;-)

I have in another post.


Before you do though, I should point out that another advantage of the
table approach is that you don't need to specify a width for either
column.
This is debattable. Declaring a width for <col> and declaring
table-layout: fixed will speed up parsing and rendering in all modern
browsers.

The rendering device decides what width to give them, based on the size of the available space, size of contents, font size, etc.
Fixing the width, even using ems does not give that flexibility.
I never used em for col width; I always used %tage instead.

<snip>

No, I wouldn't say abuse. Forms (like a subscription form) are often
formatted with tables.
So are you saying that you feel this is an appropriate use of tables?

Maybe it's not the best usage. I think what you do is acceptable use of
table. In a spreasheet application or a database application, one could
be using a table to render customer info and its related personal data.

What's absolutely nonsense to me is
- use of nested tables

Depends on the context.

I have no relativity on nested table. A table of tables makes no sense
to me. I wouldn't be able to see or use one in MS-Excel or any
spreadsheet application.
Nested tables is no more sensible than typing on a keyboard located
inside another keyboard, a car traveling inside another car, reading a
book inside another book, etc.

I can think of plenty of times when this is appropriate. Unfortunately, the vast majority of cases in the wild are
not ;-)

Well, that was and still is the challenge issued by David Dorward:

"If you really do have data that should be in nested tables, I do want
to see it!"
http://dorward.me.uk/www/nested/

- using table for nothing that is remotedly close to tabular data

Agreed, hence my question. Can a form be called tabular?

No. A form can be tabular depending on the data it presents.

Gérard
--
remove blah to email me

[Alan Silver]

>>> E.g.:

Example of section 17.4.2 Examples of forms containing INPUT controls
http://www.w3.org/TR/html401/interac....html#h-17.4.2 Yup, they line up horizontally, but *not* vertically. This was
precisely the problem I wish to avoid.

Is that vertical lining up problem so bad? really really bad?

Yup, it looks ugly, and can be very confusing to a significant
percentage of users.
This form looks awful, and will cause the

user to become confused. The table approach means that all the entry
boxes are vertically aligned.

Can this be done in CSS?

Probably. I think so, yes. Please show me how ;-)

I have in another post.

Ah, but I added the caveat below. Unless I missed the point (entirely
likely), the example posted suffered from the problem described
immediately below...

Before you do though, I should point out that another advantage of
the table approach is that you don't need to specify a width for
either column.

This is debattable. Declaring a width for <col> and declaring
table-layout: fixed will speed up parsing and rendering in all modern
browsers.

I have never noticed a problem in rendering speed by not specifying the
width, and I have seen significant advantages in allowing the browser to
decide what to use.
The rendering device decides what width to give them, based on

the size of the available space, size of contents, font size, etc.
Fixing the width, even using ems does not give that flexibility.
I never used em for col width; I always used %tage instead.

Also suffers from serious problems. How do you know in advance what the
relative size of the contents are? Who says a text box will always be
half the size of the caption (or whatever). Using percentages fixes you
to issues like this. Allowing the browser to decide gives the best
balanced layout, taking all the factors into account.

<snip>

No, I wouldn't say abuse. Forms (like a subscription form) are often
formatted with tables.

So are you saying that you feel this is an appropriate use of
tables?

Maybe it's not the best usage. I think what you do is acceptable use of
table.

OK, that's a point worth noting. That was one of my original aims in
posting.
In a spreasheet application or a database application, one could be
using a table to render customer info and its related personal data.
Now you are talking about *real* tabular data. I don't think anyone
would suggest that's not an appropriate use of tables!!

What's absolutely nonsense to me is
- use of nested tables

Depends on the context.

I have no relativity on nested table. A table of tables makes no sense
to me. I wouldn't be able to see or use one in MS-Excel or any
spreadsheet application.

Then you obviously have little experience in data-centric applications
of any real depth. This is not a criticism, just an observation based on
this comment.

Many real-world applications work with hierarchical data, where nested
tables would be appropriate. I have had to develop this sort of thing
many times.

Furthermore, assuming that you accept the use of a table for laying out
a form, what would you do if one part of the form required some tabular
data to be presented to the user? For example, I have a form (on a
private page, so I can't post an URL) where the user can type a template
for an e-mail. They can include various application-specific tags, that
will be interpreted by the application to create a personalised e-mail.
There is a small table showing the syntax for these tags. By necessity,
this table needs to be next to the entry box for the template. This
leads to a nested table. Maybe you think this does not make sense, but
it does to me.
Nested tables is no more sensible than typing on a keyboard located
inside another keyboard, a car traveling inside another car, reading a
book inside another book, etc.
Totally inappropriate comparisons. That's like saying that since you
can't have a filing cabinet inside a filing cabinet, you shouldn't be
allowed directories inside directories on your computer's hard disk. The
one has nothing to do with the other.
I can think of plenty of times when this is

appropriate. Unfortunately, the vast majority of cases in the wild
are not ;-)

Well, that was and still is the challenge issued by David Dorward:

"If you really do have data that should be in nested tables, I do want
to see it!"
http://dorward.me.uk/www/nested/

I've given you a couple above (based on the assumption of using a table
to layout a form of course).

- using table for nothing that is remotedly close to tabular data

Agreed, hence my question. Can a form be called tabular?

No. A form can be tabular depending on the data it presents.

Please explain that last comment as I don't really understand what you
mean.

Thanks for the reply, I'm finding this very informative.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Jim Moe]

Alan Silver wrote:

"FORM(s) and Function"
Try increasing the font size of your browser and look again at that
form. The captions become bigger than the fixed space allocated to them,
and the second "column" entry goes down a line, destroying the neat
arrangement that a table would give.

The widths were specified in px units rather than ems.
Furthermore, if the user has a big monitor and maximises their browser
(using the common example of a computer user viewing the form in a web
browser), then the fixed width column stays the same width. They don't
get the benefit of the wider space that their big monitor allows. A
table will be resized to use as much space as it can. This is another
big advantage of using tables.

It is not uncommon for table-based forms to fix the width of columns as
well. You may not do that allowing the form to fill the space.
Using percentages for widths instead of pixels would accomplish the same
thing in the non-table form.

There is no doubt that tables have certain advantages for layout. Just
not enough.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Alan Silver]

>>>"FORM(s) and Function"

Try increasing the font size of your browser and look again at that
form. The captions become bigger than the fixed space allocated to them,
and the second "column" entry goes down a line, destroying the neat
arrangement that a table would give.

The widths were specified in px units rather than ems.

Yup, but it suffers from similar problems if you change the units to
ems. The problem is that CSS doesn't seem capable of setting a
container's width based on the contents. That's one of the main powers
of tables.

Furthermore, if the user has a big monitor and maximises their browser
(using the common example of a computer user viewing the form in a web
browser), then the fixed width column stays the same width. They don't
get the benefit of the wider space that their big monitor allows. A
table will be resized to use as much space as it can. This is another
big advantage of using tables.

It is not uncommon for table-based forms to fix the width of columns as
well.

Which rather defeats the advantage I was describing. It may not surprise
you to know that I don't do this ;-)
You may not do that allowing the form to fill the space.
Using percentages for widths instead of pixels would accomplish the same
thing in the non-table form.
Nope, that still requires you to guess the relative size of the column
contents. Plus, the percentages are based on the container (likely to be
the window), not the contents.
There is no doubt that tables have certain advantages for layout. Just
not enough.

Well, in this case I'm not so sure. It seems to me that they do have the
edge here. Sure you can get away with CSS-based layouts in this case,
but that presents as many problems as it solves.

Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Gérard Talbot]

Alan Silver wrote :

[snipped]

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.

Can this be done in CSS?

"tableless forms with a good, solid horizontal alignment."
http://www.quirksmode.org/css/forms.html#link3

Gérard
--
remove blah to email me

[Alan Silver]

>> The main advantage of this (ab)use of tables is that the cells

automatically line up both horizontally and vertically.
Can this be done in CSS?

"tableless forms with a good, solid horizontal alignment."
http://www.quirksmode.org/css/forms.html#link3

Yup, but again this suffers form the fact that the width of the first
column is fixed. In this example it's fixed in pxs (really bad idea),
but it wouldn't help if it were fixed in percent or ems.

The big advantage of tables (as I've said a few times) is that the
rendering device will adjust the column size based on the contents,
available space, etc. That way the table looks OK at different
resolutions, client window sizes, different contents, etc. I am still
looking for a way to see if CSS can do this.

Thanks anyway.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>> For example, if I have a form, in which the user is required to fill in

various bits of information, then laying out with a table makes it easy.

As soon as you state it to yourself as "laying it out", alarm bells
should go off in your head. That tells you're you've skipped over the
essential step of asking whether your data actually are tabular.

I was contemplating this again last night, and I'm not so sure I agree
with you. I think the use of the words "laying out" here do not
necessarily indicate pure presentation.

Consider a genuine, no arguments data table, containing real genuine
data. What's the point of the whole <table> structure? To associate
various parts of the data with others. Captions (labels, titles, call
them what you will) are associated with data values.

If I'm creating a form, then I want the captions associated with the
entry controls. In visual terms, that means I want them placing
logically so that a viewing user can see clearly what caption goes with
what control. In terms of other devices, say a screen reader, then I
want it to read out the captions in a way that makes it clear that they
are associated with the controls (however a screen reader handles a
control).

Seen this way, I think that forms are an excellent candidate for tables,
logically speaking. The fact that visual browsers on personal computers
happen to render them well is really a side-effect!! The more I think
about it, the more I feel that the *structure* of a table is the most
appropriate way to set out a table.

Just my thoughts, please feel free to comment.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Gérard Talbot]

Alan Silver wrote :

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.
Can this be done in CSS?
"tableless forms with a good, solid horizontal alignment."
http://www.quirksmode.org/css/forms.html#link3

Yup, but again this suffers form the fact that the width of the first
column is fixed. In this example it's fixed in pxs (really bad idea),
but it wouldn't help if it were fixed in percent or ems.

The big advantage of tables (as I've said a few times) is that the
rendering device will adjust the column size based on the contents,
available space, etc.

It may be a disadvantage in many cases. A table content (in rows and
cells) or table rows will not line-wrap nor shrink-wrap in normal flow.
Instead, its horizontal width will grow and expand until all the content
is rendered in rows. That is not the case with block-level elements. So
large tables, even moderately large table will create horizontal
scrollbar in the browser window viewport since the document box will be
enlarged beyond the window viewport. HTML 4.01 spec spotted this and
rightly mentioned:
"Tables should not be used purely as a means to layout document content
(...) tables may force users to scroll horizontally to view a table
designed on a system with a larger display."
http://www.w3.org/TR/html401/struct/tables.html#h-11.1

This leads to another logical/forced and bad consequence (which has been
reported in many articles on tables used for layouts) for using table
for layout: the web author often needs to create a distinct print
version of that page in order to neutralize this horizontal effect.
Therefore duplicating efforts, energy.

On small screen devices (SSR) (media mobile), table would be most
annoying, inaccessible.

That way the table looks OK at different resolutions, client window sizes, different contents, etc. I am still
looking for a way to see if CSS can do this.

Thanks anyway.

You're looking for something which is less and less usable and
accessible, IMO. Block-level boxes do not stretch, expand due to their
intrinsic content.

If the 2 examples I gave you are not good enough, then I suspect your
own initial example was not a realistic one.

Gérard
--
remove blah to email me

[Alan Silver]

<snip>

The big advantage of tables (as I've said a few times) is that the
rendering device will adjust the column size based on the contents,
available space, etc.
It may be a disadvantage in many cases. A table content (in rows and
cells) or table rows will not line-wrap nor shrink-wrap in normal flow.
Instead, its horizontal width will grow and expand until all the
content is rendered in rows. That is not the case with block-level
elements. So large tables, even moderately large table will create
horizontal scrollbar in the browser window viewport since the document
box will be enlarged beyond the window viewport.

Not sure what you mean by this. I've never seen a horizontal scrollbar,
except when reducing my browser width down to a level where this would
happen with any kind of layout. Are you talking about using tables for
general layout? I'm not and never have been.

Please explain.
HTML 4.01 spec spotted this and rightly mentioned:
"Tables should not be used purely as a means to layout document content
(...) tables may force users to scroll horizontally to view a table
designed on a system with a larger display."
http://www.w3.org/TR/html401/struct/tables.html#h-11.1
Again, I'm not advocating using tables for layout, I never was. This
whole discussion was about using them for forms. This point is not
relevant to the subject.
This leads to another logical/forced and bad consequence (which has
been reported in many articles on tables used for layouts) for using
table for layout: the web author often needs to create a distinct print
version of that page in order to neutralize this horizontal effect.
Therefore duplicating efforts, energy.
Sure, that's one of the many disadvantages of using tables for layout.
But again, I'm not talking about that here, I'm talking about using
tables for forms. In such a case, you would want the table layout as it
is, and so wouldn't need to produce a separate print version.
On small screen devices (SSR) (media mobile), table would be most
annoying, inaccessible.
Ditto previous comment
That way the table looks OK at different

resolutions, client window sizes, different contents, etc. I am still
looking for a way to see if CSS can do this.
Thanks anyway.
You're looking for something which is less and less usable and
accessible, IMO. Block-level boxes do not stretch, expand due to their
intrinsic content.

Why is that less usable? That's a distinct advantage when showing a
form. The table version adapts to make best use of the space, the block
version doesn't.

Remember, I'm *not* talking about using tables for general layout.
If the 2 examples I gave you are not good enough, then I suspect your
own initial example was not a realistic one.

On the contrary, it was very realistic. I would say that just about ever
web site I have ever designed has required at least one form. So far I
have always laid them out with tables. I haven't yet found a decent CSS
alternative.

Thanks for the reply, but please keep closely concentrated on the
specific topic of discussion. I am *only* interested in discussing using
tables for forms. I have no argument over the issue of using them for
general layout.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Stuart Scharf]

Alan Silver wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout, but I would like some clarification as to exactly what
constitutes tabular data.

For example, if I have a form, in which the user is required to fill in
various bits of information, then laying out with a table makes it easy.
A basic example...

http://www.kidsinaction.org.uk/TableForm.html

[Please note that this is a very basic quick example knocked up for the
purpose of illustration. In a real example, more effort should be made
to ensure it is accessible, by using label tags, axis and pivot
attributes, etc. This was all omitted for brevity and clarity]

The main advantage of this (ab)use of tables is that the cells
automatically line up both horizontally and vertically.

Can this be done in CSS? I know I could treat each row individually, and
use a div, but then how would I get the second column (with the entry
boxes in) to line up? Using a table allows the browser (or whatever
rendering device is being used) to decide how much space to give each
row and column to allow the contents to fit. All the entry boxes line up
vertically in the table.

More to the point, is this actually an abuse of tables? I read a thread
here a while back in which someone suggested that this was reasonable.
It was suggested that this was a form of tabular data. No-one argued
with that, and it seemed a fair suggestion.

Any comments? This is a genuine question, not an intention to troll or
start an argument. I'm really not sure if this is an abuse of tables and
would like to hear the experts' opinion. If it is an abuse, is there a
sensible and simple CSS alternative? TIA

I think we have to wait until CSS 3.0 is implemented:

http://www.w3.org/TR/2005/WD-css3-layout-20051215/

CSS3 Advanced Layout Module
W3C Working Draft 15 December 2005

[Stan McCann]

Alan Silver <al*********@nospam.thanx.invalid> wrote in
news:Qo**************@nospamthankyou.spam:

"FORM(s) and Function"

Try increasing the font size of your browser and look again at
that form. The captions become bigger than the fixed space
allocated to them, and the second "column" entry goes down a line,
destroying the neat arrangement that a table would give.
The widths were specified in px units rather than ems.

Yup, but it suffers from similar problems if you change the units to
ems. The problem is that CSS doesn't seem capable of setting a
container's width based on the contents. That's one of the main
powers of tables.

Try setting the font size with % and then the container size using ems.
This is usually the most workable sizing method. I often find font
size and container both set with % also works well.

Well, in this case I'm not so sure. It seems to me that they do have
the edge here. Sure you can get away with CSS-based layouts in this
case, but that presents as many problems as it solves.

There's no doubt that tables do provide a certain advantage in working
with widths. Personally, I'd like to see CSS modify the behavior of
width: auto to become the content width. With the current behavior, it
seems kind of pointless to ever set width: auto since that is the
elements intrinsic width.

As for using tables for forms; I agree with those here that say forms
are tabular data. I use tables often with forms as forms often require
a rows and columns behavior which just happens to be a table.

As for nested tables, they are usually a mess to deal with but I have
used nested tables to separate values within a cell. Take this clip of
code for example from an old form on a website I manage:

<tr><td>Account type:</td>
<td><input type="radio" name="status" value="Faculty">Faculty<br>
<input type="radio" name="status" value="Staff">Staff<br>
<input type="radio" name="status" value="Student" checked>
Student</td></tr>

might be better written as:

<tr><td>Account type:</td>
<td>
<table>
<tr><td>Faculty</td><td>Staff</td><td>Student</td></tr>
<tr>
<td><input type="radio" name="status" value="Faculty"></td>
<td><input type="radio" name="status" value="Staff"></td>
<td><input type="radio" name="status" value="Student"
checked></td></tr>

--
Stan McCann, "Uncle Pirate" http://stanmccann.us/
Webmaster, NMSU at Alamogordo http://alamo.nmsu.edu/
Now blocking Google Grouper posts and replies.
http://blinkynet.net/comp/uip5.html

[Stan Brown]

Mon, 6 Feb 2006 19:50:29 +0000 from Alan Silver <alan-
si****@nospam.thanx.invalid>:

<snip>

The big advantage of tables (as I've said a few times) is that the
rendering device will adjust the column size based on the contents,
available space, etc.

Alan,

Your newsreader seems to be omitting attributions when you post a
follow-up containing quotes. Please adjust its settings.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[kchayka]

Stan McCann wrote:

Try setting the font size with % and then the container size using ems.
This is usually the most workable sizing method. I often find font
size and container both set with % also works well.

Both methods have merits, but which to use depends on if you are more
interested in the containers adjusting with text size, or with window size.

I tend to use largish text and smallish windows. Widths set in ems,
especially for sidebar columns, can easily take up a disproportionate
amount of screen real estate. :(

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Alan Silver]

In article <53**************@llslave.llan.ll.mit.edu>, Stuart Scharf
<no****@ll.mit.edu> writes

I think we have to wait until CSS 3.0 is implemented:

And then we'll have to wait until the web world has updated its browsing
software to the point where we can rely on it being supported. I might
be retired by then!!

Thanks for the reply

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

In article <MP************************@news.individual.net> , Stan Brown
<th************@fastmail.fm> writes

Your newsreader seems to be omitting attributions when you post a
follow-up containing quotes. Please adjust its settings.

Sorry pardon, will do.

Was that better?

--
Alan Silver
(anything added below this line is nothing to do with me)

[Stan Brown]

Mon, 6 Feb 2006 23:13:46 +0000 from Alan Silver <alan-
si****@nospam.thanx.invalid>:

In article <MP************************@news.individual.net> , Stan Brown
<th************@fastmail.fm> writes [snip]
Was that better?

Very much so -- thanks!

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Mason C]

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout,

This long thread simply must have this comment.

CSS is a lousy way to lay out a web page.

I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

I use it frequently. Very few web pages are laid
out by CSS. Even the "great" ones use tables.

When I see something misplaced on the page I know
immediately it's one of the rare CSS layouts.

Give it up. Your life will be much simpler and your
work more successful if you use tables to lay out
your pages.

Mason C bye-bye

obligatory reference: http://masonc.home.netcom.com

[Spartanicus]

Mason C <ma*****@earthlink.net> wrote:

CSS is a lousy way to lay out a web page.
No, currently it requires greater skills from the developer because the
easy way isn't supported by IE.
I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

I use it frequently. Very few web pages are laid
out by CSS. Even the "great" ones use tables.
That's an indication that many web developers do not have sufficient
skills, this shouldn't come as a surprise for anyone who has looked at
the quality of the code on the world wild web.
When I see something misplaced on the page I know
immediately it's one of the rare CSS layouts.
Another indicator for a poorly skilled developer.
Give it up. Your life will be much simpler and your
work more successful if you use tables to lay out
your pages.

Sounds like you are one of those poorly skilled.

--
Spartanicus

[Alan Silver]

In article <k5********************************@4ax.com>, Mason C
<ma*****@earthlink.net> writes

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout,
This long thread simply must have this comment.

Must? I think some may disagree in a CSS newsgroup.
CSS is a lousy way to lay out a web page.
No, CSS is lousy if done badly, but then so are tables.

Plus, this thread was *never* about laying out web pages with CSS. It
was about forms, and the question of the status of forms as tabular
data.
I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.
Plug-ins for Firefox can do the same, so can the Microsoft developer
toolbar for IE.
I use it frequently. Very few web pages are laid
out by CSS.
Proving what? We know CSS is much harder to use, but the benefits are
enormous. Sure tables are easy, but easy does not always mean better.
Even the "great" ones use tables.
Define "great". Many of the "great" sites on the web have invalid HTML.
Are you going to say that valid HTML is a bad way to lay out a web page?

As an example, someone posted here that Yahoo's front page recently
contained over 100 tables, mostly nested. Are you seriously going to
tell me that's a "great" way to design a page? If so, then I suspect you
are in the wrong newsgroup!!
When I see something misplaced on the page I know
immediately it's one of the rare CSS layouts.
You are pointing the blame in the wrong direction. Sure CSS is harder to
use, but if done properly, has many huge advantages. Why pick up on bad
design and blame CSS?
Give it up. Your life will be much simpler and your
work more successful if you use tables to lay out
your pages.

Depends on your aim in life I suppose. If you are producing a personal
site to show your family how the pet dog looks after his haircut, then I
guess good style and structure aren't so important. If you are a
professional, producing sites for the web at large (which is far larger
than just web browsers by the way), then you gain a huge advantage by
using a proper structure to your HTML, and keeping all presentational
content separate.

Sure it's harder, but that's why we get paid for it!! I try to give my
clients quality sites. They don't know the difference between good
structure and bad, valid HTML and invalid, clear separation of content
and presentation from a mixture and so on. However, the long-term
results reflect the difference. Properly designed sites work in far more
browsing devices, display sensibly in a far greater variety of
environments and allow all types of users, irrespective of their
physical abilities to access the site. All those minorities add up to
quite a lot of visitors.

Anyway, I've said more than enough. I'm sure others will comment on
this, but I'm going back to the matter at hand. Thanks for the reply,
but I won't be taking your advice.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Barbara de Zoete]

On Tue, 07 Feb 2006 11:20:08 +0100, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

In article <k5********************************@4ax.com>, Mason C
<ma*****@earthlink.net> writes

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

I understand the issue that tables should be used for tabular data and
not for layout,

[ ... ]
I use it frequently. Very few web pages are laid
out by CSS.
Proving what? We know CSS is much harder to use, but the benefits are
enormous. Sure tables are easy, but easy does not always mean better.

[ ... ]

Give it up. Your life will be much simpler and your
work more successful if you use tables to lay out
your pages.

Depends on your aim in life I suppose. If you are producing a personal
site to show your family how the pet dog looks after his haircut, then I
guess good style and structure aren't so important.

Hey, hey, careful now ... ;-)
If you are a professional, producing sites for the web at large (which
is far larger than just web browsers by the way), then you gain a huge
advantage by using a proper structure to your HTML, and keeping all
presentational content separate.

Sure it's harder, but that's why we get paid for it!!

It is not.

I keep reading about how 'easy' table layout is. I think it is a horror.
It is perhaps easy for those who use a WYSINWYG-editor, but it isn't for
those who don't. I had a dislike from table-based layout from day 1 I
wanted to publish something on the net.

The difference in using table-based layout or using proper markup and
style the pages with css, is that with the latter you need some brain and
some creativity. There is no 'push this big and obvious button right here
to create a two column layout for all your neet pages' thingy with css.
You really have to live the concept of creating well structured pages with
markup that is meaningful on the one hand, and enjoying all the fun of
having a huge white wall in front of you that is all yours to
draw/paint/what ever on. Say a 2.7 meters high and 8 meters wide piece of
nothing to start with. All yours. Usually that scares the shit out of a
lot of people. I on the other hand love it (as do many who frequent this
particular group).
--
______PretLetters:
| weblog | http://www.pretletters.net/weblog/weblog.html |
| webontwerp | http://www.pretletters.net/html/webontwerp.html |
|zweefvliegen | http://www.pretletters.net/html/vliegen.html |

[Alan Silver]

In article <op.s4lmvmvil8uz2z@zoete_b>, Barbara de Zoete
<tr******@pretletters.net> writes

Sure it's harder, but that's why we get paid for it!!
It is not.

OK, personal opinion ;-)
I keep reading about how 'easy' table layout is. I think it is a
horror. It is perhaps easy for those who use a WYSINWYG-editor, but it
isn't for those who don't. I had a dislike from table-based layout from
day 1 I wanted to publish something on the net.
I have never used WYSIWYG HTML editors as I never found one that
produced anything like decent HTML. I have always (last ten years) coded
completely by hand, and I still find tables easier.

Why? Simply because they are easier to understand. They are predictable.
You know that the cells in one row will be lined up horizontally, cells
in a column will be lined up vertically. With a CSS approach, you don't
have any of that. You have a bunch of divs, and you have to start trying
to shoft them around, always facing the problem that moving one may
affect the ones you already had in place.

Obviously this is all personal, but I find CSS layout much harder, and
can understand why people want to stick with tables. YMMV ;-)
The difference in using table-based layout or using proper markup and
style the pages with css, is that with the latter you need some brain
and some creativity.

Ah, there's the rub. You need to *learn*, you need discipline. Many
people can't be bothered. Using tables lets you ignore a lot of these
problems, so it takes less brain power.

Anyway, I guess we agree in principle ;-) Interesting to hear your views
though. I've never actually heard of anyone who thought tables were
harder before.

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

[niels.froehling]

>> The widths were specified in px units rather than ems.

Yup, but it suffers from similar problems if you change the units to
ems. The problem is that CSS doesn't seem capable of setting a
container's width based on the contents. That's one of the main powers
of tables.

You can indeed hack it:

<div style="white-space: nowrap; width: 1px;">my unknown content</div>

Better (for your design) is:

<div style="white-space: nowrap; min-width: 100px;">my unknown
content</div>

But there only exists a consistent definition of "content-size" if
it's
a block, and not floating text, in this case you convert the
(multiline)
text into a single-line block.
Any other "automatic content-adjustment" depends on something else,
for example firefox pseudo-weighing that measures the amount of text in

a cell and sets percentages after that.

Ciao
Niels

[kchayka]

Mason C wrote:

Very few web pages are laid
out by CSS. Even the "great" ones use tables.

"great" is highly subjective, you know. To me, the great ones are those
which adapt well to my not-exactly-average browsing environment. Most
table layouts don't.

That's not to say that all CSS layouts do, since it can be even easier
to make a crappy design with CSS than it is with table layouts,
especially in the hands of the unskilled, or those attempting a
pixel-perfect design.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Stan Brown]

Tue, 07 Feb 2006 11:46:24 +0100 from Barbara de Zoete
<tr******@pretletters.net>:

On Tue, 07 Feb 2006 11:20:08 +0100, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

If you are a professional, producing sites for the web at large (which
is far larger than just web browsers by the way), then you gain a huge
advantage by using a proper structure to your HTML, and keeping all
presentational content separate.

Sure it's harder, but that's why we get paid for it!!

It is not.

I keep reading about how 'easy' table layout is. I think it is a horror.
It is perhaps easy for those who use a WYSINWYG-editor, but it isn't for
those who don't. I had a dislike from table-based layout from day 1 I
wanted to publish something on the net.

Don't feel compelled to answer, but do you prefer to do word
processing with TeX or something else that is not WYSIWYG?(*) I grew
up before word processing was WYSIWYG, so I feel comfortable with
"programming" HTML and CSS. I rather suspect it's most of today's
generation that has never known anything but WYSIWYG that finds
table-based layout easier, not on its own but because of their
WYSIWYG "helper" programs.

Just speculation really...

(*) I would, but I confess that I use Word just because it's already
on my computer and installed. But I do prefer non-WYSIWYG word
processing in principle; it's one reason I tend to write new
documents in HTML. In my programming days, I actually wrote a couple
of word processing programs that used commands and special codes.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Stan Brown]

Tue, 7 Feb 2006 14:09:44 +0000 from Alan Silver <alan-
si****@nospam.thanx.invalid>:

Why? Simply because they are easier to understand. They are predictable.
You know that the cells in one row will be lined up horizontally, cells
in a column will be lined up vertically. With a CSS approach, you don't
have any of that. You have a bunch of divs, and you have to start trying
to shoft them around, always facing the problem that moving one may
affect the ones you already had in place.

I don't think either of those statements is wholly true.

With a table, you don't really know what will happen in a narrow
window or with a large font, for instance. Sure, the cells in a row
will be horizontal, but the table may extend far beyond the view port
or each cell may be many lines at one word per line, or both.

On the other hand, with CSS, you don't necessarily have "a bunch of
DIVs", though I agree that's a common approach. But the whole point
with CSS is that you _don't_ "start shifting them around" -- you
embrace the fact that the design is fluid and will flow based on the
visitor's selected font and view port. I truly see this as a
liberating thing.

This is not to say that tables qua tables are bad -- just that tables
shouldn't be used when the data aren't really tabular. I do still
have one or two tables used for layout on my Web site, but as I find
time I've been removing them. And when I do I find that the resulting
markup is simpler, not more complex.

Consider for instance my GREP registration page,
<http://oakroadsystems.com/sharware/grepbuy.htm> (last section).
Formerly that was done with tables,
<http://web.archive.org/web/200502080...adsystems.com/
sharware/grepbuy.htm>. It took up more space and more coding(*) to
present _less_ information (and fewer options) to the user. Granted
it's not a strict comparison, because I did change the information at
the same time I CSS-ized the page.

(*) I have a macro to generate the hidden name-value pairs, so that's
a wash.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[Alan Silver]

In article <MP************************@news.individual.net> , Stan Brown
<th************@fastmail.fm> writes

Tue, 7 Feb 2006 14:09:44 +0000 from Alan Silver <alan-
si****@nospam.thanx.invalid>:

Why? Simply because they are easier to understand. They are predictable.
You know that the cells in one row will be lined up horizontally, cells
in a column will be lined up vertically. With a CSS approach, you don't
have any of that. You have a bunch of divs, and you have to start trying
to shoft them around, always facing the problem that moving one may
affect the ones you already had in place.
I don't think either of those statements is wholly true.

That's fine, I'm interested to hear other approaches.
With a table, you don't really know what will happen in a narrow
window or with a large font, for instance. Sure, the cells in a row
will be horizontal, but the table may extend far beyond the view port
or each cell may be many lines at one word per line, or both.
True, but it's very easy to check. Also, the behaviour is pretty
predictable.

What I meant by this comment was that with a table, the rows and columns
always end up in the same relationship with each other. With CSS (at
least in my limited experience so far), you can have two blocks that are
side by side at one browser width, and one above the other in a
different browser width. That just doesn't happen with tables.
On the other hand, with CSS, you don't necessarily have "a bunch of
DIVs", though I agree that's a common approach.
OK, that's just my limited experience showing. All of the example I have
seen so far wrap sections of content into divs and use CSS to position
them.
But the whole point
with CSS is that you _don't_ "start shifting them around" -- you
embrace the fact that the design is fluid and will flow based on the
visitor's selected font and view port.
I suspect that very few designers, even those who stick religiously to
CSS for layout view this quite as liberally as you do. I agree that the
design should be fluid, but people (almost) always try to achieve a
certain amount of rigidity. Maybe that's wrong, but I think it's fairly
true.
I truly see this as a
liberating thing.

It's a completely new way of thinking for most people. It's a much
harder way to think if you're used to the idea of putting things where
you want them. Given that large numbers of web designers come from print
design, they are going to have a huge problem with this. Even those who
aren't print designers, but have used a word processor will be used to
the idea that things tend to stay roughly where you put them. Changing
your mind set to work with such a fluidity is more than a lot of people
can bother with. That's not to say it's wrong, it's just a big jump, and
one which many people are happy to ignore.

<snip>

Thanks for the reply. I think we've pretty much done this subject to
death now!! Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

[Barbara de Zoete]

On Tue, 07 Feb 2006 17:56:42 +0100, Stan Brown
<th************@fastmail.fm> wrote:

Tue, 07 Feb 2006 11:46:24 +0100 from Barbara de Zoete
<tr******@pretletters.net>:

I keep reading about how 'easy' table layout is. I think it is a horror.
It is perhaps easy for those who use a WYSINWYG-editor, but it isn't for
those who don't. I had a dislike from table-based layout from day 1 I
wanted to publish something on the net.
Don't feel compelled to answer, but do you prefer to do word
processing with TeX or something else that is not WYSIWYG?(*)

I don't know TeX, but I don't like Word one bit. I loved the control that
WordPerfect5.1 gave me. I mainly worked from the bottom screen, where all
the codes were.
I do remember some old machine of which I don't remember what it was, must
have been 1984'ish. One sat inside the computer, so to speek. The screen
(monochrome green) and keyboard were in a fixed position in the
desk/computer. You had to type pretty long codes to influence the looks of
text (like <18.200.25> for 18pt text on 2.5 line height with 200
color/shade, but much longer than that). But the codes made little sense
(less than what I just now came up with now).
I was still in school back then but had a job on the side, typing long
texts for books and such in that machine. At the end of the day you could
save your work (now, those things were flops!), I would then dial the
printer shop, put the phone (hoorn?) on some sort of modem and waited. Tee
time. Next day, before going to the office, I could pick up the prints
from the print shop that was some ten kilometers from the office. I
remember a big shock once: all text printed with a larger than large font
(larger than 72pt) on one continuous piece of paper, like a mile long (not
really that long of course). Forgot to close a header somewhere :-)
I grew
up before word processing was WYSIWYG, so I feel comfortable with
"programming" HTML and CSS. I rather suspect it's most of today's
generation that has never known anything but WYSIWYG that finds
table-based layout easier, not on its own but because of their
WYSIWYG "helper" programs.

Just speculation really...

Never thought of it that way, but you could be right.

--
______PretLetters:
| weblog | http://www.pretletters.net/weblog/weblog.html |
| webontwerp | http://www.pretletters.net/html/webontwerp.html |
|zweefvliegen | http://www.pretletters.net/html/vliegen.html |

[Mason C]

On Tue, 07 Feb 2006 09:27:43 -0600, kchayka <us****@c-net.us> wrote:

Mason C wrote:

Very few web pages are laid
out by CSS. Even the "great" ones use tables.
"great" is highly subjective, you know. To me, the great ones are those
which adapt well to my not-exactly-average browsing environment. Most
table layouts don't

I would very much appreciate learning why table layouts don't adapt to
your browsing environment.

Mason C
That's not to say that all CSS layouts do, since it can be even easier
to make a crappy design with CSS than it is with table layouts,
especially in the hands of the unskilled, or those attempting a
pixel-perfect design.

[kchayka]

Mason C wrote:

On Tue, 07 Feb 2006 09:27:43 -0600, kchayka <us****@c-net.us> wrote:

"great" is highly subjective, you know. To me, the great ones are those
which adapt well to my not-exactly-average browsing environment. Most
table layouts don't

I would very much appreciate learning why table layouts don't adapt to
your browsing environment.

For one thing, consider that the huge majority of table layouts are also
fixed-width. I'll let you figure out what the implications are.

It is easy to remedy suboptimal designs when they are made with CSS;
stylesheets can be disabled with a couple keystrokes. Not so easy to
remedy these built with tables, especially nested tables, more
especially when they don't linearize well.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Daniel Déchelotte]

Alan Silver a écrit :

[tables used for layout]
True, but it's very easy to check. Also, the behaviour is pretty
predictable.

What I meant by this comment was that with a table, the rows and
columns always end up in the same relationship with each other. With
CSS (at least in my limited experience so far), you can have two
blocks that are side by side at one browser width, and one above the
other in a different browser width. That just doesn't happen with
tables.

Correct. Some use that argument to make a case for CSS layout (graceful
degradation in "extreme" browsing situations), others to make a case
against it (unpredictable behaviour in "atypical" browsing situations,
including with obsolete browsers). Every one chooses either side, both
of which are valid (with one side more valid than the other ;-).
Troll killed?

--
Daniel Déchelotte
http://yo.dan.free.fr/

[Alan Silver]

In article <44************@individual.net>, kchayka <us****@c-net.us>
writes

I would very much appreciate learning why table layouts don't adapt to
your browsing environment.

For one thing, consider that the huge majority of table layouts are
also fixed-width. I'll let you figure out what the implications are.

Well, given that fixed-width layouts are a bad idea however you do them,
this isn't an argument against tables ;-)

--
Alan Silver
(anything added below this line is nothing to do with me)

[kchayka]

Alan Silver wrote:

In article <44************@individual.net>, kchayka <us****@c-net.us>
writes

For one thing, consider that the huge majority of table layouts are
also fixed-width. I'll let you figure out what the implications are.

Well, given that fixed-width layouts are a bad idea however you do them,
this isn't an argument against tables ;-)

I guess you didn't read the part about the user overcoming problems
caused by such a layout mechanism. :-\

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Alan Silver]

In article <44************@individual.net>, kchayka <us****@c-net.us>
writes

Alan Silver wrote:

In article <44************@individual.net>, kchayka <us****@c-net.us>
writes

For one thing, consider that the huge majority of table layouts are
also fixed-width. I'll let you figure out what the implications are.

Well, given that fixed-width layouts are a bad idea however you do them,
this isn't an argument against tables ;-)

I guess you didn't read the part about the user overcoming problems
caused by such a layout mechanism. :-\

You lost me here, what was I supposed to have read? I'm quite prepared
to believe I missed it, but what was it?

;-)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Matt Silberstein]

On Tue, 07 Feb 2006 07:38:17 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k5********************************@4ax.com> wrote:

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout,

This long thread simply must have this comment.

CSS is a lousy way to lay out a web page.

I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

Why do you want to reveal table borders?

[snip]

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

[Mason C]

On Wed, 08 Feb 2006 07:25:57 -0600, kchayka <us****@c-net.us> wrote:

Mason C wrote:

On Tue, 07 Feb 2006 09:27:43 -0600, kchayka <us****@c-net.us> wrote:

"great" is highly subjective, you know. To me, the great ones are those
which adapt well to my not-exactly-average browsing environment. Most
table layouts don't
I would very much appreciate learning why table layouts don't adapt to
your browsing environment.

For one thing, consider that the huge majority of table layouts are also
fixed-width. I'll let you figure out what the implications are.

Good point.

However, by switching to your own simple css you can side-step
a failed css. Is that an argument for using css layout? Ummm....

Mason C
It is easy to remedy suboptimal designs when they are made with CSS;
stylesheets can be disabled with a couple keystrokes. Not so easy to
remedy these built with tables, especially nested tables, more
especially when they don't linearize well.

[Mason C]

On Wed, 08 Feb 2006 21:05:27 GMT, Matt Silberstein
<Re**************************@ix.netcom.com> wrote:

On Tue, 07 Feb 2006 07:38:17 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k5********************************@4ax.com> wrote:

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout,
This long thread simply must have this comment.

CSS is a lousy way to lay out a web page.

I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

Why do you want to reveal table borders?

1 To quickly determine if TABLE or CSS.
2 For understanding the table tricks, e.g. overlapping
graphics.
3 Side-step CSS errors and see hidden links.
4 For fun.
Mason C
[snip]

[Paxton]

Alan Silver wrote:

In article <k5********************************@4ax.com>, Mason C
<ma*****@earthlink.net> writes

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout,

This long thread simply must have this comment.

Must? I think some may disagree in a CSS newsgroup.

CSS is a lousy way to lay out a web page.

No, CSS is lousy if done badly, but then so are tables.

Plus, this thread was *never* about laying out web pages with CSS. It
was about forms, and the question of the status of forms as tabular
data.

I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

Plug-ins for Firefox can do the same, so can the Microsoft developer
toolbar for IE.

I use it frequently. Very few web pages are laid
out by CSS.

Proving what? We know CSS is much harder to use, but the benefits are
enormous. Sure tables are easy, but easy does not always mean better.

I've just embarked on trying to layout pages using CSS instead of
tables, and spent a day and a half on a three col layout - left and
right col fixed width, centre fluid, with the left col height
increasing with the depth of the centre col content (so that the
background color would continue past the end of the left col content).

I found samples with the help of google and eventually got one of them
working in Firefox. It looked fine in IE6 too, until someone hovered
on a link in the center col, when the left hand col shot across the
screen.

Back to the drawing board for the 9th (or 10th?) time, and I knocked up
a 3 col table (left 120px, center 100%, right 130px), popped all my
divs in the correct cols, added some classes to the css, and got what I
wanted. It added a few bytes to the overall file size, but got rid of
loads of code in the css to cater for all the arse browser hacks.

CSS versus tables.... hmmm.

I agree that nested tables with loads of spacer.gifs is naff, but a
table to act as a frame for my cols MUST be better than wasting a day
and a half of project time trying to accommodate rediculous browser
implementations of CSS.

When the majority of my users are using CSS3 compliant browsers, then I
will convert fully.

P/.

[Matt Silberstein]

On Thu, 09 Feb 2006 21:48:14 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k4********************************@4ax.com> wrote:

On Wed, 08 Feb 2006 21:05:27 GMT, Matt Silberstein
<Re**************************@ix.netcom.com> wrote:

On Tue, 07 Feb 2006 07:38:17 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k5********************************@4ax.com> wrote:

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

Hello,

I understand the issue that tables should be used for tabular data and
not for layout,

This long thread simply must have this comment.

CSS is a lousy way to lay out a web page.

I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

Why do you want to reveal table borders?

1 To quickly determine if TABLE or CSS.
2 For understanding the table tricks, e.g. overlapping
graphics.
3 Side-step CSS errors and see hidden links.
4 For fun.

All of which are things only a developer would do. Developers
represent a tiny portion of most audiences. As such this is not
evidence CSS is a lousy way to lay out pages.

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

[Mason C]

On Fri, 10 Feb 2006 01:29:26 GMT, Matt Silberstein
<Re**************************@ix.netcom.com> wrote:

On Thu, 09 Feb 2006 21:48:14 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k4********************************@4ax.com> wrote:

On Wed, 08 Feb 2006 21:05:27 GMT, Matt Silberstein
<Re**************************@ix.netcom.com> wrote:

On Tue, 07 Feb 2006 07:38:17 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k5********************************@4ax.com> wrote:

On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
<al*********@nospam.thanx.invalid> wrote:

>Hello,
>
>I understand the issue that tables should be used for tabular data and
>not for layout,

This long thread simply must have this comment.

CSS is a lousy way to lay out a web page.

I use Opera and with a click can add my own CSS to
any page. It does two things: adds borders to
tables to reveal them and sets the link colors so the
links can be seen.

Why do you want to reveal table borders?

1 To quickly determine if TABLE or CSS.
2 For understanding the table tricks, e.g. overlapping
graphics.
3 Side-step CSS errors and see hidden links.
4 For fun.

All of which are things only a developer would do. Developers
represent a tiny portion of most audiences. As such this is not
evidence CSS is a lousy way to lay out pages.

Since when is a microscope "evidence"? The evidence is
in what you see, not in the tool used.

I see:
(1) most pages, including "important " ones, use tables, some
with complex layouts.
(2) many CSS pages have layout flaws.
( 3 - and incidentally, my added CSS makes the links visible.)

[Matt Silberstein]

On Fri, 10 Feb 2006 05:45:56 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<ot********************************@4ax.com> wrote:

On Fri, 10 Feb 2006 01:29:26 GMT, Matt Silberstein
<Re**************************@ix.netcom.com> wrote:

On Thu, 09 Feb 2006 21:48:14 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k4********************************@4ax.com> wrote:

On Wed, 08 Feb 2006 21:05:27 GMT, Matt Silberstein
<Re**************************@ix.netcom.com> wrote:

On Tue, 07 Feb 2006 07:38:17 GMT, in
comp.infosystems.www.authoring.stylesheets , Mason C
<ma*****@earthlink.net> in
<k5********************************@4ax.com> wrote:

>On Sun, 5 Feb 2006 14:40:46 +0000, Alan Silver
><al*********@nospam.thanx.invalid> wrote:
>
>>Hello,
>>
>>I understand the issue that tables should be used for tabular data and
>>not for layout,
>
>This long thread simply must have this comment.
>
>CSS is a lousy way to lay out a web page.
>
>I use Opera and with a click can add my own CSS to
>any page. It does two things: adds borders to
>tables to reveal them and sets the link colors so the
>links can be seen.

Why do you want to reveal table borders?

1 To quickly determine if TABLE or CSS.
2 For understanding the table tricks, e.g. overlapping
graphics.
3 Side-step CSS errors and see hidden links.
4 For fun.

All of which are things only a developer would do. Developers
represent a tiny portion of most audiences. As such this is not
evidence CSS is a lousy way to lay out pages.

Since when is a microscope "evidence"? The evidence is
in what you see, not in the tool used.

I see:
(1) most pages, including "important " ones, use tables, some
with complex layouts.
(2) many CSS pages have layout flaws.
( 3 - and incidentally, my added CSS makes the links visible.)

You know, I think I misunderstood your original post. Sorry.
--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

[kchayka]

Paxton wrote:

I agree that nested tables with loads of spacer.gifs is naff, but a
table to act as a frame for my cols MUST be better than wasting a day
and a half of project time trying to accommodate rediculous browser
implementations of CSS.
You spent a whole day and a half on a CSS layout? Wow, you must be a
real CSS expert now.

Sounds like you are in the camp that expects to instantaneously learn
CSS, like there is nothing to understanding the box model, how
positioning really works, browser peculiarities... :-\
When the majority of my users are using CSS3 compliant browsers, then I
will convert fully.

Uh, OK. I don't supposed you are going to take the time in between to
hone your CSS skills and really learn how to use it, eh? Or when that
CSS3 time comes, are you going to say the same thing and just cite CSS4
instead?

Learning takes time, and practice makes perfect. CSS is not exempt from
this. To just keep hacking away until something "works" will only lead
to frustration and failure.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.