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

[phil-news-nospam]

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

[Andy Dingley]

On 10 May 2006 18:31:29 GMT, ph**************@ipal.net wrote:

Of course I'm not happy about the fact
that IE doesn't support CSS tables.
IE does support them, but only on the <table> element (and also I think
on XML, when rendered purely by XML).

OTOH, pretty much everything that's wrong about mis-using <table> is
just as bad when applied to a <foo> element that's being styled into a
table by CSS.

There is no _need_ to style <foo> (or at least <html:div> or
<html:span>) into being table-like by using CSS. If it's right to do
that, just use the <table> in the first place. CSS table behaviour only
arose to solve an XML problem, not to solve a HTML non-problem.
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.

Use a <table> when a table is the right thing to use. Otherwise don't.

[phil-news-nospam]

On Wed, 10 May 2006 22:47:44 +0100 Andy Dingley <di*****@codesmiths.com> wrote:
| On 10 May 2006 18:31:29 GMT, ph**************@ipal.net wrote:
|
|>Of course I'm not happy about the fact
|>that IE doesn't support CSS tables.
|
| IE does support them, but only on the <table> element (and also I think
| on XML, when rendered purely by XML).
|
| OTOH, pretty much everything that's wrong about mis-using <table> is
| just as bad when applied to a <foo> element that's being styled into a
| table by CSS.

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

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 (usually
when they tried, there was some other undesired effect that I had not
mentioned as a requirement ... so their efforts were at least genuine).

All in all, some things just need tables, whether or not that is people's
view of what tables should be used for.
| There is no _need_ to style <foo> (or at least <html:div> or
| <html:span>) into being table-like by using CSS. If it's right to do
| that, just use the <table> in the first place. CSS table behaviour only
| arose to solve an XML problem, not to solve a HTML non-problem.

Maybe the people that tell me to use CSS tables instead of HTML tables
will step in here. I'm not the one to defend switching to CSS tables.

I've found it is not possible in all cases to make the HTML file be pure
content and semantics. There are some cases where that is possible. But
those are in things like informational documents (like a help page about
some program). When it comes to making a web site that is very layout
oriented, and likely highly graphical, some things that really are not
content just have to be in the HTML to get the desired results on the
site page.
|>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.
|
| Use a <table> when a table is the right thing to use. Otherwise don't.

But who's to decide? And how to decide? I know what a table does, and my
current method to decide is if I need what a table does, I'll use it. And
I don't mind doing it in HTML instead of CSS as that's what I've been doing
for years already, though for many things that can otherwise done in tables
such as the shadow effect. See http://linuxhomepage.com/ (until I redo it
in a few days or weeks or whenever) to see an excess usage of tables. My
objective is to let users customize the style (e.g. skins) to some extent
in the future. I want to make sure I provide sufficient HTML to let that
be easy enough to do in CSS. The drop shadows will likely be 3 DIVs that
can be customized as desired. I hope tables will be at a minimum of just
1 row of N columns.

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

[Johannes Koch]

ph**************@ipal.net wrote:

On Wed, 10 May 2006 22:47:44 +0100 Andy Dingley <di*****@codesmiths.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.)

[Johannes Koch]

Andy Dingley wrote:

On 10 May 2006 18:31:29 GMT, ph**************@ipal.net wrote:

Of course I'm not happy about the fact
that IE doesn't support CSS tables.
IE does support them, but only on the <table> element

At least it acts as if it supported them for table etc.
OTOH, pretty much everything that's wrong about mis-using <table> is
just as bad when applied to a <foo> element that's being styled into a
table by CSS.
Well, foo may be sematically more appropriate because its contents do
not show the relationships to each other that are declared by the use of
table/tr/td.

Of course you can question grid layouts being appropriate for the WWW.
There is no _need_ to style <foo> (or at least <html:div> or
<html:span>) into being table-like by using CSS.
Right, you don't _need_ a grid layout.
If it's right to do
that, just use the <table> in the first place.
If it's semantically approriate.
CSS table behaviour only
arose to solve an XML problem, not to solve a HTML non-problem.

That's true, however it is not limited to HTML tables and e.g. Docbook
tables.

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

[dingbat]

ph**************@ipal.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.

[Johannes Koch]

di*****@codesmiths.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.)

[phil-news-nospam]

On Thu, 11 May 2006 09:57:04 +0200 Johannes Koch <ko**@w3development.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/ |
-----------------------------------------------------------------------------

[phil-news-nospam]

On 11 May 2006 04:28:20 -0700 di*****@codesmiths.com wrote:
|
| ph**************@ipal.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/ |
-----------------------------------------------------------------------------

[phil-news-nospam]

On Thu, 11 May 2006 10:04:32 +0200 Johannes Koch <ko**@w3development.de> wrote:
| Andy Dingley wrote:
|
|> On 10 May 2006 18:31:29 GMT, ph**************@ipal.net wrote:
|>
|>>Of course I'm not happy about the fact
|>>that IE doesn't support CSS tables.
|>
|> IE does support them, but only on the <table> element
|
| At least it acts as if it supported them for table etc.
|
|> OTOH, pretty much everything that's wrong about mis-using <table> is
|> just as bad when applied to a <foo> element that's being styled into a
|> table by CSS.
|
| Well, foo may be sematically more appropriate because its contents do
| not show the relationships to each other that are declared by the use of
| table/tr/td.
|
| Of course you can question grid layouts being appropriate for the WWW.

I don't (question grid layouts). Why should I?
|> There is no _need_ to style <foo> (or at least <html:div> or
|> <html:span>) into being table-like by using CSS.
|
| Right, you don't _need_ a grid layout.

About the only things we _need_ is air to breath, food to eat, water to
drink, cover from rain and snow, heat in cold weather, and a place to
relieve ourselves.

