grid structures: TABLE/TR/TD vs. DIV

#1

Is there really any advantage to using DIV elements with float style
properies, vs. the old method of TABLE and TR and TD?

I'm finding that by using DIV, it still involves the same number of
elements in the HTML to get everything just right. When you consider
the class attribute on the DIV elements, there's not much size savings
anymore for using DIV.

There are other disadvantages to not using TABLE/TR/TD, such as the
lack of ability to merge cells, and keeping rows and columns aligned
with each other under varying content.

Content should be in HTML and style in CSS. So how is that affected
by whether the HTML markup has TABLE/TR/TD or just DIV.

Note that I am not talking about the use of additional tables and cells
to create stylistic effects in the grid, such as spacing between cells.
This can be done in CSS regardless of whether the elemnts involved are
TABLE/TR/TD or just DIV.

I bet someone has already written "Tables considered harmful". But is
it really justified?

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

Quote:

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

#2

On Sun, 30 Apr 2006 08:41:16 +0200, <phil-news-nospam (AT) ipal (DOT) net> wrote:

Quote:

Is there really any advantage to using DIV elements with float style
properies, vs. the old method of TABLE and TR and TD?

[ snip ]

Quote:

I bet someone has already written "Tables considered harmful". But is
it really justified?

This discussion has been done over and over again, in this group and other
www.authoring groups. Go through the archives first and then make up your
mind.
<URL:http://www.google.com/search?q=tableless+design>
<ULR:http://groups.google.com/groups/search?q=no+tables++css+group:comp.infosystems.www .authoring.*+group:alt.html.*>

In short:
- Try to understand what markup is for: it 'tells' browsers and bots and
the like what your content is. So a div is only needed if no other
appropriate element is available (likewise with <span>).
- Tables are for tabular data. Using them for layout purposes is just the
same thing as using blockquote for the left margin, <br> for whitespace
between paragraphs,   for padding on inline elements, <h4> for
creating a block of text with a slightly larger, bold font. Just a few
examples. It shows the author doesn't understand markup. It is all about
abusing elements because of there appearance in graphical browsers.

If done properly, in a html page the content is structured and marked up
using meaningful elements. This should give the author already a lot of
'handles' to create the appearance of the page, for every element s/he
uses in the body of the page, including the body element itself, can be
used as a selector in a style sheet.
If some content needs to be treated differently than the standard looks
the author created for the element, it gets a class or maybe an id. If
some content is to be 'physically separated' from the rest of the page,
the author can put it in a containing div and asign a class or id to that
div.

Once an author understands the concept of markup, why it came about in the
first place, how to use it properly, s/he will no longer feel the need for
tables for layout any longer.

--
______PretLetters:

Quote:

#3

On Sun, 30 Apr 2006 09:35:03 +0200 Barbara de Zoete <trashbin (AT) pretletters (DOT) net> wrote:

Quote:

On Sun, 30 Apr 2006 08:41:16 +0200, <phil-news-nospam (AT) ipal (DOT) net> wrote:

Is there really any advantage to using DIV elements with float style
properies, vs. the old method of TABLE and TR and TD?

[ snip ]

I bet someone has already written "Tables considered harmful". But is
it really justified?

This discussion has been done over and over again, in this group and other
www.authoring groups. Go through the archives first and then make up your
mind.
URL:http://www.google.com/search?q=tableless+design
ULR:http://groups.google.com/groups/sear...oup:alt.html.*

In short:
- Try to understand what markup is for: it 'tells' browsers and bots and
the like what your content is. So a div is only needed if no other
appropriate element is available (likewise with <span>).

Stop with the "try to understand" religion. I'm getting tired of it.

Quote:

- Tables are for tabular data. Using them for layout purposes is just the
same thing as using blockquote for the left margin, <br> for whitespace
between paragraphs,   for padding on inline elements, <h4> for
creating a block of text with a slightly larger, bold font. Just a few
examples. It shows the author doesn't understand markup. It is all about
abusing elements because of there appearance in graphical browsers.

That's all fine, but ...

Quote:

If done properly, in a html page the content is structured and marked up
using meaningful elements. This should give the author already a lot of
'handles' to create the appearance of the page, for every element s/he
uses in the body of the page, including the body element itself, can be
used as a selector in a style sheet.

While CSS can do quite a lot, and can even do a lot of things that cannot
be done in just HTML, there remains a few things CSS cannot do. So it is
NOT yet time to say that HTML must be pure content.

