CSS vs Tables for reports

[Derek Clarkson]

Hi all,
I've found CSS much better for doing page layouts than using tables. Less
messy. But I was wondering if anyone has used it for doing reports where
you have set columns. I figure it's doable, but I can't see how to specify
a column to adjust it's width to the contents the way a table does.

Any procs and cons ?

 

[William Tasso]

Hi all,
I've found CSS much better for doing page layouts than using
tables. Less messy. But I was wondering if anyone has used it for
doing reports where you have set columns. I figure it's doable, but I
can't see how to specify a column to adjust it's width to the
contents the way a table does.

Any procs and cons ?

You have a table of data to present - use relevant markup.

 

[news frontiernet.net]

How many days do you put ito trying to use CSS to do one hours worth of
table work?

How do you trial-and-error test your ideas and variations on them? This is
simple to do with adjusting table columnn widths and such in various
editors. But there are no such aids to making minor adjustments to layout
using CSS. In the case of column width changes, you would need to
individually alter each and every column in CSS , rather than the simple
process of using and ALT key while you are dragging a column border in
software like FrontPage.

Althought I have seen the new FrontPage . . I have read about it and it does
not seem to be aiding the replacement of tables much. I doubt that other
HTML authoring software is making the use of CSS for layout control as easy
as the use of tables.

Furthermore, there too many ERRORs in various browsers in the CSS rendering
of positionally controled items that arnt there when one uses tables. The
troubleshooting of tables is easy. The troubleshooting of CSS positioning is
complex, tedious, and time consuming.

Yuk!

I'll keep tables.

 

[Leif K-Brooks]

How many days do you put ito trying to use CSS to do one hours worth of
table work?

It takes me five minutes to make a decent-looking CSS layout. The same
layout would take at least 30 minutes abusing tables.

How do you trial-and-error test your ideas and variations on them? This is
simple to do with adjusting table columnn widths and such in various
editors. But there are no such aids to making minor adjustments to layout
using CSS. In the case of column width changes, you would need to
individually alter each and every column in CSS , rather than the simple
process of using and ALT key while you are dragging a column border in
software like FrontPage.

You're comparing apples to oranges, hand-coding versus using a so-called
WYSIWYG.

Althought I have seen the new FrontPage . . I have read about it and it does
not seem to be aiding the replacement of tables much. I doubt that other
HTML authoring software is making the use of CSS for layout control as easy
as the use of tables.

Learn to use HTML and CSS on your own. WYSIWYGs just make your job harder.

Furthermore, there too many ERRORs in various browsers in the CSS rendering
of positionally controled items that arnt there when one uses tables. The
troubleshooting of tables is easy. The troubleshooting of CSS positioning is
complex, tedious, and time consuming.

Which of these looks easier to maintain to you?

Using CSS:
#sidebar {
width : 14%;
background : #CCC;
color : black;
position : absolute;
left : 0;
top : 0;
}
#content {
margin-left : 14%;
padding-left : 1em;
}
<div id="sidebar">sidebar</div>
<div id="content">content</div>

Abusing tables:
<table border="0" cellspacing="0" cellpadding="0">
<tr>
<td bgcolor="#CCCCCC" width="14%">sidebar</td>
<td>&nbsp;</td>
<td>content</td>
</tr>
</table>

 

[Adrienne]

Gazing into my crystal ball I observed "news frontiernet.net"
<[email protected]> writing in

Please don't top post.

How many days do you put ito trying to use CSS to do one hours worth of
table work?

In the case where you have a tabular data, you would use tables, that's
what they are for. Tables and their elements can also be styled. For
example, if you wanted all your tables to have the TH element blue
background with white foreground, it is a simple matter of stating such in
an external style sheet, as opposed to doing that markup in each table.
That makes a big difference when you have multiple tables across a site,
and the site owner decides later they want white background with navy text.

How do you trial-and-error test your ideas and variations on them?
This is simple to do with adjusting table columnn widths and such in
various editors. But there are no such aids to making minor adjustments
to layout using CSS. In the case of column width changes, you would
need to individually alter each and every column in CSS , rather than
the simple process of using and ALT key while you are dragging a column
border in software like FrontPage.

One can always use http://www.bradsoft.com/top-style , which does have a
good visual editing. The problem with using FrontPage or other WYSIWYG
editors is they put attributes in each TD element, rather than use COLGROUP
and COL elements.