Most web sites today are as much about presentation as about content.
Presentation actually helps reading. I indent my programming code in
the C language to help me read it. It supplements the meaning of the
code for humans to observe, but has no effect on compilation results.
But it's important because without it, my code would be so much harder
for me to work with. So presentation really is important. But even
then, people don't all agree on how much indentation is right for C.

So technically speaking, you are right that we don't _need_ a grid
layout. But it is part of what the objective to accomplish is, so it
will end up being used.
|> If it's right to do
|> that, just use the <table> in the first place.
|
| If it's semantically approriate.

Or if it's the only way to accomplish the end goals in a defective browser.

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

[Johannes Koch]

ph**************@ipal.net wrote:

On Thu, 11 May 2006 09:57:04 +0200 Johannes Koch <ko**@w3development.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.

--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

[Johannes Koch]

ph**************@ipal.net wrote:

On Thu, 11 May 2006 10:04:32 +0200 Johannes Koch <ko**@w3development.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.
|> There is no _need_ to style <foo> (or at least <html:div> or
|> <html:span>) into being table-like by using CSS.
|
| Right, you don't _need_ a grid layout.

About the only things we _need_ is air to breath, food to eat, water to
drink, cover from rain and snow, heat in cold weather, and a place to
relieve ourselves.
Yes :-)
Most web sites today are as much about presentation as about content.
Presentation actually helps reading.

I don't question the importance of layout. But whether a grid layout is
really needed (meaning: presentation can't be done with a different
layout) in most of the situation where it is used today _is_ questionable.

--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

[phil-news-nospam]

On Thu, 11 May 2006 22:34:03 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> On Thu, 11 May 2006 09:57:04 +0200 Johannes Koch <ko**@w3development.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]

On Thu, 11 May 2006 22:38:25 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> On Thu, 11 May 2006 10:04:32 +0200 Johannes Koch <ko**@w3development.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?
|> |> There is no _need_ to style <foo> (or at least <html:div> or
|> |> <html:span>) into being table-like by using CSS.
|> |
|> | Right, you don't _need_ a grid layout.
|>
|> About the only things we _need_ is air to breath, food to eat, water to
|> drink, cover from rain and snow, heat in cold weather, and a place to
|> relieve ourselves.
|
| Yes :-)
|
|> Most web sites today are as much about presentation as about content.
|> Presentation actually helps reading.
|
| I don't question the importance of layout. But whether a grid layout is
| really needed (meaning: presentation can't be done with a different
| layout) in most of the situation where it is used today _is_ questionable.

The desired end results of visual appearance are invariant. If a different
underlying mechanism can be used to get those same end results, then I would
be interested. Some people have succeed in showing me ways to do things in
CSS that I had not gotten to work before, or had not even considered. But
other people have failed to achieve the end results. A few seem to really
be trying to vary those end results. That won't happen. If getting the
end results I finally decide I want requires a massive image for the whole
page, then that's what I'll do. Fortunately, that has not been needed.
I just want to make it clear that the visual appearance end results are not
something I'm considering changing unless there is absolutely no way to do
it at all (not even with massive HTML tables and wedgy GIFs ... a practice
I do know how to do).

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

[Johannes Koch]

ph**************@ipal.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.)

[Johannes Koch]

ph**************@ipal.net wrote:

On Thu, 11 May 2006 22:38:25 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> On Thu, 11 May 2006 10:04:32 +0200 Johannes Koch <ko**@w3development.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.)

[Andy Dingley]

On Thu, 11 May 2006 14:34:56 +0200, Johannes Koch
<ko**@w3development.de> wrote:

di*****@codesmiths.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?

In the context of your posting, for two reasons.
CSS offers presentation characteristics for grids.
CSS does not offer presentation characteristics "for grids", it offers
them for tables, specifically identified as such. This feature was
created to allow CSS to style non-HTML languages, including XML, that
did not have a pre-defined <table> concept. It was never intended for
use elsewhere in HTML, except as a default rendering for <html:table>

Nowhere in the CSS TR, not in Lie & Bos' CSS book, is the use of CSS
advocated for imposing a grid-like structure on non-<table> HTML.
: The preceding example shows how CSS works with HTML 4 elements;
: in HTML 4, the semantics of the various table elements (TABLE, CAPTION,
: THEAD, TBODY, TFOOT, COL, COLGROUP, TH, and TD) are well-defined. In
: other document languages (such as XML applications), there may not be
: pre-defined table elements. Therefore, CSS 2.1 allows authors to "map"
: document language elements to table elements via the 'display'
: property.
Now this clearly doesn't _forbid applying CSS table properties to other
elements, but that's a matter of consistent application to all elements
equally, not intent.

Why
should I use semantically inappropriate HTML table elements instead of
using semanically appropriate elements together with the presentation
characteristics for grids?

It's semantically appropriate to do anything you like in HTML which
involves puttng something with a grid-like semantic connotation into a
<table> HTML just doesn't _have_ any semantics, beyond the most
trivial -- it's really difficult to mis-use them. If you have the
slightest justification for describing somethign as "grid like", then
stick it in <table>

[Andy Dingley]

On 11 May 2006 16:29:56 GMT, ph**************@ipal.net wrote:

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.
Then they're wrong. This is a mis-use of CSS. It's legal CSS, but then
so is the expression "a = 1/0" legal in most programmng languages.
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.
They're both wrong. It's right to use tables when it's right to use
tables, and if it's right to use tables then it's right to use <table>.
There are no other sorts of "table rightness".

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 haven't seen your examples. But floats _are_ hard (read the article at
brainjar.com). Also floats often cope with inadequate rendering space by
changng their orientation, not by squeezing their width or by
overflowing, as tables do. You _can_ make them do this, but it's not the
default.