Just accept the fact that, as good as it is, CSS still needs work!

Quote:

If some content needs to be treated differently than the standard looks
the author created for the element, it gets a class or maybe an id. If
some content is to be 'physically separated' from the rest of the page,
the author can put it in a containing div and asign a class or id to that
div.

I understand the principle. I've understood this for years, even before
CSS was practical enough to even try to use. The issue is NOT about the
understanding of the principle; the issue is that CSS has been growing
up from a state of being totally unusable (e.g. Netscape 3) to being a
royal PiTA (e.g. Netscape 4) to being now quite viable for _most_ things
(Firefox 1.5). But even still, it's not at 100%.

In many cases CSS forces the HTML (which should just be content and nothing
more) to have extra markup just to support style. For example, styling a
page to have some appearance of a grid structure through the use of float
requires _additional_ DIV elements to be added to the content. That
violates the principle of separation of content and style right there. If
CSS "had it right" then I could put some content in _just_ _one_ DIV element
and then you can put ANY style on it that you want, including hover raised
drop shadow effect that so far requires at least 3 layers of DIV elements in
the content to achieve. And that can confuse someone trying to restyle it
to something else.

Quote:

Once an author understands the concept of markup, why it came about in the
first place, how to use it properly, s/he will no longer feel the need for
tables for layout any longer.

Once you guys understand that CSS does NOT yet do all the things that people
_want_ to do, and _can_ be done with HTML hacks, then we won't see threads
like this and won't have repeated conversations like this.

The drop shadow effect is _better_ done in CSS than with HTML because it
requires lots of "wedges" in the form of extra table cells and transparent
GIF images to accomplish with just HTML. BUT ... it is still NOT RIGHT in
CSS because it _should_ be doable with exactly _one_ DIV element (which can
then be styled as anyone would want).

So ... I'm moving to use CSS for drop shadow effects.

The table grid is NOT _better_ in CSS, yet. There are _two_ reasons for
this. Reason 1 is that the way being promoted now (e.g. float:left) does
not work the same way. That is, not all the same effects are accomplished
with float:left as would be using TABLE/TR/TD. These effects include
syncronized alignment and rigid arrangement. Reason 2 is that, like the
case above for shadows though for different reasons, it still requires the
insertion of extra DIV elements in the content markup (beyond the two layers
that would obviously be needed in any method to distinguish what is to be in
a row and what is to be in a column). And I forgot to count some of the
column and row span features, which float:left can do only in limited ways.

So ... I'm going to stick with certain uses of tables for grid structure.

Please stop with the f*****g annoying "markup and style" religious promotion
and either work towards making CSS better (like maybe a CSS3 that fixes the
issues mentioned), or showing new creative ways to accomplish things that
people have been using HTML hacks for years to do, or just be quiet and take
a seat and watch the events unfold without your influence.

But just STOP ... NOW ... with all the "once authors understand ..." BS.
Get your OWN understanding that CSS just isn't at the 100% level, yet.

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

Quote:

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

#4

On Sun, 30 Apr 2006 18:01:46 +0200, <phil-news-nospam (AT) ipal (DOT) net> wrote:

Quote:

But just STOP ... NOW ... with all the "once authors understand ..." BS.
Get your OWN understanding that CSS just isn't at the 100% level, yet.

If you know all the answers to your own questions, why the heck do you ask.

--
______PretLetters:

Quote:

#5

On Sun, 30 Apr 2006 18:28:57 +0200 Barbara de Zoete <trashbin (AT) pretletters (DOT) net> wrote:

Quote:

On Sun, 30 Apr 2006 18:01:46 +0200, <phil-news-nospam (AT) ipal (DOT) net> wrote:

But just STOP ... NOW ... with all the "once authors understand ..." BS.
Get your OWN understanding that CSS just isn't at the 100% level, yet.

If you know all the answers to your own questions, why the heck do you ask.

The issue of TABLE/TR/TD vs. DIV is not a question of "how do I". Instead,
it is a question of "what should we do". And yes, I do know what I believe
is the correct answer: "fix CSS". Of course that takes a long time. One of
the steps necessary to get the end result is to break through all the denial
the community has.

Understanding the _principles_ of content, markup, style, etc., does _not_
automatically make one know all the methods and means to properly use it,
either. So questions I or anyone else asks of the "how do I" variety do
need to be considered without jumping to the religious answer of "if you
just understand ...". Both CSS and HTML, as well as programming languages,
are made up of a number of discrete pieces of syntax and semantics. They
alone give you nothing. Combining things together gives you something that
if well chosen and well combined can be something great.

