
Ask HN: Seriously, what's wrong with HTML tables? - anthonycerra
I'm new to web development and am learning HTML/CSS, Rails, and jQuery as I put together a web app. I noticed it's much easier to use tables to create forms, but apparently this is bad practice.<p>Can anyone give specific reasons why it's unwise to use tables for anything other than displaying tabular data?
======
ggchappell
This site sums it up pretty concisely:

<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.

~~~
rimantas

      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?).
    

Oh, come on. If some are still stuck with IE6 this does not mean that CSS is
only capable that much. Time to learn some modern CSS, folks (hint: IE8+
supports display: table-*).

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.

~~~
hyperlexic
IE6 still has a surprisingly large user base according to my analytics
reports. some of my clients' sites are seeing above 30% still using IE6.
hopefully IT departments will go to windows 7 or something, because seriously
- what year is this?

------
patio11
Comic sans, spec design, and tables: you just smile and nod when your designer
friends start talking. Every tribe has its signaling mechanisms. This is his.
Smile and nod.

~~~
zackattack
what does that mean?

~~~
nkurz
I think he means it's OK to use tables from a purely technical point of view,
but from a social perspective you're probably better keeping this opinion
private. The current approved attitude among designers is that HTML tables are
evil, so by agreeing you gain social standing. If you adopt the technically
arguable but socially inappropriate stance that there's a time and place for
tables, you'll be treated similarly to a C programmer who defends 'goto': at
best a relic, at worst a moron.

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.

------
absconditus
This topic has been discussed to death elsewhere.

[http://stackoverflow.com/questions/83073/why-not-use-
tables-...](http://stackoverflow.com/questions/83073/why-not-use-tables-for-
layout-in-html)

~~~
anthonycerra
Thanks for the link.

------
alanh
Tangentially, if you are designing HTML email, tables and old-school HTML are
_the_ way to go, still. This is due to an even sorrier state of affairs in
email clients than web browsers. (Not the least of which: Outlook, which uses
Microsoft Word (!) as its rendering engine.)

------
ltbarcly3
Nothing.

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.

~~~
pbhjpbhj
Amazon.com and Google.com (at least) don't even serve valid pages.

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 (&amp;, 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.

------
bsk
Here are a couple reasons:

\- 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.

~~~
rimantas
15 level deep? That's nothing. Try <http://www.telsiai.lt/> I did not count
the nesting level, but the total number of tables according to my bookmarklet
is 348. Yep, we do have some wonderful CMS over there…

~~~
hyperlexic
plenty of divs and spans out there on major sites that nest so far down it
looks almost like a fractal.

------
dgreensp
Purists consider it controversial, but using tables for forms is fine in my
opinion if it gets you the layout behavior you want. CSS and tables just don't
offer the same options when it comes to layout.

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.

------
barrydahlberg
It's a tool and just like a hammer, a little experience will tell you when to
use it and when not too. I personally think using them for forms is a
reasonable case if it suits you, I prefer the lighter markup I get with simple
divs in forms though. You will find eventually that the rigid structure of
tables gets a little annoying.

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.

~~~
anthonycerra
Thanks for the insight, I appreciate it.

------
hasenj
Because in the past, people used to use tables for everything. Want to add
some spacing? Create a table with invisible columns that contain 1-pixel gifs
"spacer.gif".

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.

~~~
pbhjpbhj
>Well then, are divs semantically correct for layout? Absolutely not.

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.

------
icey
Honestly I just use them whenever I feel they're useful.

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)

------
robenkleene
Form data (which is what the original poster asked about) arguably _is_
tabular data, containing both header and data cells. I use the table header
(<th>) tag for form labels and the table data (<td>) for form fields all the
time. (Although it is marginally better not to do so, if your design allows
it.)

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.

------
qeorge
Accessibility, SEO, and maintainability are the business reasons.

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.

[1] <http://en.wikipedia.org/wiki/Semantic_Web>

------
iuguy
There's nothing wrong with using tables for non-tabular reasons, just like
there's nothing wrong with using an 'under construction' animated gif while
you're building your site or having a nice midi file playing in the
background.

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.

------
DjDarkman
You can't make a scalable layout with tables.

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.

------
stephenou
It's probably because you are only dealing with the simple situation right now
where you have few elements to display. But once you get into a more advanced
level of user interface design, you will regret using tables because there are
so many blocks of elements needed to be fit in.

Or, imagine building Facebook/Twitter using <table></table>.

------
abrudtkuhl
Tables = Use to show tabular data and forms

Tables != Layout

------
sammcd
Before CSS became popular, tables where used heavily, not just to show data,
but also to layout page. As people started to use CSS for layout tables become
the enemy.

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.

------
JustinSeriously
Maintainability.

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.

------
towndrunk
The page you are looking at right now is full of tables.

~~~
julianz
...and when you go to view it on e.g. a mobile device, it looks like shit and
all the comments hang off the RHS of the screen. Which can be tricky to fix up
in a table-based design. And a bit easier to fix in a well-designed CSS one
(skip some DIV's, move them elsewhere on the page and so on)

------
zoomzoom
Someone always points this out in these threads, but HN uses tables...and we
all love this site. Theres no morality in web design, just results.

------
GrandMasterBirt
From a purist/non purist perspective:

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.

~~~
xiongchiamiov
960 and Blueprint are the most common grid frameworks (I think), but there are
more that some googling for "css grid" will lead you to.

