Forum Moderators: open
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?
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 ;)
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.
... 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.
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
Is this really such a crime?
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.
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
The problems stems from poor layout, meaning following a sensible structure, and poor coding. That, can apply to any layout format.
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.
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.
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!
[webmasterworld.com...]
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!
[edited by: tedster at 2:31 am (utc) on Aug. 17, 2008]
You don't want to use TH in a layout table.
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.
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.
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>
;)
'tables are for displaying data'
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.
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?
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.
<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]
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.
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.
As long as you keep your head over your shouldersI 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