If you want a grid and you _must_ have a grid, then use a <table>.
Chances are that you don't really need one that much, but hey - it's
your call. You're still writing HTML though and the way you get grids
in HTML+CSS is by using <table>.

Guess what - no-one cares if you use <table>. There aren't any HTML
pixies reading every page. What we care about are the _wrong_ use of
<table>s, or <table>s when you shoudl have used something else that was
better. If what you need is grid-like rendering at the cost of all
else, despite other possible choices with float or inline-block, then
get to it and use that <table>.

There's also the point that obtaining CSS table-like rendering by using
<table> works and is portable, unlike expecting the same CSS table-like
rendering to work if you use CSS properties to apply it to <ul> instead.
Now I'm certainly no advocate of hacking the standard to fit around IE's
errors, but using CSS for non-<table> table-style rendering in HTML
isn't even _in_ the CSS recommendation, it's just an emerggent
possibility that wasn't specifically ruled out.

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

You haven't used MPEG-7 8-)

--
Die Gotterspammerung - Junkmail of the Gods

[phil-news-nospam]

On Fri, 12 May 2006 10:25:45 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|
|> On Thu, 11 May 2006 22:38:25 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | ph**************@ipal.net wrote:
|> |> On Thu, 11 May 2006 10:04:32 +0200 Johannes Koch <ko**@w3development.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.

So basically, screw the regular visual user with a lousy presentation so
the other class of users get something they like. Sorry, but I don't go
that way. I believe that even things like the navigation tree needs to
be different for things like a PDA or cell phone or aural output. The
_amount_ of information at each node needs to be different for different
types of media. I will not attempt to try to "shoe horn" one into another.

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

On Fri, 12 May 2006 10:22:30 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.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/ |
-----------------------------------------------------------------------------

[Johannes Koch]

Andy Dingley wrote:

CSS does not offer presentation characteristics "for grids", it offers
them for tables, specifically identified as such. This feature was
created to allow CSS to style non-HTML languages, including XML, that
did not have a pre-defined <table> concept. It was never intended for
use elsewhere in HTML, except as a default rendering for <html:table>
You are right. So there is no way of creating grids for just layouting
stuff in HTML/CSS.
It's semantically appropriate to do anything you like in HTML which
involves puttng something with a grid-like semantic connotation into a
<table>

except for using table purely as a means to layout document content
which is an explicit should not.

--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

[Johannes Koch]

ph**************@ipal.net wrote:

So basically, screw the regular visual user with a lousy presentation so
the other class of users get something they like.

It's not table layout vs. lousy presentation. Many web developers use
visually attractive table-less layouts nowadays, that do adapt to
various browsing situations, better than table layouts can.

--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

[Andy Dingley]

On Fri, 12 May 2006 22:34:27 +0200, Johannes Koch
<ko**@w3development.de> wrote:

You are right. So there is no way of creating grids for just layouting
stuff in HTML/CSS.

What's wrong with using a <table> for layout _as_a_table_ ?

The old bugbear of "layout tables" was a reaction to old code that used
<table> to set margins and the like, and was generally 3 columns, two of
which were blank. If you're actually wanting a repeated grid stucture,
<table> is the right thing to use.

[Johannes Koch]

Andy Dingley wrote:

On Fri, 12 May 2006 22:34:27 +0200, Johannes Koch
<ko**@w3development.de> wrote:

You are right. So there is no way of creating grids for just layouting
stuff in HTML/CSS.

What's wrong with using a <table> for layout _as_a_table_ ?

You removed my second sentence.
"Tables should not be used purely as a means to layout document
content"
HTML 4.01, 11.1, 6nd paragraph
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

[Matt Kruse]

Johannes Koch wrote:

"Tables should not be used purely as a means to layout document
content"
HTML 4.01, 11.1, 6nd paragraph

In the absence of an alternative that provides the same benefits (rigid
structure and positioning, backwards compatability with similar visual
results, ease of development and maintenance) then I disagree.

I've done a fair amount of layout using purely CSS and I'm quite familiar
with the arguments on each side of the "table layout" debate. In the end, I
chose a very simple table structure to layout
http://www.javascripttoolbox.com/ , for example. As long as the "layout
table" is used only for creating a rigid layout grid and not for CSS tasks
(spacing, widths, colors, etc) then I think it offers more benefits than a
CSS-only solution.

I've never had a single user complaint.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[phil-news-nospam]

On Fri, 12 May 2006 22:34:27 +0200 Johannes Koch <ko**@w3development.de> wrote:
| Andy Dingley wrote:
|> CSS does not offer presentation characteristics "for grids", it offers
|> them for tables, specifically identified as such. This feature was
|> created to allow CSS to style non-HTML languages, including XML, that
|> did not have a pre-defined <table> concept. It was never intended for
|> use elsewhere in HTML, except as a default rendering for <html:table>
|
| You are right. So there is no way of creating grids for just layouting
| stuff in HTML/CSS.
|
|> It's semantically appropriate to do anything you like in HTML which
|> involves puttng something with a grid-like semantic connotation into a
|> <table>
|
| except for using table purely as a means to layout document content
| which is an explicit should not.

Then I think they should add this capability in another form, to CSS3,
so that we have a means to do the layouts in a way that works like that
of tables. Ironically, whatever it would be called, it would just be a
duplication of tables; implementation would be to alias a new name to
the existing tables capability. So then what is the gain?

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