Maybe the way _I_ understand things is different than the way _you_ understand
them. But that's common; people are different ... people think in different
ways. You and I both have to live with it. For example, I see certain things
as "definitely" content which you might see as style. I presume we would
agree that background colors are style. But for me that isn't a hard and fast
rule. In some cases background colors are _content_. One example is the red
and black colors of a Chess board. Sure, someone could decide to make a Chess
board of another color and such things exist. But these are the traditional
colors people recognize as such. So if I am going to lay out a grid structure
as a Chess board, you can bet I'm going to set the colors in the HTML tags.

And I'm not going to use "float:left" to layout a Chess board, either.

There are other cases where TABLE/TR/TD still beats DIV (and float) to make
a grid structure as desired. I'd rather do it with DIV, but it just isn't
capable, yet, for all that needs to be done. TABLE/TR/TD still works better
for certain things. It seems most everyone agrees tabular data is to be
done that way. But a lot of other things that wouldn't really be called
tabular data still need the same grid structure semantics/effects, which is
not possible with DIV and float (again I say "yet" because I see the potential
to fix this).

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

Quote:

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

#6

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

Quote:

rule. In some cases background colors are _content_. One example
is the red and black colors of a Chess board. Sure, someone could
decide to make a Chess board of another color and such things exist.
But these are the traditional colors people recognize as such. So

Odd, most of the (real) chessboards I've seen are yellow and
black. Maybe it varies from place to place.

Quote:

if I am going to lay out a grid structure as a Chess board, you can
bet I'm going to set the colors in the HTML tags.

I can't imagine a situation where HTML-based colour setting would be
more reliable than CSS-based colour setting in such a situation, with
modern browsers at least - every graphical browser I know with an
"ignore CSS" option also has some form of "ignore colours" option. If
the colour is truly part of the content then perhaps an image (with
suitable text alternative) is the better way to provide the
information?

Quote:

And I'm not going to use "float:left" to layout a Chess board, either.

I'd have thought a chess board was certainly tabular data.

Quote:

There are other cases where TABLE/TR/TD still beats DIV (and float)
to make a grid structure as desired. I'd rather do it with DIV, but
it just isn't capable, yet, for all that needs to be done.
TABLE/TR/TD still works better for certain things. It seems most
everyone agrees tabular data is to be done that way. But a lot of
other things that wouldn't really be called tabular data still need
the same grid structure semantics/effects, which is not possible
with DIV and float (again I say "yet" because I see the potential to
fix this).

Does IE7 support 'position: table-*'? That gives much the same layout
options but doesn't interfere with table-reading mode so much. (Of
course, even if it does, it'll be a couple of years before it's
generally usable)

--
Chris

#7

On 30 Apr 2006 19:26:38 +0100 Chris Morris <c.i.morris (AT) durham (DOT) ac.uk> wrote:

Quote:

phil-news-nospam (AT) ipal (DOT) net writes:
rule. In some cases background colors are _content_. One example
is the red and black colors of a Chess board. Sure, someone could
decide to make a Chess board of another color and such things exist.
But these are the traditional colors people recognize as such. So

Odd, most of the (real) chessboards I've seen are yellow and
black. Maybe it varies from place to place.

I've seen a couple like that. But virtually all are red and black.

Quote:

if I am going to lay out a grid structure as a Chess board, you can
bet I'm going to set the colors in the HTML tags.

I can't imagine a situation where HTML-based colour setting would be
more reliable than CSS-based colour setting in such a situation, with
modern browsers at least - every graphical browser I know with an
"ignore CSS" option also has some form of "ignore colours" option. If
the colour is truly part of the content then perhaps an image (with
suitable text alternative) is the better way to provide the
information?

So how should the image be done? Don't forget it will be background.
There may be an image and/or text placed over it.

Quote:

And I'm not going to use "float:left" to layout a Chess board, either.

I'd have thought a chess board was certainly tabular data.

It probably comes down to what people see as tabular and not tabular.
When I want to align a set of boxes to hold blocks of text, such as
news items, I tend to want the behaviour TABLE/TR/TD bring, rather
than the behaviour I get with DIV+float.

Quote:

