CSS vs Tables for reports

Discussion in 'HTML' started by Derek Clarkson, Nov 11, 2003.

  1. 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 ?


    --
    cio
    Derek
     
    Derek Clarkson, Nov 11, 2003
    #1
    1. Advertising

  2. Derek Clarkson wrote:
    > 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.

    --
    William Tasso - http://WilliamTasso.com
     
    William Tasso, Nov 11, 2003
    #2
    1. Advertising

  3. 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.
    "William Tasso" <> wrote in message
    news:bop9tk$1g77in$-berlin.de...
    > Derek Clarkson wrote:
    > > 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.
    >
    > --
    > William Tasso - http://WilliamTasso.com
    >
    >
     
    news frontiernet.net, Nov 11, 2003
    #3
  4. news frontiernet.net wrote:

    > 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>
     
    Leif K-Brooks, Nov 11, 2003
    #4
  5. Derek Clarkson

    Adrienne Guest

    Gazing into my crystal ball I observed "news frontiernet.net"
    <> writing in
    news:6_Wrb.5614$:

    Please don't top post.

    > "William Tasso" <> wrote in message
    > news:bop9tk$1g77in$-berlin.de...
    >> Derek Clarkson wrote:
    >> > 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.
    >>

    > 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.
    --
    Adrienne Boswell
    Please respond to the group so others can share
    http://www.arbpen.com
     
    Adrienne, Nov 11, 2003
    #5
  6. Derek Clarkson

    rf Guest

    "news frontiernet.net" <> wrote in message
    news:6_Wrb.5614$...
    > 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
    above navbar <a> elements the same width so they look like buttons can be
    safely hidden from the CSS-challenged browsers.

    > 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.
     
    rf, Nov 11, 2003
    #6
  7. 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
     
    Derek Clarkson, Nov 11, 2003
    #7
  8. Derek Clarkson

    Warren Oates Guest

    In article <KiXrb.567$>,
    Leif K-Brooks <> wrote:

    :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.
     
    Warren Oates, Nov 11, 2003
    #8
  9. 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.

    "Derek Clarkson" <> wrote in message
    news:...
    > 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 ?
    >
    >
    > --
    > cio
    > Derek
     
    news frontiernet.net, Nov 12, 2003
    #9
  10. [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
     
    Michael Weber, Nov 12, 2003
    #10
  11. Michael Weber wrote:
    > 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
     
    Matthias Gutfeldt, Nov 12, 2003
    #11
  12. [Wed, 12 Nov 2003 16:52:02 +0100/Matthias Gutfeldt]
    > Michael Weber wrote:
    > > 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?


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


    regs
    michael
     
    Michael Weber, Nov 12, 2003
    #12
  13. Derek Clarkson wrote:
    > 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
    http://www.Barry.Pearson.name/photography/
    http://www.BirdsAndAnimals.info/
    http://www.ChildSupportAnalysis.co.uk/
     
    Barry Pearson, Nov 15, 2003
    #13
  14. Michael Weber wrote:
    > [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?

    --
    Barry Pearson
    http://www.Barry.Pearson.name/photography/
    http://www.BirdsAndAnimals.info/
    http://www.ChildSupportAnalysis.co.uk/
     
    Barry Pearson, Nov 15, 2003
    #14
  15. Derek Clarkson

    Isofarro Guest

    Barry Pearson wrote:

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



    --
    Iso.
    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
     
    Isofarro, Nov 15, 2003
    #15
  16. Isofarro schrieb:
    >
    > Barry Pearson wrote:
    >
    > > After all, it is still possible to use table-layout

    > 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
     
    Matthias Gutfeldt, Nov 15, 2003
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Barnes
    Replies:
    1
    Views:
    584
    J Jones
    Feb 18, 2004
  2. Peri
    Replies:
    1
    Views:
    3,005
    =?Utf-8?B?Um90aGFyaWdlcg==?=
    Jul 21, 2005
  3. Replies:
    2
    Views:
    908
  4. Rod
    Replies:
    2
    Views:
    1,811
  5. Replies:
    0
    Views:
    511
Loading...

Share This Page