homepage Welcome to WebmasterWorld Guest from 54.161.214.221
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 155 message thread spans 6 pages: 155 ( [1] 2 3 4 5 6 > >     
Tables - What is so bad about them again?
SirTalksalot




msg:3704281
 9:49 am on Jul 22, 2008 (gmt 0)

Hi all,

I've had it driven into me for so long now that 'tables are for displaying data', and not to be used to format your page any more, and the way forward is forever CSS.

I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables. The text is still readble on a page, the links still work, what's the big deal?

In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?

 

janharders




msg:3704288
 10:00 am on Jul 22, 2008 (gmt 0)

depends on who you ask.
with css, it's easy to change layout on your page once you have everything set up. check out [csszengarden.com...] to see how different the same page can look just by changing the css.

plus: once you get used to it, it'll be much easier than it seems now.
another pro-css: tables only get rendered when they're completely loaded. If you have some script on your page that does a search for example, the page will not display until the script has completed it's search. With css, your header could show instantly with a "please wait a second"-note where the content would be and once the results are in, they'll replace the "wait a second"-note. without javascript, without redirects etc pp.
another point for css-designs is accessibility. your source code is structured by feature, not by design. you can put your navigation to the top or at the bottom, just as you see fit, you're actually free to do things you can't achieve with tables.

and finally: the semantic-nazis won't bother you on forums ;)

piatkow




msg:3704299
 10:37 am on Jul 22, 2008 (gmt 0)

I imagine that css would become easier with a bit of study but like the OP I have found using it for positioning content an absolute pain. I have adopted it for basic styling but really can't face reworking the templates that I built for my site many years ago using tables. They aren't broken (nor come to that are the font tags on the older pages) so there are better things to do than fix them.

icedowl




msg:3724119
 9:34 pm on Aug 15, 2008 (gmt 0)

I'm still on the learning curve with CSS, but I'm finding it to be much easier to code my pages using it. Another benefit I'm seeing is greatly reduced page size (20k down to 5k for example) which renders the page considerably faster. I still have the occasional need to toss in a table to display some data that I haven't found any other way to do and have it look the way I want it to look.

csuguy




msg:3724211
 1:37 am on Aug 16, 2008 (gmt 0)

There is nothing wrong with using tables except the semantics for it. But - if your like me - then the whole semantics argument surmounts to nothing. I follow standards up to the point that they begin to make my life more difficult as a web designer. If a table would be a more efficient way of laying out a particular design - I use it.

I've found using a table for the basic layout and then using divs to fill it in to be the best approach. It's a matter of combining the strict structure of html with he loose nature of css.

I've found very few arguments against tables amount to anything realistically. File size and page rendering - providing the user isn't on dialup - really doesn't matter as the user sees little to no difference. Also - the first page takes longer to load when all of the information is in the css file. Many consider this to be the most important page. If they are using dial-up chances are that they run an older computer which wouldn't handle css that well anyway.

For search engines - what matters MOST is that you have other relevant sites linking to you. Besides - Google and other search engines have been documenting table based sites for a LONG time. I think they are pretty good at handling table based sites by now.

As for accessibility - unless you are creating a site that is explicitly for the visually impared - or at least needs to be made accessible to them - I find it unessecary to spend the time - and thus money - to make it accessible to a demographic that is irrelevant to my site. If you do need to make it accessible - tables can be made to degrade just as well as divs. It might take a little more work - but not really, providing you write clean code and don't go crazy with nesting.

csuguy




msg:3724212
 1:40 am on Aug 16, 2008 (gmt 0)

OH - and tables are more reliable cross-browser and cross-version!

alt131




msg:3724277
 4:52 am on Aug 16, 2008 (gmt 0)

... simply using tables. The text is still readble on a page, the links still work, what's the big deal?

It works for you. In your office, on your computer, in your user agent (browser ?).

The "big deal" for me, is that using style rules to style pages designed in semantic HTML (my preference) means one set of code can accommodate a much wider range of user agents and their users. "Write once use many" :)

