Article putting forward a case for table layout

H

Harlan Messinger

patrick said:
Hi

I'm wondering if this article has been discussed here. I don't have any
opinions on it as such but I think it is interesting reading.

<http://olav.dk/articles/tables.html>
There isn't anything improper about using tables to lay out controls
with their labels. They are logically a two-column table where each row
is a data item, with the label in one column and the data value, or a
place to enter it, in the other column. There's no need to demonstrate
that the CSS version isn't as nice.

The remainder of the page relies on the argument that ease determines
appropriateness. It's a factor, but not the only one, and the others
should be accorded their due weight.
 
B

Ben C

Hi

I'm wondering if this article has been discussed here. I don't have any
opinions on it as such but I think it is interesting reading.

<http://olav.dk/articles/tables.html>

I can't see what's wrong with using display: table and display:
table-cell if you need them. That way you can avoid presentational
markup.

So you use <td> etc. for tabular data, and display: table for grid
layouts.

Maybe that's what he's referring to when he says, "To be fair, the CSS
2.1 spec does support grid-based layout using pure CSS. Unfortunately
Internet Explorer does not support this, hence it's not really relevant
for real-world web design, even though it is supported in other
browsers".

So maybe it doesn't work in IE.

A separate question is how often do you actually need grid layouts-- a
lot of news sites for example have table-based grid layouts and are
annoying and hard to read.

Anyway, his examples can be done quite easily without tables and also
without tricks and hacks. But there are still some things you can only
do with tables.

For his form example, it's easy to get the automatic column widths by
using two floats with width: auto. In any case that pretty much is a
grid layout, as the other person said, so why not use display:
table-cell.

In the second example, you can easily use absolute positioning to put
the footer at the bottom and make the sidebar run all the way down to
footer. This seems less of a trick/hack in this case than using a table.

So when do you need tables apart from grids? Centering in either
dimension of shrink-to-fit boxes and more complex cases of dividing the
page into rows or columns whose dimensions you wish to specify in a
mixture of lengths and percentages are two examples that came up
recently.
 
M

Michael Fesser

..oO(Ben C)
I can't see what's wrong with using display: table and display:
table-cell if you need them. That way you can avoid presentational
markup.

Doesn't work in IE.
For his form example, it's easy to get the automatic column widths by
using two floats with width: auto.

One float for all the labels, the other for the controls? That's not
going to work.

Micha
 
B

Ben C

.oO(Ben C)


Doesn't work in IE.

I suspected that might be the reason.
One float for all the labels, the other for the controls?
Exactly.

That's not going to work.

Why not?

Obviously not all aspects of this method are the same as using tables,
but it works, and achieves the automatic column widths just as easily.

e.g.:

div
{
float: left;
background-color: gray;
line-height: 2em;
padding: 0.2em;
}

....

<div>
<label>Name:</label>
<br>
<label>Age:</label>
</div>
<div>
<input size="12">
<br>
<input size="8">
</div>
 
M

Michael Fesser

..oO(Ben C)

Have a look at it without CSS.

Additionally what happens if you want to use textareas or longer labels
that may break? There's no way to line them up properly with their
associated controls.

Micha
 
C

carolyn

patrick said:
Hi

I'm wondering if this article has been discussed here. I don't have any
opinions on it as such but I think it is interesting reading.

<http://olav.dk/articles/tables.html>

My thoughts and comments...

I will agree, there are some things that are easier to do with tables than
with css. Overall however I think CSS is much better for layout and
presentation - specifically when it comes to maintaining a site.

In the example of a form. I would use a table. Why? In the simplest form,
I have a column of field names and a column of user data. It is tabular
data, so I would use a table.

In the second example, if I wanted the look of two even length columns, I
could use tables - it is easier that way, but I would use columns. I
already have a template set up for that, so it is now trivial for myself.
google ruthsarian layouts if you want to find the base for my template.

Carolyn
 
B

Ben C

.oO(Ben C)


Have a look at it without CSS.

It looks just the same as if I use semantic markup and display:
table-cell and remove the CSS.

If things must layout correctly without CSS then we must use
presentational markup. I didn't think that was the point.
Additionally what happens if you want to use textareas or longer labels
that may break? There's no way to line them up properly with their
associated controls.

Agreed, that is the biggest problem with using floats in this example.
Basically you can control the columns of the simulated table quite
easily, but much less easily the rows. Each float is its own block level
box and minds its own business. Not like cells on a row in a table,
which have to agree on a common row height and in many cases a baseline.

You can't really get very far doing a grid with floats. But the orignal
article stated:

"A table is the right solution when we need one or more box to stretch
beyond the natural (content-determined) size, depending on the size of
sibling boxes."

I don't really agree with that.

But I do think table layout is the best thing for grids, and that that
form example is basically a grid.
 
S

Spartanicus

Ben C said:
It looks just the same as if I use semantic markup and display:
table-cell and remove the CSS.

The correct *semantic* markup for a form with associated text is an HTML
table, not a bunch of *non semantic* divs.
If things must layout correctly without CSS then we must use
presentational markup. I didn't think that was the point.

There is nothing presentational about the use of an HTML table in this
case, consider screen readers for example.
 
J

John Dunlop

Ben C:
It looks just the same as if I use semantic markup and display:
table-cell and remove the CSS.

