should I go back to tables in HTML instead of CSS?

In followups by Brian O'Connor (ironcorona) to other posts, he repeats
the idea that using tables in CSS is not something that should be done
because IE doesn't support it. Of course I'm not happy about the fact
that IE doesn't support CSS tables. But what can one do about that?
And tables of one type or the other are needed in some cases (regardless
of whether some people feel it is appropriate or not). So the issue I
and considering right now is to back up one step and stay with tables in
HTML (e.g. TABLE/TR/TD/etc elements) for now, until either Microsoft gets
its act together better, or Firefox makes more inroads on Windows users.

If no one can give a good reason not to, I'll make that change back.

Note, this is not applicable to things that someone can prove do not need
tables.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

phil-news-nospam (AT) ipal (DOT) net wrote:

On Wed, 10 May 2006 22:47:44 +0100 Andy Dingley <dingbat (AT) codesmiths (DOT) com> wrote:
| Use a <table> when a table is the right thing to use. Otherwise don't.

But who's to decide?

You, the author

And how to decide?

I think, Steve Pugh summed it up quite well (remember this intersection
thing).

I know what a table does, and my
current method to decide is if I need what a table does, I'll use it.

Do you mean 'does' only in terms of default presentation? Then do you
also use blockquote when you need a left margin?

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

phil-news-nospam (AT) ipal (DOT) net wrote:

This has been debated in the past. There are people that say not to use
tables. Other say it's OK when using tables in CSS because then it is
presentation, whereas tables in HTML is content (marked up).

I have no idea what your last sentence is intended to mean.

When pressed to show how some thing I did use tables for could be done
in ways without tables, some things worked, and some did not

This is an entirely separate issue - don't confuse them.

There are two reasons to "not use CSS table styling" One is about
avoiding tables, one is about avoiding adding CSS table-styling to
non-table elements.

In the first case, then "tables for layout are bad" is an old
chestnut. I'm not going to try and convince you either way. There are
"acceptable tables" (including those containing "tabular data") that
should still be marked up with <table> under CSS. The definition of
"tabular data" is up to you, The definition of "acceptable tables" is
also up to you -- it's extended beyond pure "tabular data" by some
degree dependent on your skill (or lack of) in using CSS to control
layout without needing a grid. That much is up to you.

The second case though is based on the fallacy that "Using CSS table
behaviours to style <foo> as a table is better than coding the HTML
with <table>" This is just bogus.

If you're coding an "acceptable table", then just use <table>, don't
faff about using CSS table behaviour to pretend that isn't what you're
doing. If it's not an "acceptable table", then don't code it as one, by
any means. What counts as "acceptable" is up to you and as much design
Clue as you care to absorb.

dingbat (AT) codesmiths (DOT) com wrote:

The second case though is based on the fallacy that "Using CSS table
behaviours to style <foo> as a table is better than coding the HTML
with <table>" This is just bogus.

Why is it bogus? CSS offers presentation characteristics for grids. Why
should I use semantically inappropriate HTML table elements instead of
using semanically appropriate elements together with the presentation
characteristics for grids?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

On Thu, 11 May 2006 09:57:04 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:

I know what a table does, and my
current method to decide is if I need what a table does, I'll use it.

Do you mean 'does' only in terms of default presentation? Then do you

Yes.

also use blockquote when you need a left margin?

Frequently. When it works as desired, sure. But also has the effect of
adding a blank line above and below. When I desire to NOT have that effect,
then I use something else.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On 11 May 2006 04:28:20 -0700 dingbat (AT) codesmiths (DOT) com wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:

This has been debated in the past. There are people that say not to use
tables. Other say it's OK when using tables in CSS because then it is
presentation, whereas tables in HTML is content (marked up).

I have no idea what your last sentence is intended to mean.

I'll rephrase:

There are people who have said that when I need tables for a purpose
other than for the purpose intended in HTML, then I should use tables
in CSS.

When pressed to show how some thing I did use tables for could be done
in ways without tables, some things worked, and some did not

This is an entirely separate issue - don't confuse them.

Separate from what?

There are two reasons to "not use CSS table styling" One is about
avoiding tables, one is about avoiding adding CSS table-styling to
non-table elements.

In the first case, then "tables for layout are bad" is an old
chestnut. I'm not going to try and convince you either way. There are
"acceptable tables" (including those containing "tabular data") that
should still be marked up with <table> under CSS. The definition of
"tabular data" is up to you, The definition of "acceptable tables" is
also up to you -- it's extended beyond pure "tabular data" by some
degree dependent on your skill (or lack of) in using CSS to control
layout without needing a grid. That much is up to you.

The examples that have been show by others, who are presumably better at
using CSS than I am, have accomplished the task. Until someone can do
better, I have to conclude that there are some things which tables (in
CSS) can do, that cannot be done otherwise (short of constructing the
whole thing in a giant image).

