Related
There's a general consensus that using tables for layout in HTML should be avoided. But there are exceptions to every rule. I am designing an SPA (single page application)—with pages that resemble the layout used by a desktop application.
Obviously HTML isn't well equipped for these types of pages, but I have little other choice. Implementing these layouts with DIVs is pure hell, requiring a mix of CSS tricks, hard-coded values and even JS calculations on resize events. I've recently asked this question about implementing these layouts using a grid framework.
But then I stopped to reconsider whether a table-based layout might be appropriate. The typical criticisms don't seem to apply to the unique case of an SPA:
Separation of content from layout—Since an SPA is not really content (it's just a skeleton with AJAX filled data), this argument doesn't apply. This is just an interface; I don't expect Google to index it.
Tables are less maintainable—Not in this case. The CSS hell you have to go through to implement this with DIVs has a much higher maintenance cost.
Tables are slower to render—Of course, but the complex layout we would be creating using alternatives would require even more calculations to render than tables. Heck, we usually compensate for the inherent limitations using JS resize events. It would be much more efficient for the browser to do this natively inside the rendering engine.
In light of these arguments, are table-based layouts appropriate in the specific case of SPAs, or am I failing to consider some other important factors? Is there an even better option?
People used to be wrong about tables. Many people, who knew nothing, pushed for non table layout, event though it didn't make any sense at all at that time, especially when there was still ie5+6 to worry about. There were many misconceptions, eg. that google cares about semantic code. It never has, and it never will, because people get it wrong, and you can not account for it.
However, now, finally there is an actual reason not to use tables:
Media Queries and responsive Design
In responsive design, if you have 2 columns, it makes sense to drop one column to the bottom on small screens. For example, several columns can become a single column on a phone screen.
You can not do this with tables.
This, in my opinion, is the single most important problem with tables. Most other arguments are nothing more than mental masturbation.
There are other layouts, like masonry (see e.g. http://masonry.desandro.com/), which I think would be hard to achieve with tables alone. But for the classical problems of full height columns, tables were the right solution, even though most people preferred horrible workarounds, adding a ton of fragile markup and css just to fake a table.
Now, however it's different, as a table doesn't give you the flexibility you need for responsiveness.
Forgetting about things that pertain exclusively to the developer like code maintainability and religion wars about semantics and what-not, my question is: what real world problems does using tables present to the user? Are there device that cannot understand a tabled layout properly? Does it decrease the page's relevance on search engines?
Of course I'm talking about a reasonable layout where tables are only used for things that in pure CSS/divs require hacks (and for tabular data obviously) -- not things like a hundred nested tables maybe even used instead of ul/li.
User agents (aka browsers) for the visually-impaired may use spoken descriptions of a webpage.
When the layout is done by table, the description of the page contents becomes a description of the table, which is unlikely to help understanding.
Tables are such old technology that they are reliably rendered on every device and in every program I know.
I am not encouraging the use of tables for layout unless really, really necessary (which it is in a few cases), but I do not believe a well done layout using tables for some aspects does automatically affect rendering negatively. Feel free to prove me wrong, though.
There may be problems for text to speech programs when a table is used instead of the semantically correct element, e.g. in ordered/unordered lists. But I believe that any text to speech or other accessibility software has provisions for this, otherwise it would not be usable on today's Internet.
There may also be cases in which a browser that needs to intelligently resize a web page (e.g. a mobile browser) has more trouble with tables than with other layout elements. But that depends very much on the individual layout and situation.
Here's a nice presentation that sums up the problems with tables pretty well: http://www.hotdesign.com/seybold/06problems.html
The main end-user argument I have about it is future-proofing, and page size (which relates to load time, which relates to user experience). If you are designing a page semantically, and using the minimal markup approach, then page sizes w/o table-based layout are almost always smaller than pages that use a table-based layout.
That's more bits on the wire on every request for that page, which (as stated) means longer load times, etc. min-html + external CSS sheet, however, works out to markedly faster load times for most production sites (see Yahoo's YSLOW guidance) due to the fact that there's usually a one to many relationship between CSS sheets and pages, which means that you are taking advantage of browser's caching capabilities (and potentially other intermediate devices caching as well).
The future-proofing comment is related to design changes. It's much easier to effect wholesale visual layout redesign from CSS with a min-markup page than it is to do so in most common table-based designs. See csszengarden.com for examples.
Obviously, YMMV in both cases. If you're really making the minimal use of tables (e.g. one table on a page, one row in that table, three TDs in that row, one for each column), then you probably don't have to worry about those things. That said, ime, it's better to learn the CSS techniques, or pay someone who knows them. Designs quickly become more complex than you think they will up front many times, and using tables as a quick fix soon becomes a slippery slope. Again, all said IME; YMMV.
This question already has answers here:
Why not use tables for layout in HTML? [closed]
(66 answers)
Closed 5 years ago.
I have been pondering on this over the last couple of days. I'm currently writing a web application (actually adding a screen to an existing, extensive application). I know that using "tables" for layout is a big no-no. But in this app, all of the pages use tables for layout. I decided to do my new page using divs instead.
But I came across 2 hurdles.
A lot of the layout stuff that I need to do were already done on the other pages and if I use divs instead, I cant reuse any of that (CSS's and JS and that kinda stuff). That leads to more work and pushes out my completion date.
Some of the more complex parts of the layout are really difficult to do using divs and are really easy to do using tables. Maybe its just me being "old-school"y as I am not much of a web/html kinda guy (I get by).
So, why can't I use tables? I'm not trying to be argumentative, just want to see if there are any compelling arguments beyond the "Its the right thing to do" type stuff. I know it is the right thing to do. I'd like to know why?
Implementing your layout with divs, spans, etc, offers a ton more flexibility over tables. Consider floating, auto wrapping of block content vs. horizontal scrolling, specifying where an element should exist on a page, etc. Content is just plain easier to manipulate via CSS when not using tables.
When using tables you're pretty locked in to a strict structure.
Now that doesn't mean it's absolutely the wrong thing to do. From your information I'd likely stick with the theme of the application for consistency sake and implement using tables. Make the best choice for the situation vs. following "the rules" on what's popular right now.
Hope that helps!
Ian
Doing css layouts make it easier to change the layout of your page later on.
Tables also make your html harder to read and edit.
According to this page..
make your redesigns more efficient and less expensive
help you maintain visual consistency throughout your sites
get you better search engine results when you minimize your markup and use header tags properly. This reduces ratio of code to content.
make your sites more accessible to all viewers and user agents.
your pages load faster, file sizes will be smaller because table information isn't needed in every page.
and give you a competitive edge (that is, job security) as more of the world moves to using Web standards.
I'm going to post a contrarian view, just so you have some ammo. I realize this doesn't answer your question (why not use tables) but it does address the other responses you will see.
The future of CSS never gets here (note: from 2005)
Everyone else uses tables and there are valid arguments against every response others have listed.
You might find some middle ground by using "display:table" to turn DIVs into TABLEs. Of course, you can't do this because IE doesn't support it until v8.
I read a good point somewhere: when people are referring to side-by-side columns of equal height as the "holy grail", something must be wrong with the layout engine.
I mean, just look at the unmaintainable contortions some people go through to make it work: negative margins, pixel counts that must correspond throughout five different rules, etc.
So be practical.
That said, most of my designs use pure CSS. Nearly everything can be done in CSS just as easily as with tables (or even easier.) Start with the assumption that DIVs can do it, and maybe fall back on 1 table for a tricky multi-column layout. Even then, someone has probably found a solution for your layout so search first.
They are also bad for accessibility reasons i.e. screen readers don't read them correctly, but this is only if the data you are representing is not tabular data.
Saying that, due to deadlines etc. (the real world) I've resorted to using them for form layout because it's just so much easier.
Because the tag <table> implies it should contain tabular data.
Like Peter said, the universe won't implode if you do create table-based layout, but semantically, this should be avoided.
Semantics become increasingly important, since web pages are not always shown in a desktop browser anymore. Web standards are developing in a way that HTML describes the semantic structure of the document, not the markup; and as said: using <table> tags for tabular data is semantically correct.
Interesting related reads:
Should Tables be avoided in HTML at any cost?
http://en.wikipedia.org/wiki/Semantic_Web
First, you can usually convert a table layout to divs without too much trouble once you know the necessary CSS.
But more to the point, some of the reasons why tables are bad:
Not all your users are going to see the page using the browser's rendering engine. Some are going to use a screen reader, which may assume that when it encounters a table, it should actually read the contents out as tabular data. Essentially, you should think of it as a coincidence that tables have a certain layout "look" in a browser.
tables can't be rendered until the table and all its children have been parsed. A div can be rendered independently of its children, so you avoid the page contents jumping up and down on the page as the page is parsed, and get to show contents sooner.
There are good and valid reasons to prefer tables, but when you're used to tables, there's also a certain learning curve, so if you're pressed for time, this might not be the time to make that switch.
If you have the kind of constraints you mentioned, deadline looming, large existing code base, then use tables, the universe won't implode, but in the long term using css and welformed markup will allow you to create a nicer, cleaner, more maintainable website.
Tables are pretty ugly if you want to support text to speech readers (if you've got any kind of accessibility requirements, you pretty much have to use tables for tables and nothing else).
There is an SEO aspect of this as well. For SEO, it's better to have your content at the top of the page than at the bottom. (Sadly, studies suggest appears that putting a menu first is actually a good idea for accessibility, so the two imperatives clash.)
If you are having trouble with cross-browser support, I can suggest that you develop using Firefox. Its support for CSS development is much better than other browsers, and it's more standards-compliant (and hence more predictable). Later on, you can patch up for down-level browsers.
And, as Peter says, the universe won't implode. But using CSS for layout is cleaner in the long term. Redesigning something with the layout hard-coded can be a real pain. Check out the CSS Zen Garden for examples of what you can do. Of course, in the future, we'll have CSS table layouts, the best of both worlds.
Tables also affect the behaviour of search engines. Using CSS instead of tables is actually an SEO technique as well. The reason I heard for this is that search engines stop indexing after a certain level of tags, and layout using tables can become very deeply nested.
Using CSS for layout, rather than HTML tables provides a level of separation between your page content and the layout of that content.
With tables, your HTML markup has both your content and layout intermingled within the HTML code. This means is you ever want to have a different layout for the same content, you'll need to edit the intermingled code heavily.
By using a CSS stylesheet over your HTML markup you separate the code that provides the content (HTML) from the code that provides the layout (CSS). This makes it far easier to completely change the layout aspect of a web page without having to edit the content code.
The best example of this is the CSS Zen Garden website.
All that said, it's still far easier to do some layout techniques in tables rather than CSS, so there's definitely a "balancing act" there. (For example, even Google uses tables in it's page layouts!)
By using tables for layout you tie the content to the formatting, this is the main point that most of the disadvantages come from. It messes up the source, complicates site-wide formatting updates that could be easily done with CSS, etc. Using tables for layout also often means slicing images on weird places just to fit them in the cells, yuck.
you can use tables, but divs have more advantages.
but it's all in perspective.
Like you say, you are precious for time, so probably (on short notice) tables will be the choice to make. However, if you manage to make it div-wise, you will have a more maintable page, which you can use to refactor the other pages as well.
Jeffrey Zeldman wrote a great book on this topic: Designing With Web Standards. This book should be mandatory reading for every web designer.
Here are some reasons why tables for design are bad
Tables generate more markup -> More bandwidth usage
Tables makes it harder for search engines to index your pages -> Your site becomes less "searchable"
Tables makes it harder to change and tweak the visible appearance of your site -> More costly redesigns
...But most importantly: using tables for design adds presentation logic to your markup
That is bad because you want to separate your presentation from your content! HTML should only define WHAT your content is, not HOW it should look.
If you obtain this level of separation your site will...
...be more accessible by different kinds of browsers and other kinds of user agents.
...make redesigns much easier
The best you do not listen to the fanatics of CSS. These purists live in some imaginary world and will feed you the arguments of some abstract purity, semantics and the rest. You would not want to have this kind of people in your team. For now I've only seen yellow-mouth students to run around with "pure CSS design" ideas. They'll show you examples of very primitive CSS-designed sites, ignoring you whenever you ask them how you can accomplish some complex enterprise software design with it. Experienced developers already know this perfection is not possible.
What should you do? Follow the KISS principle. If CSS can help you implement your particular design idea, fine, the problem is solved. If you need to resort to some relatively uncomplex hack, it may be okay. But when it comes to some huge piece of code with dozens of rules to make a basic thing, which you easily and naturally achieve with tables, drop it.
It serves no purpose to create an incredibly complex and sophisticated tricky CSS design that noone else (and yourself after a couple of months) will be able to understand and support.
As for the "easy redesign", unless you only want to change colors and fonts, you will enevitably have to restructure your markup whether it is done with tables or without them. In the latter case, a high portion of your markup will serve no purpose except implement CSS trickery which will be useless for you new redesign idea.
Honestly, it's not your fault that the people responsible for further development of HTML/CSS don't do their job properly. You should not waste your and other people's time trying to find workarounds for something that should have been there ages ago.
HTML/CSS is a good example of how poorly some committee could do their job and brake the development of technology as compared to a single company with resources and commitment.
"The right thing to do" depends on your situation.
Yes, divs offer more flexibility, but at the end of the day, do you really need it? As far as the number of lines of code goes, I have found that a simple table is often quite a bit smaller that an equivalent div design.
It's faster to put together, and it works as reliably as possible in pretty much all browsers, which means you don't have to write a zillion hacks to make it work consistently AND it doesn't break down when a new display engine comes out.
Using tables for display is technically a hack, but it does the job, is easy to understand and maintain and is to a large degree future proof, so for a simple layout, considering that the rest of the website already uses tables for layout, I would keep using tables.
Besides, turning a Table into a "div" table which uses the new "display=table" attributes can easily be done with a few regexes (if you rack your brains, you can probably even do it with a single pass). If you know your regexes, you can replace a table with divs through an entire website in a matter of minutes, so the whole issue of flexibility is really not that big: when (if) you actually need to use divs and CSS positioning, just run a few regex, and you are set. And if you need more control than what you can handle from regex, you can spend a couple hours to write a quick & dirty parser that will convert your tables to div exactly as you want them.
Bottom line is that despite the stigma, for simple layouts, tables still do the job, they do it fast and are reliable, and if you don't have to contend with CSS purists, you can save yourself a lot of work.
CSS layouts make it easier to alter the layout through stylesheets (separation of data from display).
Also, browsers often can't render a table until the </table> tag has been parsed. This can be a problem if you are using a table with a large amount of content. CSS layouts can often be rendered as they go.
I have been designing websites table-less for a while now. the problem is that it can take a very long time to finish the site. People who design using tables can finish much faster. What's a good tutorial or of related to do such a thing?
I know this is wrong but I've noticed a lot of clients don't really care and they want their site asap. doing it the div way, depending on the site can take forever.
PS: I've tried designing the site in say Photoshop or Illustrator then exported the design as a webpage, but when it comes to modifying the design, i cant wrap my head around getting the site to show correctly.. and usually i get pissed of and start hand coding it. i find hand coding alot easier then anything else. i think its a bad habit or can be. i take longer doing it by hand thought.
Table-based layout is extremely simple, at least conceptually. A table starts with <table> and ends with </table>. Inside you have zero or more rows (<tr>...</tr>), inside of which you have zero or more columns (<td>...</td>). There are a few other tags (thead/tbody/tfoot, th for header cells), but that's really all you need to know about tables - no tutorial needed.
The main advantages to a table are:
The size of a table adjusts based on the size of the content
Columns always line up, making it easy to line content up vertically
Simple to code - a few lines of HTML are all that's needed for basic structure
Universally supported - the table will look and act properly in old/weird browsers (I'm looking at you, IE!)
The downsides to tables include an "it's complicated" relationship status with div and CSS, not to mention the scorn of your peers. Tables aren't a complete replacement for div and CSS, but don't let anyone tell you that div and CSS are complete replacements for tables either.
When attempting to style a table, there are a few things that you can play with to make it look the way you want:
border - this defines a border around and between the cells of the table
padding - this is the amount of padding between the content and the edges of the cell
text-align - horizontal alignment of content within the cell
vertical-align - vertical alignment of content within the cell (useful for vertical centering!)
border-collapse - you can collapse the border to remove any spacing between cells
W3Schools has a pretty good tutorial here:
http://www.w3schools.com/html/html_tables.asp
You might want to take the time to study up on using DIV's, CSS, etc., as exporting a website from Photoshop and Illustrator will only give you headaches when you need to make small tweaks. (Along with numerous other scenarios.)
If you use tables, you'll have a lot more headaches if you're trying to do any fancy DHTML. Table elements are not block elements, they're not box elements, they're tables.
If you have just a static HTML site with no javascript, then your issues aren't as severe, however one point of table less design is to separate design and structure. Which is worth the trouble it takes to learn css.
For example, forget just the benefits and lack of headaches having to hunt down table layout design when you want to make adjustments later, putting all design rules into a css file reduces subsequent downloads for clients, as your css will be cached even if your markup pages are generated dynamically via PHP. This makes your site load faster.
And anyhow many developers can create css table-less layouts as quick other people create some ugly table + spacer.gif sites.
Isn't the question where a tutorial is for div layout? I've just been reading a book about web accessibility which states the preference for div layout in pretty strong terms.
Your argument is valid, coding a site with tables is much faster off the line. The problem with tables is that they're significantly harder to maintain in the long run. By using divs you'll have a much simpler time when adjusting style or layout changes in the future.
If the site you're creating will require (very) little to no future maintenance then tables would be arguably better/faster. However, if you are planing on making changes to the sites design/layout in the future (even just an average amount of changes/fixes), a div-centric design will be much more rewarding.
There are plenty of tutorials available on the web but I'm going to take a different tack with my answer.
Are you creating these pages to do things the right way or are you creating them for a business purpose?
If the former, by all means learn as much about the CSS-type solutions as you can. You should be doing that anyway but don't let it get in the way of delivery.
If the latter, I doubt the customer cares how 'pure' the code is behind it, as long as it looks okay. Their primary concern will be speed of delivery and nice rendering on all the major browsers.
That's the reason why I still use tables for layout on the stuff I deliver to customers. I also only test it on three browsers (I won't say which) since that's all my customers care about. They really don't care whether Opera on the iPhone (for example) renders correctly since that's not their target market.
Maybe I'm a Luddite, but I don't see anything wrong with using a table for page layout. It works everywhere and as you said, users rightfully don't much care. Note that I said a table; multiple nested table sites are a nightmare to maintain. And just because you're using a table for the wireframe doesn't mean that you shouldn't be using CSS extensively to style it and the rest of your site.
You can get the best of both worlds by using correct HTML markup, and then, in CSS, using the various different table-related values of the display property.
As for using tables in HTML, this is what W3C says (see Tables in HTML documents):
Tables should not be used purely as a
means to layout document content as
this may present problems when
rendering to non-visual media.
Additionally, when used with graphics,
these tables may force users to scroll
horizontally to view a table designed
on a system with a larger display. To
minimize these problems, authors
should use style sheets to control
layout rather than tables.
Steve
If you like tables, know tables and they don't do you wrong then stick with it, but 'going div' can be pretty liberating. You do need though to understand positioning and I've not found a better tutorial than the following to teach you how to position divs
http://www.barelyfitz.com/screencast/html-training/css/positioning
the best tutorial site I know is htmldog which, despite the name, is mostly about css.
Also two invaluable sites for replicating table like designs using divs are:
Faux columns (for making divs
equal height
This site, which will
generate the basic cross-browser
page layout html and css for you:
http://fu2k.org/alex/css/onetruelayout/example/interactive
Stick with divs - as you get used to it it'll become second nature, maybe even quicker than tables
In HTML Web page creation the table creation on the page is been declared inside the body of the content into this the table can be declared
<table> and ends With </table> then the table header <theader></theader>
then rows has been initialised <tr>content</tr> table datas are inserted using <td>content</td> table border and width height font style font weight background are declared in the css.
It is advisable to use tables in HTML pages (now that we have CSS)?
What are the applications of tables? What features/abilities does tables have that are not in CSS?
Related Questions
Tables instead of DIVs
DIV vs TABLE
DIVs vs. TABLEs a rebuttal please
No - not at all. But use tables for tabular data. Just don't use them for general layouting.
But if you display tabular data, like results or maybe even a form, go ahead and use tables!
I guess I'm not in the majority here, but I still see a lot of use for tables in HTML. Of course, yes, for things like forms, you simply can't beat a table. Trying to line up the labels and accompanying form fields would certainly be possible using DIV's, but what a PITA that would be, and resizing the page would be ugly in some cases. A table works wonders here.
But also consider larger issues. For example, have you tried to create a standard 3 column layout with header and footer using only DIV's and CSS? Again, it is very possible, and there are about 1000 websites with examples, but they all tend to suffer from the same problems. The first problem is that the columns never really like to all become the same height without some sort of javascript assistance. The second problem is changing the layout is often a tricky thing, because it is a bit of a balacing act to get everything "just right" to begin with, so then you don't want to mess with it. Finally, and this goes back to that last point - it ain't easy. You have to lay out all your DIV's, then go back and create the magic CSS that force those DIV's into the proper position, and then spend a few hours tweaking it until it is right.... ugh. And then looking at the HTML without a viewer really gives you NO idea what the page looks like because it is ALL reinterpreted by the CSS in the end.
Now, option B. Use a table. Spend about 30 seconds typing out the <tr> and <td> tags, probably no CSS at all, no javascript 'fixit', and know EXACTLY what it will look like just by looking at the HTML.
Certainly there are arguments for and against tables, and purists seem to favor DIV's for layout, but don't use DIV's for religious reasons just because someone told you tables are evil. Use what works best for you, your page, and the way your viewers are going to interact with the page. If that's a table, then use it. If not, don't.
Everyone so far has said how tables should only be used for tabular data, and this is true. Take a look at the HTML source of any page on SO and you'll see that they have a different idea...
I think their rationale is that sometimes using a table is just so much simpler. Though, there are a lot of really good usability reasons why to avoid them.
Other than for tabular data, tables are unfortunately still necessary if you want to create flexible grid layouts such as complex forms in a cross-browser compatible manner.
CSS2 has support for creating flexible grid layouts without using the table element via the display property, but this is not supported in IE6 or IE7.
However, for most basic form layouts, CSS should be sufficient.
If only the CSS equivalent was as expedient in setting up a "table-like" layout, then I would love to use CSS. I find the time that it takes to mimic the things that others have listed here (equal heights on cells, auto-growing rows, etc.) is simply not worth the effort. I don't get a return on my investment as opposed to quickly throwing together a table in most cases.
All browsers can agree on exactly how a table should be laid out. Bam. Done.
Here's how my CSS follies usually go:
Try setting up a table-like layout in CSS. Spend 20 minutes or more getting everything just so in Mozilla and then open it up in IE. Spend another 30 minutes tweaking between those two browsers. Pretend like there are only two browsers in the world because I actually need to get some work done.
I believe in the promise of CSS: Separation of concerns. The problem is that for those who need to be productive, CSS is not ready for prime time. Or perhaps it's the rendering engines of the browsers - whichever.
The benefit of CSS is that it separates design and layout from content.
If you have tabular data then it makes sense to use a <TABLE> tag. If you want to layout different blocks of content then you should use <DIV> or <SPAN> and CSS.
Tables are for outputting tabular data. Anything that you might display in a spreadsheet, columns of results, that kind of thing.
The suggestion of using CSS rather than tables is for columnar layouts, which weren't really actual tables. It was never intended to suggest that tables should be removed completely.
Tables have no equivalent in CSS2, and they aren't that easy to duplicate using css. The particular part of tables that is hard to reproduce is the auto-sizing of the columns. While it's easy to let the 1 row grow to the same size across the page, it's hard for the next row to match up the column size or each cell size dynamically, and in fact can't be done without using other scripting languages such as javascript, php or others. You can use max and min widths, as well as set percentages for cell sizes, or hard code cell width's, but dynamically growing cells work fine for 1 row, it's the next row below it that won't match up.
Scanning over these answers, I didn't see one real-world reason where tables are necessary for layout and that is html emails.
I work for a very, very large financial company and we track around 600 different jobs a month....many of which are multiple email campaigns.
You cannot use css for layout for any mail reader. There are a few inline css specs you can use that relate to color, font face and size and even line-height is fairly widely available but for layout, you have to use tables as all the major and most minor email readers (Outlook 97/03, Entourage, MSN etc) read them just fine.
The issues with tables come into play when you have td's that do not have height/width specified whether they contain data or not. So, 'broken' table layouts are usually fixed by paying attention to attributes and yes... whitespace in the html....yes whitespace that isn't supposed to matter.
So, if you ever work for a large company/corporation or you land a very large client, be ready to throw all the current technology out the door and get your html table hat on!
I think it all depends on time/effort. While a purist might say "only use tables for tabular data," I've used tables to ease cross-browser layouts in the past.
For me, it's matter of time utilization. I can either spend my time cranking away on the CSS to get it right or I can toss it in a table and spend far less time on it. I tend to go this route until things are up and running. Once the functionality is there, I go back and polish the CSS/HTML.
I have to go with the tables approach here. The reason for this comes simply down to cost. Until a well supported CSS-centric approach to layout comes out, and I am talking about at the macro level...not micro within containers, trying to shoehorn CSS positioning into a generalized approach to layout is inefficient. You have to approach this from the perspective of the person writing the check for the development.
A few years ago I contracted to develop and maintain a site for a major hotel chain. We went with a table driven layout; your basic header, body, footer with left/right columns. We also used tables for some of the finer elements like non-graphic buttons. The chain's parent company maintained their own site and went with a pure CSS approach to layout. When IE7 came out our site worked perfectly without any changes. The parent company's site was a mess. Overall they spent about 1000 total hours (between meetings/development/QA/rollout) fixing the issues.
When you are paid to develop a site part of your responsibility is to mitigate against future risk and minimize future development costs, particularly if those costs do not add value to the site (your product).
My very simple and basic opinion on this is that tables are there for tabular data - not for positioning one thing on top or next to another element because you happen to like it being there.
So - if you want to display a table of data: do so (with a table). If you want to position content on the page: use css.
I think you might be slightly confused. CSS is a method of styling HTML documents, whether this is a table element or a 'div'.
It used to be that tables were used in HTML to design the whole page layout. It was common to see multiple nested tables (usually generated by WYSIWYG programs such as Dreamweaver), and this lead to a maintainance nightmare.
Since the introduction and adoption of CSS stylesheets it is now correct only to use a table for tabular data. That means if your data is most naturally rendered as a table use the table element. You can still style the table using CSS.
However, and I generally disapprove of this method since it duplicates existing functionality, it is possible to use elements to build a table like structure. In fact there are several website that will generate such code for you, but I have no links to hand.
Remeber also that some users might be either viewing in text only mode, or using a screen reader both of which will probably break the page (like reading the columns vertically rather than horizontally) hence the proper use of tables.
HTH
I believe and hope the era of using tables for layout is gone. Simply put: a table is a table, nothing else.
What I think will be the new, similar, flamewar topic for next few years is : should I use new CSS feature display: table, table-cell, table-row etc. for layout?? ? :-)
I think the reason this comes up so much is that using html tables is easier to understand when creating structure and layout than CSS. Using CSS is more abstract but helps seperate your code.
In response to the "structure" argument...by definition, isn't using html tables giving structure to data so that you identify it as "tabular". Whether it is CSS or html you are controlling the flow and layout of data. Be it tabular or otherwise...
If CSS tables are so important (and I'm sure my answer will start some kind of flame war) why isn't there a mechanism in Visual Studio to create a layout using CSS? Oh, you didn't check the layout feature thingy in VS? Yeah, you get tables, straight from Microsoft. I'm not complaining, just making the point that if it meant as much to the rest of the world you would see MS switch to CSS.
In my opinion do what fits best with your project. For one or two page web projects I still use html because what it does is obvious. Using CSS is more abstract and some mornings I just haven't had that much coffee. HTML tables can get messy, fast. CSS takes a little more time to get messy but will too.
Although for some layouts using tables may seem simpler at first, when maintenance time comes using css pays off. Especially if you ever want to change the position of something, or if you want to use the same layout in several places.
IMHO, tables should be used only when presenting tables. Never for layout purposes.
Tables are used for displaying tabular data. There's not much else to add :-D
If there is a reason for using a table in a semantic way (for example for showing tabular data) use tables.
Just use no tables to do layout stuff. There are lot of searchengine und accessibility benefits that you get with semantic markup.
Reserving tables for use only for tabular data works most of the time. There are certain layout problems that are much easier to achieve with tables than anything else. For example, vertical alignment and equal height columns. On the other side of the fence, there have been some complex data tables that I've used floated divs for because tables weren't fitting the bill.
Like anything else, use the right tool for the right job, and sometimes the most pragmatic tool isn't what you think it would be. That said, I rarely use tables for layout, even in the examples I gave, because inevitably I hit some problem that makes me have to do it with CSS anyway. Your mileage may vary.
I also don't like the idea of using tables to arrange items on a page. However this should not become a religion - tables are bad. I've encountered one example where I have a three column layout and needed the center column to grow with the content. In the end the solution that was the simplest and worked well on all needed browsers was to use a table. IMHO CSS still has some shortcomings and sometimes it's better to use something simple that works rather than just adhere blindly to some idea ('tables are bad...').
you can even use them for layouting, if your layout is somewhat tabular. I like the feature of tables and cells dynamically adjusting to whatever width the browser window is.
Never use any fixed widths or height, that's just messing up things.
It's easy.
Think your webpage as a real page on paper.
You should use tables on webpage only when you would draw a table on your paper.
Another tip is to use table only with border > 0.
This way, you use tables only when you mean you want a table (and not for layout).
#toddhd, advocating the use of tables for layout simply to save time is a cop out. If time is the issue, then you can quickly create a columnar layout without tables using a framework like Blueprint CSS or 960 Grid.
Seems to depend on what browsers were capable of when you started designing. If you began back when only tables worked then that is what you will probably always want to use, because you know it. Or if that is what you liked to use even after browsers had advanced to be able to render CSS...
I just don't like to keep doing the same things over and over because they are easy and I know how to do them.That is boring. I would much rather learn new techniques than dismiss something because I don't know how to use it or I think I don't have time to learn.
I don't like to use tables, I don't understand them, they seem alien and offensive but that is because I began in 2005. I also don't use design programs to spit out templates because I prefer hand coding.
I am going to assume that your question is actually - "Should I avoid using HTML tables for layout purposes?". The answer is: No. In fact, tables are specifically meant to be used to control layout. The drawback for using tables to control the layout of an entire page is that the source file rapidly becomes difficult to manually understand and edit. A (possible) advantage of using tables to control the entire layout is if there are specific concerns about cross-browser compatibility and rendering. I prefer to work directly with the HTML source file, and for me using CSS makes that easier than using tables for the entire layout.
Tables make sense only when you're trying to display tabular data and that's it. For layouts, you should always use DIVs and play with CSS positionings.
if you need to use a table, your layout probably sucks. Show me a single well-designed site that uses tables, and I'll show you a thousand that don't.
A lot of people are throwing around the term "purist". This is rubbish. Would you print newspaper copy in a book? Would you design a brochure with Excel? No? Then why would you use a table to display non-tabular data?
Most times the difficulties people face in letting go of tables for layout is a result of their own ignorance of HTML/CSS/Good Design Principles. While you may find it difficult to make multi-column layouts extend evenly in the vertical direction, you might think to try a different method. DIVs are not TABLEs. You can make faux columns using wide borders, page backgrounds, etc. Spend some time actually learning to do what you're setting out to do, or forever be seen as someone without any kind of useful skill. (http://www.alistapart.com would be a good start)
I'm honestly surprised that this question is cropping up in 2008. DIVs came around when I was in high school. Stop being a noob.
And as was mentioned above, tables fail hard on mobile devices and screen readers.