On Fri, 12 May 2006 20:35:40 +0100 Andy Dingley <di*****@codesmiths.com> wrote:
| On Thu, 11 May 2006 14:34:56 +0200, Johannes Koch
| <ko**@w3development.de> wrote:
|
|>di*****@codesmiths.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?
|
| In the context of your posting, for two reasons.
|
|> CSS offers presentation characteristics for grids.
|
| CSS does not offer presentation characteristics "for grids", it offers
| them for tables, specifically identified as such. This feature was
| created to allow CSS to style non-HTML languages, including XML, that
| did not have a pre-defined <table> concept. It was never intended for
| use elsewhere in HTML, except as a default rendering for <html:table>
|
| Nowhere in the CSS TR, not in Lie & Bos' CSS book, is the use of CSS
| advocated for imposing a grid-like structure on non-<table> HTML.

So, yes or no ... if I need a grid-like structure for some part of a page,
or maybe even for all of it, there is no more of a problem just using the
TABLE/TR/TD elements in HTML than there is with using display:table* in CSS?
| Now this clearly doesn't _forbid applying CSS table properties to other
| elements, but that's a matter of consistent application to all elements
| equally, not intent.

It seems that, if not already there, CSS is headed towards being able
to full specify how to present, in least in some media, every possible
element of HTML and XML ... e.g. a default stylesheet. So in the end,
without a default stylesheet at all, the elements would nothing more
than the semantics of markup, and all elements would be alike. So at
that point, why even have a restricted name set of elements and why
even have the class attribute? Why not just let elements be named at
will, and not bother with classes? Instead of <div class="foo"> I could
simply have <foo> and reference it from CSS with just: foo { ... }
That wouldn't mean we can't have default elements and default style for
them. It would just mean we have a simpler way to extend it.
|> Why
|>should I use semantically inappropriate HTML table elements instead of
|>using semanically appropriate elements together with the presentation
|>characteristics for grids?
|
| It's semantically appropriate to do anything you like in HTML which
| involves puttng something with a grid-like semantic connotation into a
| <table> HTML just doesn't _have_ any semantics, beyond the most
| trivial -- it's really difficult to mis-use them. If you have the
| slightest justification for describing somethign as "grid like", then
| stick it in <table>

Like how http://craigslist.org/ is built?

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

On Fri, 12 May 2006 23:36:41 +0100 Andy Dingley <di*****@codesmiths.com> wrote:
| On Fri, 12 May 2006 22:34:27 +0200, Johannes Koch
| <ko**@w3development.de> wrote:
|
|>You are right. So there is no way of creating grids for just layouting
|>stuff in HTML/CSS.
|
| What's wrong with using a <table> for layout _as_a_table_ ?
|
| The old bugbear of "layout tables" was a reaction to old code that used
| <table> to set margins and the like, and was generally 3 columns, two of
| which were blank. If you're actually wanting a repeated grid stucture,
| <table> is the right thing to use.

See my http://linuxhomepage.com/ page. It uses tables not just for the
three column layout, but also to construct boxes, borders and shadows.
The latter can be done in CSS (I've done so), and will soon be replaced
on that site. I can certainly see the "bias" against tables coming from
uses like that. But it seems that "bias" is trying to go further. Or
it could just be the people that don't want to see so much "structure"
in web pages, and prefer to have simpler "documents" consisting mostly
of text and maybe some lists.

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

On Sat, 13 May 2006 01:52:37 +0200 Johannes Koch <ko**@w3development.de> wrote:
| Andy Dingley wrote:
|> On Fri, 12 May 2006 22:34:27 +0200, Johannes Koch
|> <ko**@w3development.de> wrote:
|>
|>>You are right. So there is no way of creating grids for just layouting
|>>stuff in HTML/CSS.
|>
|> What's wrong with using a <table> for layout _as_a_table_ ?
|
| You removed my second sentence.
| "Tables should not be used purely as a means to layout document
| content"
| HTML 4.01, 11.1, 6nd paragraph

So we should use tables for other things, too? I can go along with that.

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

On Fri, 12 May 2006 22:43:50 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> So basically, screw the regular visual user with a lousy presentation so
|> the other class of users get something they like.
|
| It's not table layout vs. lousy presentation. Many web developers use
| visually attractive table-less layouts nowadays, that do adapt to
| various browsing situations, better than table layouts can.

Show me some. But not simplistic blog pages. Show me one that looks
like CraigsList.Org but uses no tables ... and works in IE, too.

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

On Fri, 12 May 2006 20:51:11 +0100 Andy Dingley <di*****@codesmiths.com> wrote:

| If you want a grid and you _must_ have a grid, then use a <table>.
| Chances are that you don't really need one that much, but hey - it's
| your call. You're still writing HTML though and the way you get grids
| in HTML+CSS is by using <table>.

In http://linuxhomepage.com/ there is a mass of tables. My intent is to
make the site do the box presentations with CSS instead of excessive use
of tables. I've replicated it with only one table, and that table has
one row and three columns to create the column layout. I am exploring
other styles for the purpose of making sure I provide adequate HTML so
others can make their own style over a wide range of possibilities. The
one thing I have found is that I do need a few layers of DIV elements on
each box so there are enough to create the effects. For example the drop
shadow effect needs at least 2 layers. But when I extend that to make
the box rise up (shifts to the top and left while the shadow itself shifts
to the bottom and right) I find I need 1 more DIV elementy surrounding the
whole thing so I can use that one to engage the :hover action on it. If
I use :hover on the shifted boxes, the fact that they shift in position
leaves open some locations where the pointer can trigger oscillation.
So that is why I will have a number of extra DIV layers; they are just
handles for CSS writers to use to create more complex styles. But there
will be that one layer of TABLE/TR/TD ... you think that is OK?
| Guess what - no-one cares if you use <table>. There aren't any HTML
| pixies reading every page. What we care about are the _wrong_ use of
| <table>s, or <table>s when you shoudl have used something else that was
| better. If what you need is grid-like rendering at the cost of all
| else, despite other possible choices with float or inline-block, then
| get to it and use that <table>.

Maybe what the people telling me not to use tables really mean is to not
use a grid-like structure, and to make my page some other way that they
are envisioning which may approximate the grid or columnized layout, but
not really be 100% that.
| There's also the point that obtaining CSS table-like rendering by using
| <table> works and is portable, unlike expecting the same CSS table-like
| rendering to work if you use CSS properties to apply it to <ul> instead.
| Now I'm certainly no advocate of hacking the standard to fit around IE's
| errors, but using CSS for non-<table> table-style rendering in HTML
| isn't even _in_ the CSS recommendation, it's just an emerggent
| possibility that wasn't specifically ruled out.

I believe most of the original standards developers, and perhaps even
many still today, are focused on making things for "academic" documents,
rather than what so much of the web has become (and is often hated for)
in promoting business and marketing.

I still use "goto" statements in my programming, too.

More readings:
http://www.meyerweb.com/eric/comment/chech.html
|>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).
|
| You haven't used MPEG-7 8-)