There are other cases where TABLE/TR/TD still beats DIV (and float)
to make a grid structure as desired. I'd rather do it with DIV, but
it just isn't capable, yet, for all that needs to be done.
TABLE/TR/TD still works better for certain things. It seems most
everyone agrees tabular data is to be done that way. But a lot of
other things that wouldn't really be called tabular data still need
the same grid structure semantics/effects, which is not possible
with DIV and float (again I say "yet" because I see the potential to
fix this).

Does IE7 support 'position: table-*'? That gives much the same layout
options but doesn't interfere with table-reading mode so much. (Of
course, even if it does, it'll be a couple of years before it's
generally usable)

I have no idea. No IE running here of any version right now.

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

Quote:

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

#8

On Sun, 30 Apr 2006 20:12:33 +0200 Johannes Koch <koch (AT) w3development (DOT) de> wrote:

Quote:

phil-news-nospam (AT) ipal (DOT) net wrote:
While CSS can do quite a lot, and can even do a lot of things that cannot
be done in just HTML, there remains a few things CSS cannot do. So it is
NOT yet time to say that HTML must be pure content.

Just accept the fact that, as good as it is, CSS still needs work!

Are you sure, you mean "CSS still needs work"? Not "CSS implementations
need work"? WRT presentation of HTML tables (what I suspect you call
grid), there is really a little stuff (rowspan/colspan) which cannot be
done with CSS.

Show me CSS2 coding that will produce tables with the same semantics that
TABLE/TR/TD has, and maybe I could believe it's an implementatuon issue.

For another issue with CSS, take a block of text in a _single_ DIV element
and using CSS only, style that block so it appears with a drop shadow effect
without changing the HTML at all. I had to add extra DIV elements to get it
to work, and found that a couple other people doing the same thing did it
the same way (though I went a step further and added yet another DIV to make
an effect that raised and lowered the shadow effect based on hover). Better
CSS would allow doing anything like that wihtout changing HTML at all. If
the style needs more container context, then CSS should be able to logically
include that.

Here's one of the pages I was experimenting with:
http://phil.ipal.org/usenet/ciwas/20...in-tables.html
Be careful with the top right and bottom left corners as they can result in
the raising/lowering effect oscillating if you position the pointer on the
pixels that move away.

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

Quote:

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

#9

<phil-news-nospam (AT) ipal (DOT) net> kirjoitti
viestissä:e33or8111ca (AT) news1 (DOT) newsguy.com...

<snip>

Quote:

For another issue with CSS, take a block of text in a _single_ DIV element
and using CSS only, style that block so it appears with a drop shadow
effect
without changing the HTML at all.

http://www.kolumbus.fi/ace/ng/box.html

Div with heading and paragraph of text inside. If you add more paragraphs it
needs tweaking though.

#10

On Mon, 1 May 2006 05:59:50 +0300 "W?rm" <nomailstodragon (AT) north (DOT) invalid> wrote:

Quote:

phil-news-nospam (AT) ipal (DOT) net> kirjoitti
viestiss?:e33or8111ca (AT) news1 (DOT) newsguy.com...

snip

For another issue with CSS, take a block of text in a _single_ DIV element
and using CSS only, style that block so it appears with a drop shadow
effect
without changing the HTML at all.

http://www.kolumbus.fi/ace/ng/box.html

Div with heading and paragraph of text inside. If you add more paragraphs it
needs tweaking though.

OK, different elements. Usable in the case of just needing those two.
Or maybe just any two. But my point is it's still two elements being
selected for in CSS. One should be able to do it all for one single
element since many other styles can be done that way.

Here's how I think it could be done in CSS. Some purists might whine
that it is, in effect, adding markup in CSS. First, you'd have a property
that specifies a number of virtual containers:

/* WARNING to stray readers - the following is NOT valid CSS */

..mybox {
virtual-containers: 2;
}

/* Then you'd configure them separately as needed: */

..mybox [0] {
background-color: #cccccc;
color: #000000;
margin-bottom: 10px;
}

..mybox [1] {
background-color: #ffffff;
color: inherit;
border: 0;
position: relative;
top: -4px;
left: -4px;
margin: 0;
padding: 0;
}

Then what's inside could be configured any way desired without even any
concern for the fact that it's in something that is being styled with a
drop shadow. The border could be added by the interior elements, if one
is desired, or this can be changed to add one here.

The idea is the markup does not need to be changed just to make a more
complex style. An implemention _may_ actually accomplish it my adding
extra markup in its DOM structure (whatever they prefer as programmers).

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

Quote:

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