That means no time (money) wasted coding separate pages to accommodate different user agents, no sales (money) lost because pages on a retail site took too long to download on dial-up, no fines (money) or penalties (money) paid after lengthy litigation (money) over failures to meet usability and accessibility legal obligations.

Plus there is the satisfaction of using the right tool for the right job.

Marshall




msg:3724297
 6:32 am on Aug 16, 2008 (gmt 0)

over failures to meet usability and accessibility legal obligations.

This, IMHO, this is a grey area.

If you look at sites that are required to meet 508 accessibility standards, you will find tables. I cite as examples irs.gov, copyright.gov, and best of all, section508.gov. They all use tables.

All standards aside, tables still provide the best, and easiest, cross-browser compatibility than any other layout configuration. While my opinion may start an argument here, I cite WebmasterWorld. Look at how many questions are posted regarding problems with CSS/<div> and cross-browser compatibility versus questions for the same with tables.

I am no way promoting one method over another, or passing judgement on any one's preference, I am just pointing out facts.

In the end I think we can all agree to disagree.

Marshall

SteveWh




msg:3724329
 8:23 am on Aug 16, 2008 (gmt 0)

Is this really such a crime?

IMO, no crime at all. Use tables with no guilt if they achieve what you want. Abandoning tables for CSS because that's the current fad is as pointless as abandoning HTML for XHTML when HTML was rendering your pages properly in the first place.

csuguy




msg:3724330
 8:27 am on Aug 16, 2008 (gmt 0)

HAHA - I'm adding Section508.gov to my favs :D

alt131




msg:3724369
 10:50 am on Aug 16, 2008 (gmt 0)

If you look at sites that are required to meet 508 accessibility standards, you will find tables. I cite as examples irs.gov, copyright.gov, and best of all, section508.gov. They all use tables.

Thanks Marshall - the irony always brings a smile to my face. You might add tag soup as well - even if they do linearise. And no arguments here - my angst ran out during the "version4 browser wars".

Just a thought - forum members aren't always in nations to which 508 applies.

csuguy




msg:3724375
 11:06 am on Aug 16, 2008 (gmt 0)

Then you have to apply to the rules in your own nation. Does yours explicitly ban tables even if they gracefully degrade?

Marshall




msg:3724376
 11:13 am on Aug 16, 2008 (gmt 0)

forum members aren't always in nations to which 508 applies.

True, but since Section 508 was brought up, I too thought their use of tables was ironic and/or made a point, that being: just because a layout uses tables does not make it inaccessible.

I also find it ironic that, in another post, csuguy makes note of a screen reader which I believe is from the UK and it too uses tables for the layout. Draw your own conclusions.

Bottle line - if it is done right, anything works and is acceptable. The problems stems from poor layout, meaning following a sensible structure, and poor coding. That, can apply to any layout format.

Marshall

alt131




msg:3724393
 12:50 pm on Aug 16, 2008 (gmt 0)

bottle line ... is that a suggestion to reach for a cool beer before this debategets impassioned? (Count me in for a beer)

The problems stems from poor layout, meaning following a sensible structure, and poor coding. That, can apply to any layout format.

Hear, hear.
Although another argument is that using tables automatically results in poor structure because of the incorrect semantics.

I've never thought the "look at them" (eg section508.org) argument to be the strongest case to be made in support of tables. As you say, using tables is not the same as authoring "good" code - yet that "common interest" often gets ignored.

alt131




msg:3724407
 1:34 pm on Aug 16, 2008 (gmt 0)

Then you have to apply to the rules in your own nation. Does yours explicitly ban tables even if they gracefully degrade?

No - as would be expected. The ability to degrade gracefully does not automatically mean a table is accessible and usable after it has degraded (or before it degrades, for that matter), so degradation (graceful or otherwise) isn't used to measure accessibility or usability.

csuguy




msg:3724462
 2:24 pm on Aug 16, 2008 (gmt 0)


I've never thought the "look at them" (eg section508.org) argument to be the strongest case to be made in support of tables. As you say, using tables is not the same as authoring "good" code - yet that "common interest" often gets ignored.