I've heard the "tables for layout are bad" things for ages. But some
people who have said that recently have said it's OK if you use tables
in CSS instead of HTML. And there are some that say it is not OK to
use tables at all. I wish I could lock those different groups together
in a room and feed them pizza and sodapop until the decide which it
shall be :-)

The second case though is based on the fallacy that "Using CSS table
behaviours to style <foo> as a table is better than coding the HTML
with <table>" This is just bogus.

If you're coding an "acceptable table", then just use <table>, don't
faff about using CSS table behaviour to pretend that isn't what you're
doing. If it's not an "acceptable table", then don't code it as one, by
any means. What counts as "acceptable" is up to you and as much design
Clue as you care to absorb.

I have layouts to do where things load float don't work right, or require
other hacks to get them to work right where the other hacks have bad effects
in other ways. Effects I have seen include boxes falling to the next row,
text spilling out from the box, and excessive space gaps.

I know I'm using tables when I use tables. But as others have said, in
HTML it's content, and in CSS it's presentation, and that's not exactly
the same meaning (e.g. in HTML it means that's tabular data and implies
a default table presentation).

Anyway, I intend to use tables until shown another way that _completely_
has the same effect on presentation, but I will use tables in HTML for
cases where IE audience is important (e.g. for all but geek sites), even
though the data is not considered tabular by some people (most did not
give a precise non-circular definition).

In other media, like video, I can just put things where I want it. But
of course that media is a relatively fixed media (the transition to high
definition video has complicated it just a bit, but still nowhere near
the complication of web layout). Of course it would be nice to be able
to just simply once specify that the station logo is to track the network
logo as it spins and moves into and out of the screen. But it's generally
not that hard to replicate the entire effect and overlay it. Sometimes
it's better to have the effect come the other way, anyway.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On Thu, 11 May 2006 22:34:03 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:
On Thu, 11 May 2006 09:57:04 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:
| Do you mean 'does' only in terms of default presentation? Then do you
| also use blockquote when you need a left margin?

Frequently. When it works as desired, sure.

Again, "works" only in terms of default presentation. So you don't care
at all about the structure the elements create. I give up, sorry, good
night.

I care about the end results. I'm happy to use "the ethically right way"
to get those end results, if such a way exists, works, is practical to use,
and works universally over the browsers by audience uses (which for non-geek
audience includes IE, unfortunately). But if "the ethically right way"
cannot achieve the designed end results, even with manipulations of the
default presentation in CSS, then I have no choice but to give up on "the
ethically right way", at least for now, as I have for years already. It's
just that today, I know I can get closer to it. Just not there yet.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

phil-news-nospam (AT) ipal (DOT) net wrote:

I care about the end results.

Again, "end results" only in terms of default visual presentation. You
don't seem to care about end results in terms of structure, end results
in non-visual user agents that render structure to the user. If you use
inappropriate structural elements just because of their default visual
presentation, the non-visual presentation ("end result") will be wrong.

Have you ever heard of web accessibility?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

phil-news-nospam (AT) ipal (DOT) net wrote:

On Thu, 11 May 2006 22:38:25 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:
| phil-news-nospam (AT) ipal (DOT) net wrote:
|> On Thu, 11 May 2006 10:04:32 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:
|> | Of course you can question grid layouts being appropriate for the WWW.
|
|> I don't (question grid layouts). Why should I?
|
| Some people do.

Why do they?

Because they care for more than visual end results in desc top browsers
run in full-screen mode. They do care e.g. for visual end results on
PDAs etc. and don't want horizontal scroll bars.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

On Fri, 12 May 2006 10:22:30 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:

phil-news-nospam (AT) ipal (DOT) net wrote:

I care about the end results.

Again, "end results" only in terms of default visual presentation. You
don't seem to care about end results in terms of structure, end results
in non-visual user agents that render structure to the user. If you use
inappropriate structural elements just because of their default visual
presentation, the non-visual presentation ("end result") will be wrong.

Have you ever heard of web accessibility?

Yes. But my current focus is on getting the _visual_ results. The fact
that the standards are poor at defined faciities and certain browsers are
even worse at provided facilities means this end up having to be a big
hack job. Not all of what I want to do can be done in CSS. That is just
simply a fact. And from what people tell me of CSS3, it looks like it
will be a step in the right direction, but still some distance away from
"presentation nirvana".

It would be great if I could markup content purely semantically, and make
specifications for all different kinds of presentations and get each one
exactly as desired. But the current methods simply do not provide this,
so I have to work around it.

There are two aspects to this problem. One is the ability to create a
presentation for a variety of different media. The other is the ability
to change the presentation entirely separate from the content. I'm not
so sure the 2nd of those can ever be achieved.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------