It's what the video creation tools provide, which is timeline oriented
and very WYSIWYG (and also WYHIWYG). If I want to make some text just
a tad big larger, I can, without having to even think about it in points
or any other measures. And yet it is still all a set of layered objects
such that I can come back later and replace the base video that network
provided with the new video for next week's episode promotion. Then when
I run the playout to record to tape, it all gets "flattened" together and
I see the finished product.

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

[Neredbojias]

To further the education of mankind, "Matt Kruse"
<ne********@mattkruse.com> vouchsafed:

Johannes Koch wrote:

"Tables should not be used purely as a means to layout document
content"
HTML 4.01, 11.1, 6nd paragraph

In the absence of an alternative that provides the same benefits
(rigid structure and positioning, backwards compatability with similar
visual results, ease of development and maintenance) then I disagree.

I've done a fair amount of layout using purely CSS and I'm quite
familiar with the arguments on each side of the "table layout" debate.
In the end, I chose a very simple table structure to layout
http://www.javascripttoolbox.com/ , for example. As long as the
"layout table" is used only for creating a rigid layout grid and not
for CSS tasks (spacing, widths, colors, etc) then I think it offers
more benefits than a CSS-only solution.

I've never had a single user complaint.

You've never had me as a user...

Actually, the css box-model allows you to make almost any kind of box
imaginable except the one you really want.

--
Neredbojias
Infinity has its limits.

[Neredbojias]

To further the education of mankind, ph**************@ipal.net
vouchsafed:

On Fri, 12 May 2006 22:43:50 +0200 Johannes Koch
<ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> So basically, screw the regular visual user with a lousy
|> presentation so the other class of users get something they like.
|
| It's not table layout vs. lousy presentation. Many web developers use
| visually attractive table-less layouts nowadays, that do adapt to
| various browsing situations, better than table layouts can.

Show me some. But not simplistic blog pages. Show me one that looks
like CraigsList.Org but uses no tables ... and works in IE, too.

If you're talking about the home page, what's so difficult about that? A
bunch of emed-width and absolutely-positioned divs would do it.

--
Neredbojias
Infinity has its limits.

[Johannes Koch]

ph**************@ipal.net wrote:

On Fri, 12 May 2006 22:34:27 +0200 Johannes Koch <ko**@w3development.de> wrote:
| Andy Dingley wrote:
|> It's semantically appropriate to do anything you like in HTML which
|> involves puttng something with a grid-like semantic connotation into a
|> <table>
|
| except for using table purely as a means to layout document content
| which is an explicit should not.

Then I think they should add this capability in another form, to CSS3,
so that we have a means to do the layouts in a way that works like that
of tables.
It's already there. But they might change the table* display values to
grid*. Or put some text into the prose that its use is not only for
presenting tables (relationships) but also for any kind of grid.
Ironically, whatever it would be called, it would just be a
duplication of tables; implementation would be to alias a new name to
the existing tables capability. So then what is the gain?

It would only be about presentation (CSS), not about relationships
(HTML). But I think we already had this topic. Again: CSS offers
'font-weight: bold' to visually present something bold, whereas HTML
offers an element strong for conveying strong emphasis. It would be
easier for you to understand this if you stopped thinking of HTML being
a visual presentation language, which it is _not_.

--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)

[phil-news-nospam]

On Sat, 13 May 2006 02:03:15 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:
| To further the education of mankind, "Matt Kruse"
| <ne********@mattkruse.com> vouchsafed:
|
|> Johannes Koch wrote:
|>> "Tables should not be used purely as a means to layout document
|>> content"
|>> HTML 4.01, 11.1, 6nd paragraph
|>
|> In the absence of an alternative that provides the same benefits
|> (rigid structure and positioning, backwards compatability with similar
|> visual results, ease of development and maintenance) then I disagree.
|>
|> I've done a fair amount of layout using purely CSS and I'm quite
|> familiar with the arguments on each side of the "table layout" debate.
|> In the end, I chose a very simple table structure to layout
|> http://www.javascripttoolbox.com/ , for example. As long as the
|> "layout table" is used only for creating a rigid layout grid and not
|> for CSS tasks (spacing, widths, colors, etc) then I think it offers
|> more benefits than a CSS-only solution.
|>
|> I've never had a single user complaint.
|
| You've never had me as a user...
|
| Actually, the css box-model allows you to make almost any kind of box
| imaginable except the one you really want.

However, even moderately complex boxes require that there be multiple
element in the HTML (usually DIV elements would be appropriate) so that
the various components being constructed into a box can be assembled in
the proper order.