The 'look at' argument's validity is based upon exactly who you are looking at - obviously. I'm not a strong believer in it either - however this is one of the few examples which I say would have weight to it. It shows that tables can be made accessible - and thus the accessibility argument falls apart. Its just a matter of good - though unsemantical - programming.


No - as would be expected. The ability to degrade gracefully does not automatically mean a table is accessible and usable after it has degraded (or before it degrades, for that matter), so degradation (graceful or otherwise) isn't used to measure accessibility or usability.

Perhaps. I am fairly new to the whole accessibility standards stuff as I never built a website which would need to be accessed by a disabled individual - and so I never looked into it. Although it is clear by its use in gov sites and site reader sites that they can be made accessible if properly coded.

I intend to do some more reading on the subject of tables and accessibility and so if you have any good resources please post 'em!

csuguy




msg:3724486
 3:39 pm on Aug 16, 2008 (gmt 0)

I went through W3C's WCAG guidlines - specifically those regarding tables. It seems pretty easy to make a table accessible. There are a couple things to consider - like older screen readers seem to have trouble with graceful degradation, so a little bit of extra work might be involved there. Although the technique I've adapted would easily avoid that complication. Using a single column table for layout and using divs if I need more than 1 column in a row - yeah for hybrids!

encyclo




msg:3724519
 4:42 pm on Aug 16, 2008 (gmt 0)

You can try this thread for some ideas on how to improve the accessibility of tables:

[webmasterworld.com...]

csuguy




msg:3724523
 4:50 pm on Aug 16, 2008 (gmt 0)

That's a nice thread. Although it deals more with data tables than layout tables as were discussing here. You don't want to use TH in a layout table.

alt131




msg:3724722
 2:22 am on Aug 17, 2008 (gmt 0)

csuguy and making tables for layout accessible
I intend to do some more reading on the subject of tables and accessibility and so if you have any good resources please post 'em!

To avoid hijacking this thread, a quick start is the Accessibility and Usability [webmasterworld.com] forum library for links to threads and external resources.

[edited by: tedster at 2:31 am (utc) on Aug. 17, 2008]

csuguy




msg:3724735
 3:08 am on Aug 17, 2008 (gmt 0)

Thx!

Marcia




msg:3724738
 3:15 am on Aug 17, 2008 (gmt 0)

You don't want to use TH in a layout table.

Thank you for mentioning that. On a site I work with (for SEO, conversion and usaability), the web designer used TH instead of <H2> for topical product sections when laying out product displays in nested tables.

IMHO, that's incorrect usage of HTML elements. The "topics" reflected in the <TH> are sub-topics of what the page itself is about, which is exactly what <H2> is supposed to be for, regardless of whether it's a tables or a CSS layout structure.

Solution1




msg:3724871
 1:12 pm on Aug 17, 2008 (gmt 0)

It is not possible to do columns in DIVs and CSS that have different content lengths, but equal column heights, and are flexible. (That is, if it needs to display in the most commonly used browsers.) It seems a lot of designers have therefore abandoned using equal length columns, so as to be able to do layout in DIVs and CSS exclusively.

I personally like designs with equal length columns - so I do it with TABLEs.

I have gotten used to doing most other layout in CSS. But I wish some replacement for CSS would be developed that is a bit more user friendly. CSS is too complicated and unintuitive for general use. We need something more simple, yet powerful.

csuguy




msg:3724890
 2:32 pm on Aug 17, 2008 (gmt 0)

:think: YA, like some kind of text markup language... :D

One way I've developed to solve the equal height problem is to use tables to define the rows and use divs to create the columns. This is useful if you have an area that you have to keep changing the number of columns for whatever reason. That way - you don't have to constantly adjust the colspan attribute. It has its limitations - like it doesn't seem that you can put anything inside of the div with a percentage height (and probably width) or it breaks. If you used overflow:auto in combination with it though - that would probably solve it. But - of course - the single best way to do a column/row layout is with tables.


<html>
<head>
<title>test</title>

<style>
<!--
#myTable
{
border:10px solid black;
margin:0 auto;
padding:0px;
width:740px;
height:500px;
}