<table summary="Product List">
<colgroup span="3">
<col span="2" width="40%">
<col span="1" width="20%">
</colgroup>
<tr>...

Althought I have seen the new FrontPage . . I have read about it and it
does not seem to be aiding the replacement of tables much. I doubt that
other HTML authoring software is making the use of CSS for layout
control as easy as the use of tables.

That's one of the problems of letting software do you work for you. You
don't have control. Tables are for tabular data, not for presentation, and
perhaps software manufacturers are too lazy to program as such. When
authors demand CSS for presentation, WYSIWYG programs will implement it.

Furthermore, there too many ERRORs in various browsers in the CSS
rendering of positionally controled items that arnt there when one uses
tables. The troubleshooting of tables is easy. The troubleshooting of
CSS positioning is complex, tedious, and time consuming.

Have you even had to edit pages that have nested tables for presentation?
Recently I've been working on a site that had tables nested four levels
deep. It's a real PITA to have to debug those things.

Yuk!

I'll keep tables.

I'll keep CSS and use tables for what they were intended for, tabular data.

 

[rf]

How many days do you put ito trying to use CSS to do one hours worth of
table work?

How do you trial-and-error test your ideas and variations on them? This is
simple to do with adjusting table columnn widths and such in various
editors. But there are no such aids to making minor adjustments to layout
using CSS. In the case of column width changes, you would need to
individually alter each and every column in CSS , rather than the simple
process of using and ALT key while you are dragging a column border in
software like FrontPage.

Akk. Dragging table borders around using frontpage sets their size in pixles
IIRC. This is hardly condusive to liquid design, expecially if you are
talking about printing. You have no idea how many "pixels" wide the paper
is. Yes, I know, it appears to be extrapolated from about 800 but you just
can't tell.

This 'ease of use' feature is what makes things like frontpage able to spew
out very bad HTML with a simple mouse click.

Althought I have seen the new FrontPage

I'll bet it's worse then its predecessor

. . I have read about it and it does
not seem to be aiding the replacement of tables much. I doubt that other
HTML authoring software is making the use of CSS for layout control as easy
as the use of tables.

One of the reasons CSS layout is easier than the use of tables is that you
no longer have to worry about layout. The browser does it for you. All you
have to consider are such things as "I want this vertical nav bar at the
left of the canvas and I want it 12 ems wide". Here is the CSS:

ul.nav {float: left; width: 12em;}

Much simpler than fiddling around with table cells and trying to second
guess the viewers canvas size.

Plus that single line affects every nav ul in the entire site. Try changing
a few hundred table based pages using your drag/drop method and get them all
the same.

Furthermore, there too many ERRORs in various browsers in the CSS rendering
of positionally controled items that arnt there when one uses tables.

Once again there is this fixation on "positionally controlled". Avoid any
sort of "control" and let the browser do it. All of the visual browsers from
release 4 onwards support enough CSS to get the job done. (well maybe not
Netscape 4.x but who cares?). Any really tricky things, like making all the

The
troubleshooting of tables is easy.

No, it is not. It is a pain in the arse when used for layout Leave out
one </tr> and the whole table screws up, and spectaularly different on
different browsers as their different error correction kicks in.

When using tables for their intended use, tabular data, it *is* easy because
there are no layout considerations. It's a table, what else does it need to
do?

The troubleshooting of CSS positioning is
complex, tedious, and time consuming.

No it is not. There is no 'troubleshooting' because there is usually no
trouble. Leave out one <div> and only that little bit screws up and it's
obvious where the problem lies. I can build and fine-tune a page without
tables in a tenth of the time compared to one that uses tables.

Cheers
Richard.

 

[Derek Clarkson]

Thanks for your replies everyone. I seem to have provoked a small war
without intending to ;-)

Having read your posts:

1. I'll keep using tables for reports where data in columns is required.
It's easy to apply CSS to handle the LaF of a table and just use the basic
table tags. The only real issue I had with attempting to do it in CSS was
that I didn't want to specify the width of the columns because I did not
know the width of the data I was going to present. So leaving the data in a
table and using CSS to "pretty" it up makes sense.