Consider a drop shadow box with hover changing the offsets to effect a
rise in the visual appearance when the pointer moves over. This takes
three layers of DIV the best I've been abled to do it. One requirement
I have is that it not oscillate. So that means a non-shifting outer
box has to be where the hover detection is applied. Then the 2nd box
would be offset for the shadow, and the third box offset back more the
other way to create the front box. If the contents that goes inside
needs settings that would conflict with the front box, then even a 4th
box would be needed, and thus a 4th level of nested DIV in the HTML.

CSS would be better if it allowed a way to create the effect of multiple
box layers while applying the entire set to exactly one element in HTML.
That way, the HTML won't need to be coded to accomodate the presentation
style.

Someone pointed out to me how to get rounded corners with a special
property called -moz-border-radius which works, but not ideally. If
CSS could not only adopt this, but also adopt anti-aliasing for it,
that would improve.

Another improvement would be multiple borders. I can do that with images
and tables (oh, people will definitely hate it). Wouldn't it be better
to allow that in CSS? Or would you want to exclude it from CSS because
it is so ugly (see the last box in the following page)?

http://phil.ipal.org/usenet/ciwas/2006-05-11/rbox.html

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

On Sat, 13 May 2006 10:22:37 +0200 Johannes Koch <ko**@w3development.de> wrote:
| ph**************@ipal.net wrote:
|> On Fri, 12 May 2006 22:34:27 +0200 Johannes Koch <ko**@w3development.de> wrote:
|> | Andy Dingley wrote:
|> |> It's semantically appropriate to do anything you like in HTML which
|> |> involves puttng something with a grid-like semantic connotation into a
|> |> <table>
|> |
|> | except for using table purely as a means to layout document content
|> | which is an explicit should not.
|>
|> Then I think they should add this capability in another form, to CSS3,
|> so that we have a means to do the layouts in a way that works like that
|> of tables.
|
| It's already there. But they might change the table* display values to
| grid*. Or put some text into the prose that its use is not only for
| presenting tables (relationships) but also for any kind of grid.
|
|> Ironically, whatever it would be called, it would just be a
|> duplication of tables; implementation would be to alias a new name to
|> the existing tables capability. So then what is the gain?
|
| It would only be about presentation (CSS), not about relationships
| (HTML). But I think we already had this topic. Again: CSS offers
| 'font-weight: bold' to visually present something bold, whereas HTML
| offers an element strong for conveying strong emphasis. It would be
| easier for you to understand this if you stopped thinking of HTML being
| a visual presentation language, which it is _not_.

So why does HTML have both <STRONG> and <I>?

However, it is _possible_ to create a language that looks a lot like HTML
which serves multiple purposes from semantic markup to presentation style
in various media types. There would be different element spaces for each
type of purpose. There would be elements for semantics. And there would
be elements for presentation in large display visual media. And there
would be elements for presentation in small display media (actually, if
it were made conditional on display size it could handle a wide range of
possibilities with one set of specifications). Other elements would be
for audio presentation (and conditional for audio combined with visual).

Of course such a language would be bad. For one thing, it would require
data transfers of all media types even though only one or two would be
needed. And of course, there would be lots of redundancy, though a lot
of that is easily undone with appropriate data compression.

If such a language provided a means to refer in a simple way to something
in a separate specification, either at the beginning of the same file, or
in another file, much like class="foo" now refers to a .foo selector in
CSS, not only would you be removing so much of that redundancy, but also
providing a means to restyle in an easier way after data transmission.

My point here is that although it i appropriate to separate content with
it's semantic markup apart from presentation style, that is not necessarily
a natural way to think about things for many people. So do expect people
to think that presentation could be included in HTML, and also think that
it in fact was because some elements in HTML really work that way.

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

On Sat, 13 May 2006 02:17:27 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:
| To further the education of mankind, ph**************@ipal.net
| vouchsafed:
|
|> On Fri, 12 May 2006 22:43:50 +0200 Johannes Koch
|> <ko**@w3development.de> wrote:
|>| ph**************@ipal.net wrote:
|>|> So basically, screw the regular visual user with a lousy
|>|> presentation so the other class of users get something they like.
|>|
|>| It's not table layout vs. lousy presentation. Many web developers use
|>| visually attractive table-less layouts nowadays, that do adapt to
|>| various browsing situations, better than table layouts can.
|>
|> Show me some. But not simplistic blog pages. Show me one that looks
|> like CraigsList.Org but uses no tables ... and works in IE, too.
|
| If you're talking about the home page, what's so difficult about that? A
| bunch of emed-width and absolutely-positioned divs would do it.

Absolutely positioned? That's liable to break pretty badly. Sure, you
can make it track font size with emed-width (and perhaps height, too).
But how well will the layout hold with window sizes?

I'm not saying it can't be done. I'm saying it will be full of glitches
and be very hard to keep stable. Until I see someone actually achieve it
without any issues, I'm certainly NOT going to attempt it myself.

TABLES for me because ... THEY WORK.

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

[Neredbojias]

To further the education of mankind, ph**************@ipal.net
vouchsafed:

| Actually, the css box-model allows you to make almost any kind of box
| imaginable except the one you really want.

CSS would be better if it allowed a way to create the effect of
multiple box layers while applying the entire set to exactly one
element in HTML. That way, the HTML won't need to be coded to
accomodate the presentation style.
Well, at least the effect you mentioned and some others. I would expect
that this could be best accomplished by expanding the border attributes.
Someone pointed out to me how to get rounded corners with a special
property called -moz-border-radius which works, but not ideally. If
CSS could not only adopt this, but also adopt anti-aliasing for it,
that would improve.
I guess css border-radius is in the offing for css3. However, graphic
refinements like anti-aliasing may be a while in coming considering that
most browsers (-Opera is a noted exception) don't even bother to resample
images when resizing them. (The old argument that it takes too much
resources/time is no longer valid and hasn't been for years [unless you
have a crappy browser to begin with].)
Another improvement would be multiple borders. I can do that with
images and tables (oh, people will definitely hate it). Wouldn't it
be better to allow that in CSS? Or would you want to exclude it from
CSS because it is so ugly (see the last box in the following page)?