td
{
vertical-align:top;
text-align:center;
}

.col
{
margin:0px;
padding:0px;
float:left;
height:99%;
}

#header
{
font-weight:bold;
}

#content_links_row
{
vertical-align:middle;
}

#links
{
width: 30%;
}

#content
{
border:1px dashed black;
width: 69%;
}

#footer
{
font-weight:bold;
}
-->
</style>
</head>

<body>

<table id="MyTable">
<tr>
<td id="header">
THIS IS THE HEADER ROW!
</td>
</tr>

<tr>
<td>
<div id="links" class="col">
LINKS GO HERE!
</div>

<div id="content" class="col">
CONTENT GOES HERE!<br>
<br><br><br><br><br><br>
<br><br><br><br><br><br>
<br><br><br><br><br><br>
<br><br><br><br><br><br>
...
</div>
</tr>

<tr>
<td id="footer">
THIS IS THE FOOTER!
</td>
</tr>
</table>

</body>
</html>

csuguy




msg:3724894
 2:39 pm on Aug 17, 2008 (gmt 0)

Actually - it seems putting any block level element inside of the div rows causes it to slightly break in FF2.

sgietz




msg:3725664
 4:20 pm on Aug 18, 2008 (gmt 0)

Webmaster World uses tables, font, and center tags :o

;)

Herenvardo




msg:3726498
 5:58 pm on Aug 19, 2008 (gmt 0)

'tables are for displaying data'

Indeed, they are. And knifes are for cutting things, and screwdrivers are for puting and removing screws... yet I have found myself, when lacking a screwdriver, using a knife to remove screws and, know what? It worked ;)
I've tried my best to stick with CSS, but I've always found it a massive pain in the ass compared to simply using tables.

I have been experimenting with CSS for the past few weeks (just to find out what could I achieve with it that would work cross-browser) and yes, it will take more effort to create a page using CSS than using tables (in the layout aspect). However, it should be later easier to maintain/modify a page that uses markup only for logical structure, and CSS for layout+formatting. At least in theory: that still depends on the overall design practices applied.

In short, I'm thinking of making life a lot easier by simply reverting to tables for formatting, with a little CSS to tweak it. Is this really such a crime?

Of course, that's not a crime by itself. As long as this doesn't lead to other crimes; which mostly depends on the audience and needs of your site.

I'll try to mention the main arguments on the topic (at least those I've heard about):
Semantics
That's a quite interesting one: yes, indeed, separating content from presentation makes a page more "semantic". And, what's the point of it? I find the concept of semantic webs quite interesting, from the theoric view-point, but I have yet to see any practical benefit of making a site "semantic". Until I see that, I'll consider semantics as a philosophy rather than an argument.

Accessibility
Yet again, separation of concerns can be a good tool to improve accessibility; but it is not the only tool, nor is it a fool-proof tool: a site can be made completelly accessible while using tables for layout (and even font tags, for that matter); while other sites can be using only CSS for layout and still be completelly unaccessible. Of course, there also are some CSS-based accessible sites, and some table-based unaccessible sites. Both <table>s and CSS are tools. Indeed, they were made with specific purposes in mind, so they are likely to suit such purposes; but at the end the way you use them are totally up to you.
One easy alternative to CSS for accessibility is server-side negotiation: just check which kind of browser is requesting your page (ie: a visual desktop browser, a screen-reader, a hand-held device integrated browser, etc), and serve appropriate content for each relevant sector.
Another mechanism is to use CSS to its best, even while using tables; like adding a sheet only for aural media that "hides" all the navigational stuff (or that puts it on the end).
Finally, if you are using XHTML, you might try to go nuts with XSL. It's probably overkill, but it's turing-complete, so you can, in theory, achieve anything with it (I have even seen XSL-based prime number generators).
In summary: yes, using CSS instead of <table> for layout can help making your site accessible, but there are other tools that can achieve the job as well.

Cross-browser compatibility
That's the point of the standards, after all. However, standards can only achieve compatibility among browsers that implement them; and the currently most used browser is well known to have too little compliance.
So this point should, in theory, pull towards CSS, but in practice it pulls towards tables.

