Can anyone give specific reasons why it's unwise to use tables for anything other than displaying tabular data?
http://phrogz.net/CSS/WhyTablesAreBadForLayout.html
Not that I agree with him entirely. In particular:
> 6. Once you know CSS, table-based layouts usually take more time to implement.
For a sizable site with layouts reused over multiple pages, yes. For a single page, or a site with differing layouts for each page, in my experience, no. Actually, I'd extend that first sentence of mine into a new reason: with CSS you can specify your layout once, and not have to redo it for every page. Doesn't work with tables.
> 7. Tables are semantically incorrect markup for layout.
My response: So what? (Yes, I know about the problems with screen readers, but that's a different reason, one I happen to agree with.)
And then, on the other hand, there are the things no one wants to say: the advantages tables have over CSS. In particular, it's obvious to me that CSS was not designed with modern layouts in mind. The fact that it works at all is really just an accident: it turned out that you can make columns using floats (how 'bout that?). Yes, using tables for layout is a kind of jury-rig, but to be honest, so is using CSS. And at least tables have a mechanism for producing columns, that was designed with columns in mind.
And then there are the browser rendering inconsistencies. With modern browsers, these problems are fading, but for older ones, the inconsistencies with CSS seem to be much more troublesome than those with tables.
And then, on the other hand, there are the things no one
wants to say: the advantages tables have over CSS. In
particular, it's obvious to me that CSS was not designed
with modern layouts in mind. The fact that it works at all
is really just an accident: it turned out that you can make
columns using floats (how 'bout that?).
And anyone who thinks that tables are easier to deal with either did not work enough with CSS or did not care enough. In 1996-2003 I was building stuff tables way, in 2004 I went full CSS and never looked back.
Probably both, in my case. :-)
(I don't agree with this. I hate table layouts from the experience of maintaining sites with them.)
Nod and smile, then get back to work. Improve your toolset by learning how it's done in Haskell (Erlang, Lua, R, other up and coming language) on the side, but don't be worried about using the language you know to get the job done. Understand the potential advantages of CSS, but don't worry too much about a perfectly workable solution. Just realize that you'll be mocked for it in certain circles. But better to be mocked with a site that's up and running than to still be debating whether quotes should always be used even if not required by the spec.
http://stackoverflow.com/questions/83073/why-not-use-tables-...
Look at the source to amazon.com, netflix.com, google.com, bing.com. It's hard to find any big site that doesn't use tables for at least some layout tasks.
CSS is a really, really shitty method of doing layout. Fanboys will come out of the woodwork to try and prove that statement wrong, but in my opinion, it's true. I'm not sure how we ended up with such a terrible tool.
There are times when I have spent 10 hours trying to do some trivial bit of layout done with CSS, and finally resorting to a little table got it done instantly.
There are entire classes of things that you can't do with CSS, or you have to resort to bizarre hacks to get done (negative padding, etc).
I'm not claiming that tables solve every problem, but presented with the choice of spending hours figuring out some css hack and testing it in the dozens of browsers / mobile browsers that are out there now, and just making a table, I will just make the table and move on.
Edit: You should use CSS 90% of the time. Tables often let you do something easily that CSS has lots of trouble with, and I recommend resorting to them at that point.
Amazon doesn't declare a doctype or character encoding. They have 7 blocks of inline CSS, there page is a dog to load. They have nested tables for non-tabular data, the don't encode entities (&, etc), they use non-existent (in spec) attribute values, don't declare all script types, don't add all alt attributes, they use a mixture of XHTML and HTML (mixed use of self-closing tags and unclosed tags), etc., etc..
So I guess big sites just don't care about web standards.
I can't imagine how insane it would drive you trying to navigate Amazon's site with a screenreader.
- At one point the design becomes a nightmare to maintain. I've worked on some web apps, where we had pages with 15 levels deep tables in tables in tables ...
- Separating the semantic information in .html from the design in .css. Can help with SEO, screen readers, cashing.
There are only two big uses for tables that I would avoid, and which are probably how this all started:
- Don't put all your content in giant tables for multiple columns, etc. Browsers do have to go to some effort to calculate column widths and such, and may delay rendering the contents of the table, e.g. until all the dependencies like inline images are loaded.
- Don't try to use big hairy pixel-precise tables for freeform layout, like when designers would carve up a mock in Photoshop, export the "slices" as 14 different images, and reassemble them using tables. This is a maintainability and usability nightmare and will come back to bite you.
People can get really dogmatic about not using tables. Perhaps you could find some forms you like and see what kind of mark-up they use.
In the past we've seen huge messes of tables nested upon tables which creates bloated, inflexible HTML. This is usually done by people who would create huge bloated messes of divs anyway. What you should really be focusing on is creating clean, valid markup written with a sense of style and care.
CSS frameworks like Blueprint can make getting started with layout a lot easier for you if don't mind having an argument about the abuse of CSS as well.
Now adays these things can happen with CSS, and you should use css to get spacing and positioning done right.
However, for layout, I completely disagree with the mainstream idea that "divs and css are better than tables for layout".
#1 argument, they say, is that tables are semantically incorrect for layout.
Well then, are divs semantically correct for layout? Absolutely not. Actually, tables are semantically correct for layout.
How else do you express stacking elements vertically and horizontally?
Floating divs to create layout is a horrible hack, and it's not maintainable at all.
Use tables to get the basic layout, but do all the styling with css.
Adding a div adds no semantic meaning to the page. Adding a table tells you that the elements in the different columns and rows relate to one another, that the rows or columns duplicate data types that the td have relationships with one another as data.
Tables are semantically correct for arranging data that is related correctly when presented in a table; but this is not "layout" in terms of visual appearance. The semantics of the data table aren't necessarily related to the layout - imagine a table of <name,image,date> tuples that you arrange as floating polaroid imges using some javascript.
>How else do you express stacking elements vertically and horizontally?
If ordering is important for the meaning of the data then use lists (ol) if 2D ordered data is being presented then you have a table and using the table element is expected.
The web is not print media and was designed to convey information (to myriad different UA) and not to give rigid print-like presentation of that same information.
Tabular data goes in tables (including forms for the most part). Everything else goes in a DIV (or SPAN, I guess).
That being said, all of my tables are put inside of DIVs for layout.
(Also, I'm not a designer)
The dogmatic view, that marking up your document with as few, strictly semantic tags as possible is ideal, has died down in recent years. I advocate the following approach: create your design and initial as-semantic-as-possible HTML. Starting doing the CSS, you run into problems that a table would help with? Either adapt the design, or just put in the table -- your guiding light should be semantic markup is great, but it isn't worth adding hard-to-maintain HTML/CSS hacks to your design in order to keep your markup perfect.
In otherwords, HTML/CSS hacks are worse than some bad markup here and there.
Always keep in mind that the HTML/CSS revolution was a _blogging_ movement. Usually keeping the markup strictly semantic is easy for a blog, as blogs are textual documents -- the type of data that and HTML/CSS were originally designed for.
I personally mainly work on web applications (think lots of buttons and forms), HTML/CSS perform far worse in this context. And I've wasted a lot of time extrapolating what is good advice for a blog to web applications were it can be terrible advice.
But the larger reason, the why, is that its easier for a computer to parse. If you want to be part of the Semantic Web[1], you should make your pages as machine-readable as possible. Makers of screen readers will thank you too.
<table> means tabular data, not layout. But since no one follows that, parsers first have to determine which way you meant <table>. This is an unneeded complication. If everyone used the right tags (<div> and <span> for layout, everything else is semantic), writing a parser would be insanely easy and we could spend our time on more interesting problems.
I'm sure some day someone will come up with some sort of standard that allows a regular website to look good on multiple devices with multiple capabilities, perhaps some sort of file containing style information that could tell the browser how to structure different sections.
You can't easily change complex table-based layouts, because you get lost in the td-s and tr-s.
You can make forms even easier with some clever CSS.
Or, imagine building Facebook/Twitter using <table></table>.
Tables != Layout
Tables became bad, and CSS became good. So much that some people where using divs to show data for a while just because they hated tables so much.
Same reason that, when you code, you want to include comments, have good variable names, use reasonably-sized functions, etc. It makes maintainability and future extension much easier.
Forget about semantic purity. CSS has survived all these years because it's been very useful in a very practical sense.
There is something inherently wrong with CSS tables for layout. There are also technological hurdles.
When using RAW CSS WITH NO FRAMEWORK laying shit out is hard at best. Which is why you should use one of a multitude of frameworks which give you css grid layouts. There are also frameworks which apply css 2 table cell properties to layout your page using tables without tables.
When using HTML Tables, you are guaranteeing that your site will NEVER scale gracefully with lower resolutions and mobile devices without CSS (dying). While sometimes you do want to say "Vertical" or "Horrizontal" box, on some devices neither helps. You need wrapping, text area resizing (and i dont mean textarea tags) etc.
So in the end of the day: Don't do Table-based layouts. BUT ALSO DON'T REINVENT THE WHEEL. I think it is an equal sin to hack up a new layout css for every page/project as it is to hack up a new webserver for every little 2-page static html server.
From a technological perspective, tables don't make for good layout containers. They don't respect their width/height properties like you hope they would. You need to account for the dreaded cellpadding and cellspacing defaults, child borders/margins, etc. Avoid it. Trust me, a bigger headache in the long run.