http://phil.ipal.org/usenet/ciwas/2006-05-11/rbox.html

As I said, expand the css border attributes. Btw, I made a multiple-border
image like that one once, too, with nested divs, and it looked just as
ugly.

--
Neredbojias
Infinity has its limits.

[Neredbojias]

To further the education of mankind, ph**************@ipal.net
vouchsafed:

|> Show me some. But not simplistic blog pages. Show me one that
|> looks like CraigsList.Org but uses no tables ... and works in IE,
|> too.
|
| If you're talking about the home page, what's so difficult about
| that? A bunch of emed-width and absolutely-positioned divs would do
| it.

Absolutely positioned? That's liable to break pretty badly. Sure,
you can make it track font size with emed-width (and perhaps height,
too). But how well will the layout hold with window sizes?
As well as the table version. At fixed size (em-wise), why wouldn't it?
I'm not saying it can't be done. I'm saying it will be full of
glitches and be very hard to keep stable.
Not at all. It may take a bit longer to construct but would probably be
more stable in the long run.
Until I see someone
actually achieve it without any issues, I'm certainly NOT going to
attempt it myself.
Well I'm not going to ditz around making a clone of that, either, because
it's a waste of time for me as all of my pages are at least somewhat fluid.
But even a simple example of 2 or 3 items will show you it _would_ work.
The only "trick" involved may be initially setting the correct em width for
the enclosed text.
TABLES for me because ... THEY WORK.

Didn't they say that about horses?

--
Neredbojias
Infinity has its limits.

[phil-news-nospam]

On Sat, 13 May 2006 21:01:39 -0400 Neredbojias <http://www.neredbojias.com/fliam.php?cat=alt.html> wrote:

| I guess css border-radius is in the offing for css3. However, graphic
| refinements like anti-aliasing may be a while in coming considering that
| most browsers (-Opera is a noted exception) don't even bother to resample
| images when resizing them. (The old argument that it takes too much
| resources/time is no longer valid and hasn't been for years [unless you
| have a crappy browser to begin with].)

Even so, there is the option to just do a rough rescale first and follow
that up with a clean resample. You just see the screen get better in
however much time your computer takes (and if your computer is too fast,
you miss the experience :-)
|> Another improvement would be multiple borders. I can do that with
|> images and tables (oh, people will definitely hate it). Wouldn't it
|> be better to allow that in CSS? Or would you want to exclude it from
|> CSS because it is so ugly (see the last box in the following page)?
|>
|> http://phil.ipal.org/usenet/ciwas/2006-05-11/rbox.html
|
| As I said, expand the css border attributes. Btw, I made a multiple-border
| image like that one once, too, with nested divs, and it looked just as
| ugly.

I'd like to see an easier way to do the drop shadow effect. Expanding on
the border features might well work, but there would be a lot of detail to
add to it to do stuff like shadows.

FYI, I just deployed the redesign for http://linuxhomepage.com/ ... not yet
all of what I want to do to change it, but a lot is done and it comes out OK
on Firefox (no idea about MS IE, but this site isn't one I worry much about
IE for).

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

[Dr John Stockton]

JRS: In article <e4*********@news3.newsguy.com>, dated Sat, 13 May 2006
04:43:08 remote, seen in news:comp.infosystems.www.authoring.stylesheets
, ph**************@ipal.net posted :

Then I think they should add this capability in another form, to CSS3,
so that we have a means to do the layouts in a way that works like that
of tables. Ironically, whatever it would be called, it would just be a
duplication of tables; implementation would be to alias a new name to
the existing tables capability. So then what is the gain?

Web pages are intended, on the whole, to be read as displayed by
browsers. Only the authors/maintainers need to read the source code.

So, where you have truly tabular material, use <TABLE> <TBODY> <TR> <TH>
<TD>; where you have material most readily or suitably laid out with CSS
boxes, use CSS boxes.

And where you have non-tabular material best laid out on a grid, use
<GRID> <GBODY> <GR> <GH> <GD> for your authoring; and run a pre-
processor to convert those G characters to T characters.

Now you have, as author/maintainer, the semantic indications that you
may need; and the true users have the display you intend. The only
"losers" are such as those here, who like to read the source code of
pages from the Web.

And, some years after W3 takes up the idea, the pre-processor will no
longer be needed.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Matt Kruse]

Neredbojias wrote:

I've done a fair amount of layout using purely CSS and I'm quite
familiar with the arguments on each side of the "table layout"
debate. In the end, I chose a very simple table structure to layout
http://www.javascripttoolbox.com/ , for example. >> I've never had a
single user complaint. You've never had me as a user...

If the web site is visible in your browser and the information you seek is
easily obtained, I'm not sure why you would want to complain, or on what
grounds you would do so.
Actually, the css box-model allows you to make almost any kind of box
imaginable except the one you really want.

Then the argument for tables-based layout is quite clear ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[phil-news-nospam]

On Sun, 14 May 2006 18:31:09 +0100 Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:
| JRS: In article <e4*********@news3.newsguy.com>, dated Sat, 13 May 2006
| 04:43:08 remote, seen in news:comp.infosystems.www.authoring.stylesheets
| , ph**************@ipal.net posted :
|>
|>Then I think they should add this capability in another form, to CSS3,
|>so that we have a means to do the layouts in a way that works like that
|>of tables. Ironically, whatever it would be called, it would just be a
|>duplication of tables; implementation would be to alias a new name to
|>the existing tables capability. So then what is the gain?
|
|
| Web pages are intended, on the whole, to be read as displayed by
| browsers. Only the authors/maintainers need to read the source code.
|
| So, where you have truly tabular material, use <TABLE> <TBODY> <TR> <TH>
| <TD>; where you have material most readily or suitably laid out with CSS
| boxes, use CSS boxes.