Looks should have nothing to do with what markup some data is marked
up with. If the data is tabular in nature, mark it up as a table; if
the data is not tabular in nature, mark it up as something else. To
tell if data is tabular in nature, consider the relationship between
the would-be cells.

Tables in HTML were not designed for *laying out* data in a
presentational sense, but rather for *arranging* data in a structural
sense. For example, columns and rows needn't have any spatial
properties, since they can still have meaning for non-visual
user-agents.
But I do think table layout is the best thing for grids, and that that
form example is basically a grid.

If we assume 'grid' more so than 'table' implies spatial properties,
that is a presentational issue, best relegated to stylesheets.

A collection of form inputs and their labels is, structurally, a
table, no matter how you expect the form to be rendered.
 
B

Ben C

On 2006-11-01 said:
Looks should have nothing to do with what markup some data is marked
up with. If the data is tabular in nature, mark it up as a table; if
the data is not tabular in nature, mark it up as something else. To
tell if data is tabular in nature, consider the relationship between
the would-be cells.

Tables in HTML were not designed for *laying out* data in a
presentational sense, but rather for *arranging* data in a structural
sense. For example, columns and rows needn't have any spatial
properties, since they can still have meaning for non-visual
user-agents.


If we assume 'grid' more so than 'table' implies spatial properties,
that is a presentational issue, best relegated to stylesheets.

Exactly, which is what we wanted to do (in a world without IE etc.).
A collection of form inputs and their labels is, structurally, a
table, no matter how you expect the form to be rendered.

Well, I think I see your point, but I don't agree that form inputs and
their labels are structurally a table.
 
A

ato_zee

If we assume 'grid' more so than 'table' implies spatial properties,
that is a presentational issue, best relegated to stylesheets.

Fine, but for the fact that W3C validated code and CSS stylesheets
display differently in different browsers. Tables impose a grid
structure which responds more benignly to different browsers.
 
J

John Dunlop

(e-mail address removed):
Fine, but for the fact that W3C validated code and CSS stylesheets
display differently in different browsers.

...in the very nature of a Web that is World Wide, no?
Tables impose a grid structure which responds more benignly to different browsers.

What the blazes are you talking about, man?
 
T

Travis Newbury

John said:
...in the very nature of a Web that is World Wide, no?

Actually no, it happens to be that way only because the browsers can
not agree how to do things. If they all agreed, and rendered
everything the same way, then it would all look the same. So the "web"
is not the issue, the browsers are. YMMV

What the blazes are you talking about, man?

who the hell knows, I'm lost with that statement too...
 
A

ato_zee

Actually no, it happens to be that way only because the browsers can
not agree how to do things. If they all agreed, and rendered
everything the same way, then it would all look the same. So the "web"
is not the issue, the browsers are. YMMV

Maybe the browsers need validating as well. "If they all agreed, and rendered
everything the same way, then it would all look the same." would solve a lot
of browser problems.

With a table, cells remain in the same position relative to
each other, with division based tableless designs, comprising
a header, 3 column div (not a table in sight, only the
stylesheet), finally a footer, you get
different results, depending on the browser.
That leads into browser sensing and life gets very involved,
so you might begin to consider server side scripting, or going
back to tables.
 
B

Bergamot

Travis said:
it happens to be that way only because the browsers can
not agree how to do things.

Actually, they do for the most part. It's why there's a W3C in the first
place, eh? The issue isn't agreement so much as bugs, or non-support for
a particular feature, element or property.

Classic case is IE6 - buggy as heck, and doesn't support any of the CSS
that would make cool pages. IE7 has the worst bugs addressed, so things
will improve when it comes out, but it still has a long way to go to
catch up. IE6 will still be out there in large numbers for a long time,
anyway. Makes it hard for the web to move forward. :(
So the "web" is not the issue, the browsers are. YMMV

Yes, but not necessarily in the way you say.
 
D

dorayme

"Travis Newbury said:
Actually no, it happens to be that way only because the browsers can
not agree how to do things. If they all agreed, and rendered
everything the same way, then it would all look the same. So the "web"
is not the issue, the browsers are. YMMV



who the hell knows, I'm lost with that statement too...

It seemed perfectly clear to me. (Calm down Jock!) If you use a
table in many situations (for layout purposes, not because the
content is really tabular), you get more consistent results over
a wider range of browsers both old and new than with css layout.
On average, taking everyone who does both into account, both the
skilful, the novice, the output from the wyswygs, operated by
people both good and bad. Give me a grant and I will provide you
with clear and meaningful stats that give perfectly good sense to
the statement by sampling.

About browsers being all the same. That would be unfortunate at
this stage. It is an important process to go through having
different experiments going on at the same time. I am saying
there is an upside to the difficulties - bit like free speech
really.
 
J

John Dunlop

dorayme:
If you use a table in many situations (for layout purposes, not because the
content is really tabular), you get more consistent results over
a wider range of browsers both old and new than with css layout.

Consistent in what way? Visually?
 
J

John Dunlop

Travis Newbury:
If they all agreed, and rendered everything the same way, then
it would all look the same.

What an odd thing to say! The presupposition that rendering produces
something visible is wrong because two user-agents can render a
document in the same way without rendering anything visible.

What is behind your desire for "agreement"?
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,021
Latest member
AkilahJaim

Latest Threads

Top