CSS vs Tables for reports

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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 ?


Re: CSS vs Tables for reports

Derek Clarkson wrote:
Quoted text here. Click to load it

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

William Tasso - http://WilliamTasso.com

Re: CSS vs Tables for reports

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.


I'll keep tables.
Quoted text here. Click to load it

Re: CSS vs Tables for reports

news frontiernet.net wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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">
<td bgcolor="#CCCCCC" width="14%">sidebar</td>

Re: CSS vs Tables for reports

: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.
Looks like more of Texas to me.
... Arizona, where the nights are warm and the roads are straight.

Re: CSS vs Tables for reports

Gazing into my crystal ball I observed "news frontiernet.net"

Please don't top post.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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%">

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

I'll keep CSS and use tables for what they were intended for, tabular data.
Adrienne Boswell
Please respond to the group so others can share

Re: CSS vs Tables for reports

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

I'll bet it's worse then its predecessor :-)

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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
above navbar <a> elements the same width so they look like buttons can be
safely hidden from the CSS-challenged browsers.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


Re: CSS vs Tables for reports

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


Re: CSS vs Tables for reports

Derek Clarkson wrote:
Quoted text here. Click to load it

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

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

Barry Pearson
http://www.Barry.Pearson.name/photography /
http://www.BirdsAndAnimals.info /
http://www.ChildSupportAnalysis.co.uk /

Re: CSS vs Tables for reports

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.

Quoted text here. Click to load it
tables. Less

Re: CSS vs Tables for reports

[Wed, 12 Nov 2003 03:37:57 GMT/news frontiernet.net]
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Re: CSS vs Tables for reports

Michael Weber wrote:
Quoted text here. Click to load it

How much experience do you really have with CSS layouts?


Re: CSS vs Tables for reports

[Wed, 12 Nov 2003 16:52:02 +0100/Matthias Gutfeldt]
Quoted text here. Click to load it

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


Re: CSS vs Tables for reports

Michael Weber wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it

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?

Barry Pearson
http://www.Barry.Pearson.name/photography /
http://www.BirdsAndAnimals.info /
http://www.ChildSupportAnalysis.co.uk /

Re: CSS vs Tables for reports

Barry Pearson wrote:

Quoted text here. Click to load it

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

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.

FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com /
Recommended Hosting: http://www.affordablehost.com /
Web Design Tutorial: http://www.sitepoint.com/article/1010

Re: CSS vs Tables for reports

Isofarro schrieb:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Site Timeline