2. I'm currently using Quanta (linux) as it supports the tools I require and
allows me to write tight code. Like some of you my experiences with WYSIWYG
tools such as Frontpage is that they tend to limit how you do things and
produce a lot of un-necessary code. Being a programmer by profession I
prefer to write the code myself, it might be slower, but I have complete
control. I have found over the years that like programming, people who
start with WYSIWYG editors and rarely if ever touch raw code, tend to have
little understanding of the issues at that level and as a result, don't
produce well designed documents. Their stuff might work, but it tends to
have problems because of bloat and code added by the editors which is
clumsy or not quite what the author needs. I'm sure there are a number of
you who by now are itching to flame me for these comments, but even I'm
allowed an opinion. ;-)


cio
Derek

 

[Warren Oates]

:Which of these looks easier to maintain to you?
:
:Using CSS:
:#sidebar {
: width : 14%;
: background : #CCC;
: color : black;
: position : absolute;
: left : 0;
: top

You'll have to

body { margin: 0; padding: 0; }

so that position looks the same on all browsers. Put everyone on the
same page, so to speak.

 

[news frontiernet.net]

I would really like to use the new CSS for layout.

But, the only times I have tried it have resulted in it not working
corss-browser unless I find someone to craft some JS script to make up for
MS browse not handling positioning right when one tries to center a div to
make sure that the material is in the center of the scren for 800x600,
1024x7678 and all larger resolutions.

The use of tables and <center> was soooooo much easier, sooo much less times
consuming, and reliably cross-browser.

I have one CSS layout with CSS result that does work . . but the job should
have taken me a few hours but ended up in weeks of newsgroup discussions to
figure out why the valid CSS didnt layout right cross-browser.

So, I got burned on trying to use CSS.

I also, do lots of visual trial-and-error work with layout using toold like
FrontPage so visually see what I think will look good. But it nearly alwasy
need to be tweeked. Tweeking tables is simple dimple in WSYWIG. Tweeking CSS
requires code level work, then visualization . . more time.

I am moving more of my other coding to CSS based controls. On each update or
rewrite, I do introduce CSS to do work that used to be done with older tags.

But, untill I can see this stuff works better cross-broswer, I am going to
continue to use the tools in FrontPage to create tables to do even simple
things like quickly set up a section of text that will be horizontally in
the middle of the page. They are quick, reliable and 100% cross-broswer.

Thank you for the pep talk tho. I do periodically try new stuff.

 

[Michael Weber]

[Wed, 12 Nov 2003 03:37:57 GMT/news frontiernet.net]

I would really like to use the new CSS for layout.

But, the only times I have tried it have resulted in it not working
corss-browser unless I find someone to craft some JS script to make up for
MS browse not handling positioning right when one tries to center a div to
make sure that the material is in the center of the scren for 800x600,
1024x7678 and all larger resolutions.

The use of tables and <center> was soooooo much easier, sooo much less times
consuming, and reliably cross-browser.

So then go on using it. As long as popular browsers do support it.

I also, do lots of visual trial-and-error work with layout using toold like
FrontPage so visually see what I think will look good. But it nearly alwasy
need to be tweeked. Tweeking tables is simple dimple in WSYWIG. Tweeking CSS
requires code level work, then visualization . . more time.

Most css-layouts do have issues, when they are made in css only
while trying to act as a table. Whether they are fixed or ugly.

But, untill I can see this stuff works better cross-broswer, I am going to
continue to use the tools in FrontPage to create tables to do even simple
things like quickly set up a section of text that will be horizontally in
the middle of the page. They are quick, reliable and 100% cross-broswer.

Kick off FrontPage and make your tables by hand. Less code, more
control.

Thank you for the pep talk tho. I do periodically try new stuff.

Think about css-based layouts when css3 comes out or IE7 shows up.
Untill then it's not worth the time to try. The more you try, the
more often you will hear "rethink your design!" to meet today's
css-cross-probs. Don't let tell you, you were a wannabe if you
_not_ using css for layout. This is state-of-the-art bullshit and
will often be followed by just a "rethink your layout"...


regs
michael

 

[Matthias Gutfeldt]

Think about css-based layouts when css3 comes out or IE7 shows up.
Untill then it's not worth the time to try. The more you try, the
more often you will hear "rethink your design!" to meet today's
css-cross-probs. Don't let tell you, you were a wannabe if you
_not_ using css for layout. This is state-of-the-art bullshit and
will often be followed by just a "rethink your layout"...