Ease of authorship
As long as you keep your head over your shoulders, creating a table-based layout is simpler than creating a CSS-equivalent; but the latter should be easier to maintain and modify.

Maybe I'm missing something, but these are the points that come to my mind now. In summary: it's only you who can check your needs and figure out which is the tool that better suits them.

Hope this helps.

Regards,
Herenvardo.

Demaestro




msg:3726507
 6:18 pm on Aug 19, 2008 (gmt 0)

Think about what HTML is... it is a mark up language, meaning that the markup tag defines it's content.

<head> means that anything in it is header info. It doesn't make sense to put something in the <head> tag that isn't header info, the tag defines the content.

<body> means that it contains the body of the page, putting <head> content here would work, but is it right? Does it make sense? No because wrapping stuff in a body tag means you are defining it as the body.

<p> means that there is paragraphical text content. Should not be used for containing images nor should it be used to create blank spaces or columns. Is it wrong to put an image into a<p> tag... no, but it doesn't make logical sense since an image isn't text.

It isn't that <table> is bad for layouts, it is simply wrong.

<table> is meant to contain tabular data, putting something into a table should mean to anything looking at it that the content within is tabular in nature... so putting all your content into a table is not really logical since the entire page, layout included is not tabular data even though you are saying it is.

As we move towards a more strict HTML environment these things become more and more true.

Another issue with it that hasn't been mentioned is how many nodes does a bot have to traversed before getting to the content of the page?

<table> 1 node
<tr> 2 nodes
<td> 3 nodes
<table> 4 nodes
<tr> ... an so on.

For bots and indexers to get to the content there is often node upon node to parse through, check the content, decide if it is layout of textual content and so on. It is labor intensive and since your content isn't really what the markup says it is you get a penalty (in theory)

[edited by: Demaestro at 6:21 pm (utc) on Aug. 19, 2008]

Trace




msg:3726556
 7:16 pm on Aug 19, 2008 (gmt 0)

It isn't that <table> is bad for layouts, it is simply wrong.
QFT

When the time comes to hire a Webmaster/Integrator here, they could show me the most visually pleasing screens but if they're built wrong, I wouldn't want someone like that on my team.

If you're going to do anything, take the little extra time to do it correctly.

Herenvardo




msg:3726559
 7:20 pm on Aug 19, 2008 (gmt 0)

DeMaestro:

Your argument is mostly about semantics, and I just stated what's my position about semantics in my previous post.

On the other hand, the point about bots punishing content based on tag-hierarchy dept is worth a look at:
Another issue with it that hasn't been mentioned is how many nodes does a bot have to traversed before getting to the content of the page?

<table> 1 node
<tr> 2 nodes
<td> 3 nodes
<table> 4 nodes
<tr> ... an so on.


following on... the next <td> would be 6 nodes deep. You are using an example of, at least, two levels of table nesting, about which I'd like to make two comments:
1st: if a layout really requires nesting tables (remember that you can use the colspan and rowspan attributes), how many nested <div>s would you need to achieve the equivalent layout via CSS? (This not to mention how complex might the CSS be).
2nd: where I said
As long as you keep your head over your shoulders
I mostly meant "as long as you aren't nesting tables for layout". I'll try to make this clear: using a table for layout and, inside it, some tables for tabular contents seems fine to me (at least in some contexts); but if your layout really needs nesting tables then you should consider what kind of design are you doing (regardless of using tables or CSS). Remember that webpages do not come with a 400-pages user manual: keep it simple.

Besides the issue of nesting, your statement about bots punnishing these usages (which have been the norm for serveral years) seems quite speculative. Can you point to some factual data supporting it? (Either an example of a site affected by this, or some statement by a search engine mentioning this).
Personally, I really think that a semantic approach should help bots to understand a site's contents, and hence help on rankings; but I abstaining from mentioning it because it's rather a personal impression, quite hard to prove or even argue about.

Regards,
Herenvardo

This 155 message thread spans 6 pages: 155 ( [1] 2 3 4 5 6 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved