•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the HTML and CSS section within the Web Development category of DaniWeb, a massive community of 392,001 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 4,197 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our HTML and CSS advertiser: Lunarpages Web Hosting
Views: 4182 | Replies: 28
![]() |
•
•
Join Date: May 2006
Location: New Jersey
Posts: 1,422
Reputation:
Rep Power: 5
Solved Threads: 34
Why is easy:
1) Easier to update
2) Faster loading pages
3) More control
1) Easier to update
2) Faster loading pages
3) More control
John Conde
Brainyminds | Merchant Account Services | I Love Code
IT'S HERE: Merchant Accounts 101 Everything you need to know about merchant accounts!
Brainyminds | Merchant Account Services | I Love Code
IT'S HERE: Merchant Accounts 101 Everything you need to know about merchant accounts!
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 936
Reputation:
Rep Power: 5
Solved Threads: 47
Sometimes you can do things that could be done with tables with CSS instead; sometimes you can't, or it just becomes close to a waste of time trying (if you find your almost para-implementing tables with CSS + javscript, you're certainly wasting your time).
i guess the thinking is that a table is a restrictive structure (defined in markup) and CSS can be modular (by using different stylesheets)
CSS and tables aren't incompatible or exclusive. If you're being asked to do something without tables, you should ask the person commissioning you if they have a good reason why not to use them; and a reason based on heresay/myth-mongering isn't a valid one.
Here's some myths to dispell:
Myth - Screenreaders can't read tables
Fact - Well organised tables are easier to read in logical order (using a markup-based screenreader) than a load of floating/absolutely placed elements.
Myth - Tables are deprecated in the latest W3C HTML specs.:
Fact - Tables are not deprecated in any HTML or XHTML specification, although the WAI do advise against the use of tables in circumstances where they are inapropriate, or could be confusing if linearized.
Myth - Search engines don't like tables, a site without tables is going to get a lower rank in a search engine.
Fact - Search spiders don't like confusing or invalid markup, but they are intelliigent enough to work out what is markup and what is keywordable data. If your headings and primary keywords are in a table, you could probably organise your page better; but a spider just sees valid block level elements containing text, in the same way it would see any hierachy of block level elements.
Myth - Tables make my markup longer.
Fact - If your markup is shorter without some tables and still does what you want it to, then it probably wasn't neccessary to use those table in the first place. Standard "CSS-only" replacements for tables (which tend to make use of <div> elements in replacement) often contain at least as many <div> elements than <table>,<tr> and <td> elements in a table approach, and often suffer from browser compatibility issues or have a 'breaking threshold' (the point at which either a screen size or data length cause visual messiness) far lower than a table.
This is getting to be something I reiterate quite often. You'll find it's worth researching how to do things using different methods, but it's not worth restricting yourself in any direction for any reason.
i guess the thinking is that a table is a restrictive structure (defined in markup) and CSS can be modular (by using different stylesheets)
CSS and tables aren't incompatible or exclusive. If you're being asked to do something without tables, you should ask the person commissioning you if they have a good reason why not to use them; and a reason based on heresay/myth-mongering isn't a valid one.
Here's some myths to dispell:
Myth - Screenreaders can't read tables
Fact - Well organised tables are easier to read in logical order (using a markup-based screenreader) than a load of floating/absolutely placed elements.
Myth - Tables are deprecated in the latest W3C HTML specs.:
Fact - Tables are not deprecated in any HTML or XHTML specification, although the WAI do advise against the use of tables in circumstances where they are inapropriate, or could be confusing if linearized.
Myth - Search engines don't like tables, a site without tables is going to get a lower rank in a search engine.
Fact - Search spiders don't like confusing or invalid markup, but they are intelliigent enough to work out what is markup and what is keywordable data. If your headings and primary keywords are in a table, you could probably organise your page better; but a spider just sees valid block level elements containing text, in the same way it would see any hierachy of block level elements.
Myth - Tables make my markup longer.
Fact - If your markup is shorter without some tables and still does what you want it to, then it probably wasn't neccessary to use those table in the first place. Standard "CSS-only" replacements for tables (which tend to make use of <div> elements in replacement) often contain at least as many <div> elements than <table>,<tr> and <td> elements in a table approach, and often suffer from browser compatibility issues or have a 'breaking threshold' (the point at which either a screen size or data length cause visual messiness) far lower than a table.
This is getting to be something I reiterate quite often. You'll find it's worth researching how to do things using different methods, but it's not worth restricting yourself in any direction for any reason.
If it only works in Internet Explorer; it doesn't work.
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 936
Reputation:
Rep Power: 5
Solved Threads: 47
•
•
•
•
Why is easy:
1) Easier to update
2) Faster loading pages
3) More control
That went through as I was typing out my micro-essay...
As a rebuttal to 1, that depends entirely on how you update pages.
Tweaking the position of things is not the same as changing content, and a big style change usually involves some markup changing anyway.
In agreement with 2, in some circumstances.
In partial agreement with 3, except that a table is a controllable entity in itself, and sometimes control is more controllable when it's controlled. ^_-
Last edited by MattEvans : Jan 14th, 2007 at 1:35 pm. Reason: shorthand != isn't appropriate
If it only works in Internet Explorer; it doesn't work.
Ha!
It really is a preference issue.
Most people will tell you that tables were created exclusively to hold tabular data...and that any other use is wrong.
Since we have been using tables long before CSS, this is obviously false.
If your client doesn't care and you are GOOD at using tables, knock yourself out. If you are using 50 tables to position items on a small page, however, you should really look into learning CSS.
It really is a preference issue.
Most people will tell you that tables were created exclusively to hold tabular data...and that any other use is wrong.
Since we have been using tables long before CSS, this is obviously false.
If your client doesn't care and you are GOOD at using tables, knock yourself out. If you are using 50 tables to position items on a small page, however, you should really look into learning CSS.
•
•
Join Date: May 2006
Location: New Jersey
Posts: 1,422
Reputation:
Rep Power: 5
Solved Threads: 34
•
•
•
•
ost people will tell you that tables were created exclusively to hold tabular data...and that any other use is wrong.
Since we have been using tables long before CSS, this is obviously false.
That's because tables were the only way to control a page's layout. Until CSS came along, and was fully supported, it was either use tables (incorrectly) or have a basic top-to-bottom page. In other words, using tables were a hack.
Tables are meant for tabular data.
John Conde
Brainyminds | Merchant Account Services | I Love Code
IT'S HERE: Merchant Accounts 101 Everything you need to know about merchant accounts!
Brainyminds | Merchant Account Services | I Love Code
IT'S HERE: Merchant Accounts 101 Everything you need to know about merchant accounts!
•
•
Join Date: Oct 2005
Location: Northampton UK
Posts: 1,141
Reputation:
Rep Power: 6
Solved Threads: 9
•
•
•
•
That's because tables were the only way to control a page's layout. Until CSS came along, and was fully supported, it was either use tables (incorrectly) or have a basic top-to-bottom page. In other words, using tables were a hack.
Tables are meant for tabular data.
That is a perfect way of putting it. I also think one of the most important things for me is how much neater and easier to edit your html becomes.
The other day I had to make a quick design for someone who wanted to add all the server-side stuff themselves and they asked me to do it with tables and it took me I would say (with no exageration) about 10 or 20 times longer to do it than if I had just used css and no tables.
That depends on what you consider "wrong."
Technically, yes, according to the W3C, tables for layout is "wrong." I think browsers still have a little way to go in the way of rendering CSS uniformly across platforms, so sometimes a table is easier for those who are familiar with them.
I personally use CSS...but I won't hang someone who doesn't (unless they are working on my site).
Hey...I've been known to use a screwdriver for a chisel in the past. It may not be "right"...but it works in a pinch.
Technically, yes, according to the W3C, tables for layout is "wrong." I think browsers still have a little way to go in the way of rendering CSS uniformly across platforms, so sometimes a table is easier for those who are familiar with them.
I personally use CSS...but I won't hang someone who doesn't (unless they are working on my site).
Hey...I've been known to use a screwdriver for a chisel in the past. It may not be "right"...but it works in a pinch.
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 936
Reputation:
Rep Power: 5
Solved Threads: 47
I think a definate distinction needs to be drawn between designing with less tables, and tableless design.
Rigidly tableless design is as logically defunct as throwing all of the screwdrivers out of your toolbox because a chisel is good for presentation.
Mythical "CSS-only" chisels cause as much of a mess to the screwhead of any tabular data layout (which may or may not be presented as a table of figures) as a screwdriver would to a woodcarving.
Design with less tables is a process of natural selection. If "CSS-only" (which is an absolute myth anyway) could do everything tables could do, and reliably, and with the same markup overhead, and without being overall more hacky than a table solution, nobody would use tables; even if it were only to escape pre-spoken criticism.
All HTML markup is presentational to a point; HTML has almost none of the useful features a data definition language would have, and yet it's widely spoken as being 'data' that needs to be separated from presentation. All CSS solutions require markup, otherwise you have one element to work with; <body> (and even then you need a little markup).
You'll find, that the best designed websites and the best website designers make good use of the inherant advantages of tables, where and when they are appropriate.
I think it'd also be good to talk about the different types of website. Flashy graphical one-to-five page info-sites that never change unless the "website designer" gets another hefty contract payment probably never need a table. Each page can be carefully designed and tested on every browser version, and it'll always look good because it'll never change anyway.
Sites that present dynamic lists of anything (forums are a good example) will almost always use a table to present something, somewhere. Tables line up their rows and columns, tables are easily visually interpretable, tables can easily be populated from a database. Using a combination of HTML DIVs and SPANs and CSS to emulate a tabular layout for the data is always going to be 150% hacky.
In essence, this is exactly as the W3C put it, tabular data (possibly taken directly from a database table) could be presented in a table, and for the most part, should be presented in a table.
The same applies whether the HTML data is manually entered or automatically generated, provided there is some logical or meta-logical link between "these values" and "those values". In essence XML itself (and thus XHTML, and thus HTML if you agree that HTML is essentially occasionally-closure-implicit XHTML) is an arbitrarily-dimensioned nested tabular structure.
Where the path between data organisation and data layout lies will for the most part, and providing you're not aiming to confuse, fall along parallel lines. I fail to understand why double-implementing those lines could be of any benefit to anyone. Applying positioning CSS to a load of identically classed objects to arrange data that could be better organised seems somewhat backwards to me. Perhaps these CSS-only designers are aiming for totally content-ordered-markup, which seems to be mostly an SEO myth.
If you want to design without tables, definately try it. If you use one table where it's appropriate, you don't design without tables, you (perhaps) design with less tables. Neither way is inherantly wrong.
Rigidly tableless design is as logically defunct as throwing all of the screwdrivers out of your toolbox because a chisel is good for presentation.
Mythical "CSS-only" chisels cause as much of a mess to the screwhead of any tabular data layout (which may or may not be presented as a table of figures) as a screwdriver would to a woodcarving.
Design with less tables is a process of natural selection. If "CSS-only" (which is an absolute myth anyway) could do everything tables could do, and reliably, and with the same markup overhead, and without being overall more hacky than a table solution, nobody would use tables; even if it were only to escape pre-spoken criticism.
All HTML markup is presentational to a point; HTML has almost none of the useful features a data definition language would have, and yet it's widely spoken as being 'data' that needs to be separated from presentation. All CSS solutions require markup, otherwise you have one element to work with; <body> (and even then you need a little markup).
You'll find, that the best designed websites and the best website designers make good use of the inherant advantages of tables, where and when they are appropriate.
I think it'd also be good to talk about the different types of website. Flashy graphical one-to-five page info-sites that never change unless the "website designer" gets another hefty contract payment probably never need a table. Each page can be carefully designed and tested on every browser version, and it'll always look good because it'll never change anyway.
Sites that present dynamic lists of anything (forums are a good example) will almost always use a table to present something, somewhere. Tables line up their rows and columns, tables are easily visually interpretable, tables can easily be populated from a database. Using a combination of HTML DIVs and SPANs and CSS to emulate a tabular layout for the data is always going to be 150% hacky.
In essence, this is exactly as the W3C put it, tabular data (possibly taken directly from a database table) could be presented in a table, and for the most part, should be presented in a table.
The same applies whether the HTML data is manually entered or automatically generated, provided there is some logical or meta-logical link between "these values" and "those values". In essence XML itself (and thus XHTML, and thus HTML if you agree that HTML is essentially occasionally-closure-implicit XHTML) is an arbitrarily-dimensioned nested tabular structure.
Where the path between data organisation and data layout lies will for the most part, and providing you're not aiming to confuse, fall along parallel lines. I fail to understand why double-implementing those lines could be of any benefit to anyone. Applying positioning CSS to a load of identically classed objects to arrange data that could be better organised seems somewhat backwards to me. Perhaps these CSS-only designers are aiming for totally content-ordered-markup, which seems to be mostly an SEO myth.
If you want to design without tables, definately try it. If you use one table where it's appropriate, you don't design without tables, you (perhaps) design with less tables. Neither way is inherantly wrong.
If it only works in Internet Explorer; it doesn't work.
•
•
Join Date: Jan 2007
Posts: 6
Reputation:
Rep Power: 0
Solved Threads: 0
In order to keep up with the "trend" of modern design techniques you should really learn CSS and tableless (or less-table
) design practices. The key benefits I can think are as follows:
1) Using CSS makes your site more accessible to those with disablities and textbased web browsers (Lynx).
2) CSS makes your code easier to read and understand by search engine bots. (and yourself sometimes)
3) It's good practice to keep your Presentation/Layout layer seperate from your Data/Content layer. (updating is in-fact easier).
Think of it this way: You wouldn't use Excel to design a webpage so why would you use tables. Move on to CSS and don't look back.
) design practices. The key benefits I can think are as follows:1) Using CSS makes your site more accessible to those with disablities and textbased web browsers (Lynx).
2) CSS makes your code easier to read and understand by search engine bots. (and yourself sometimes)
3) It's good practice to keep your Presentation/Layout layer seperate from your Data/Content layer. (updating is in-fact easier).
Think of it this way: You wouldn't use Excel to design a webpage so why would you use tables. Move on to CSS and don't look back.
Last edited by mrclean : Jan 19th, 2007 at 1:33 pm.
![]() |
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
•
•
•
•
•
•
•
•
DaniWeb HTML and CSS Marketplace
- Seeking Talented Graphic Web Deigner (Web Development Job Offers)
- forum software (Growing an Online Community)
- Any recommendations on good Flash books? (Graphics and Multimedia)
- designing with em / ex ? (HTML and CSS)
Other Threads in the HTML and CSS Forum
- Previous Thread: Strange CSS action: Possible causes?
- Next Thread: Css Layout



Linear Mode