How much experience do you really have with CSS layouts?


Matthias

 

[Michael Weber]

[Wed, 12 Nov 2003 16:52:02 +0100/Matthias Gutfeldt]

How much experience do you really have with CSS layouts?

2 years and enough to know, that a 3 colum nonfixed table with 100%
header & footer in css trashy is.


regs
michael

 

[Barry Pearson]

Thanks for your replies everyone. I seem to have provoked a small war
without intending to ;-)

[snip]

Much of this is a holy war. Positions get polarised, variations within either
side get minimised, consequences eitherway are carefully selected, then
exaggerated.

One problem is that people don't compare like with like. They will compare the
code produced by someone who barely understands HTML with that produced by an
expert in both CSS & HTML. Or years-old code with modern code. These are not
useful comparisons, because no-one is making the choice between using
"tableless layout & CSS versus table-layout & HTML3.2 & no-CSS". The
differences in such a case are not primarily caused by the method, they are
nearly all caused by the skill-level.

When you control the "author skill" and "development date", using
tableless-layout & table-layout are relatively little different compared with
most of the content. They can both be accessible, flexible, efficient,
supported across a target-range of browsers, viewable on 240-pixel screens,
etc. I suspect an expert in tableless layout could develop a page using a
simple table for layout which would be much better in almost all respects than
a tableless-layout page developed by an non-expert.

About a third of my pages don't use tables for page-layout. The experience
made me realise just how immature the support for it is. Even though they were
simple pages, I needed help (from the web & Usenet) overcoming various browser
deficiences.

 

[Barry Pearson]

[Wed, 12 Nov 2003 03:37:57 GMT/news frontiernet.net] [snip]

The use of tables and <center> was soooooo much easier, sooo much
less times consuming, and reliably cross-browser.

So then go on using it. As long as popular browsers do support it.

[snip]

Popular browsers will support it for a decade or two. A high proportion of the
pages on the web use table-layout, with perhaps 100,000 or more of them being
published each day. (News articles published by 1000s of news sites, for
example). So UAs for general use, rather than use for a narrow range of
material, simply have to continue to support it. After all, it is still
possible to use table-layout in validated XHTML 1.1. It isn't even deprecated
(unlike, say, "underline"!) Non-visual UAs can navigate around it (in spite of
what some claim), it can be displayed by at least one UA on a 240-pixel
screen, and support will continue to improve.

I believe the main turning point will be when authoring tools used by
non-experts make it easier to develop tableless-layout than table-layout
pages. Surely there are now enough experts in tableless-development to help
build such tools, and so enable others to exploit their expertise in a very
effective way - invisibly?

 

[Isofarro]

After all, it is
still possible to use table-layout in validated XHTML 1.1. It isn't even
deprecated (unlike, say, "underline"!)

Ahhh... the usual Barry Pearson bullshit. Where's your reference to the W3C
HTML specification that says tables are to be used for page layout? Surely
for HTML to be deprecated it actually has to _appear_ in an HTML
specification.

Now the table element is specified in the HTML specification, and it has a
use for structuring tabular data. There is no point deprecating the table
element, since its intended use as describing the structure of tabular data
is still valid.

 

[Matthias Gutfeldt]

in validated XHTML 1.1. It isn't even deprecated
(unlike, say, "underline"!)

Where's your reference to the W3C
HTML specification that says tables are to be used for page layout? Surely
for HTML to be deprecated it actually has to _appear_ in an HTML
specification.

The point here is "validated XHTML 1.1". Tables are valid in XHTML1.1 .
Whether they're used for tabular data, layout, or a replication of an
impressionist painting, is irrelevant for validation.

And XHTML1.1. is not HTML. The XHTML 1.1 Specification doesn't say
anything about the use of tables. The HTML 4.01 does say something about
table layouts, but it's not as clear as one would like it to be.

Personally I think it would be better to use HTML4.01 Transitional for
table layouts, since it has less restrictions than XHTML1.1.

Now the table element is specified in the HTML specification, and it has a
use for structuring tabular data. There is no point deprecating the table
element, since its intended use as describing the structure of tabular data
is still valid.

I don't think Barry was arguing for deprecating tables, either.


Matthias