Why not CSS tables? CSS boxes don't do what I want when I want the kinds
of things I will pick tables to use.
| And where you have non-tabular material best laid out on a grid, use
| <GRID> <GBODY> <GR> <GH> <GD> for your authoring; and run a pre-
| processor to convert those G characters to T characters.

What's the point of this? The last place I can process it is the server.
And sometimes maybe not even there. I can process it in my head just as
effectively.
| Now you have, as author/maintainer, the semantic indications that you
| may need; and the true users have the display you intend. The only
| "losers" are such as those here, who like to read the source code of
| pages from the Web.

They will just see whatever <GRID> got translated to. No gain.
| And, some years after W3 takes up the idea, the pre-processor will no
| longer be needed.

Provided they do it exactly this way. I can't depend on what that standard
will end up being like.

I'd rather take a wait and see approach, and then translate TABLE and friends
to whatever new comes out, however that translation has to be made then based
on what the standard ends up being like. Afterall, only the authors need to
read the source code, as you said way above.

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

[Neredbojias]

To further the education of mankind, "Matt Kruse"
<ne********@mattkruse.com> vouchsafed:

Neredbojias wrote:

I've done a fair amount of layout using purely CSS and I'm quite
familiar with the arguments on each side of the "table layout"
debate. In the end, I chose a very simple table structure to layout
http://www.javascripttoolbox.com/ , for example. >> I've never had a
single user complaint.

You've never had me as a user...

If the web site is visible in your browser and the information you
seek is easily obtained, I'm not sure why you would want to complain,
or on what grounds you would do so.

Pretend I'm a woman.

Actually, the css box-model allows you to make almost any kind of box
imaginable except the one you really want.

Then the argument for tables-based layout is quite clear ;)

No argument from me. If you gotta use a table, use a table. I don't
disagree with you. The thing is, though, that most people _think_ they
have to use a table when they don't. That is actually the crux of the
matter right there.

I use a table in many of my headers because I want the align-right right
side delimited by and stopping at the align-left left side, not overlapping
it or dropping below it. This may not be absolutely impossible in css, but
it's improbable. As I said, "...any kind of box but the one you want."

--
Neredbojias
Infinity has its limits.

[Beauregard T. Shagnasty]

Neredbojias wrote:

I use a table in many of my headers because I want the align-right
right side delimited by and stopping at the align-left left side, not
overlapping it or dropping below it. This may not be absolutely
impossible in css, but it's improbable. As I said, "...any kind of
box but the one you want."

Something like this? No tables.
http://k75s.home.att.net/banner.html

--
-bts
-Warning: I brake for lawn deer

[Matt Kruse]

Beauregard T. Shagnasty wrote:

I use a table in many of my headers because I want the align-right
right side delimited by and stopping at the align-left left side, not
overlapping it or dropping below it.

Something like this? No tables.
http://k75s.home.att.net/banner.html

When the browser window is narrowed, content wraps and does so in an
incorrect order. (IE6, Win)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Beauregard T. Shagnasty]

Matt Kruse wrote:

Beauregard T. Shagnasty wrote:

[>> Neredbojias wrote:]

I use a table in many of my headers because I want the align-right
right side delimited by and stopping at the align-left left side,
not overlapping it or dropping below it.

Something like this? No tables.
http://k75s.home.att.net/banner.html

When the browser window is narrowed, content wraps and does so in an
incorrect order. (IE6, Win)

So how narrow was your window? Be realistic. The third one works fine
down to about a 350px wide browser window.

It was posted as a sample. Feel free to make adjustments.

--
-bts
-Warning: I brake for lawn deer

[niels.froehling]

> |> Show me some. But not simplistic blog pages. Show me one that looks

|> like CraigsList.Org but uses no tables ... and works in IE, too.
When I started learning English I didn't start with Shakespeare. It
took me 5 years to be able to fully understand Frankenstein. ;-)
Absolutely positioned? That's liable to break pretty badly. Sure, you
can make it track font size with emed-width (and perhaps height, too).
But how well will the layout hold with window sizes?
A bastard of an absolute positioned layout:

http://www.aigelsalvador.com/index.php

(but please don't repeat that anyway)
TABLES for me because ... THEY WORK.

Never believe that a compromise is OPTIMAL.

Ciao
Niels

[Matt Kruse]

Beauregard T. Shagnasty wrote:

So how narrow was your window? Be realistic. The third one works fine
down to about a 350px wide browser window.
Quite narrow, I admit. But in a realistic test case, the header may contain
much more content than your example, and wrapping problems will become
evident with wider windows.
It was posted as a sample. Feel free to make adjustments.

<table>

;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Neredbojias]

To further the education of mankind, "Beauregard T. Shagnasty"
<a.*********@example.invalid> vouchsafed:

Neredbojias wrote:

I use a table in many of my headers because I want the align-right
right side delimited by and stopping at the align-left left side, not
overlapping it or dropping below it. This may not be absolutely
impossible in css, but it's improbable. As I said, "...any kind of
box but the one you want."

Something like this? No tables.
http://k75s.home.att.net/banner.html

Yeah... That's just my point: the right drops below the left. Okay, as
you replied to Matt, it _is_ at quite a small separation, but I don't have
teeny graphics, I have text to deal with. I don't want the 2 segments to
run into each other nor change levels nor anything else. I also want the
combined widths as rendered to establish the h. scrollbar boundary, in
effect making a min-width for the page. As far as I can see, css can't do
it. (-Primarily because of the nature of the box model.)

--
Neredbojias
Infinity has its limits.