
Ask HN:  CSS vs table based layouts - iamelgringo
I'm working on my own site, and I was able to come up with a decent layout in about an hour or two using tables.  I then had a pang of guilt, and started re-doing things in CSS, and but it's taking me forever.<p>I know that from time to time, PG gets crap for using tables for HN, but it seems to work rather well, and it renders the same across all the browsers I've used, including my Android phone.<p>I'd love to hear an educated discussion on table based vs CSS based layouts.  Please discuss.
======
tptacek
Cheat. Use Blueprint, from Blue Flavor, which gives you semi-semantic layout
in table style using DIVs and spans. Blueprint actually gives you more layout
control than tables do --- your stuff will look better --- but gets rid of
almost all the CSS headaches.

Standards zealots get all up in Blueprint's face because it's fundamentally
non-semantic (you end up putting presentation details in your markup). But now
you're splitting hairs. If you're using Blueprint, you get to call yourself a
CSS designer.

~~~
larrywright
+1 for cheating, and for BluePrint - it makes CSS bearable for those of us who
aren't pros. 960gs (<http://960.gs>) is also a very nice framework.

One correction though, Blueprint isn't from Blue Flavor, though they did do an
article on it. It's by Olav Bjorkoy, and currently maintained by Christian
Montoya.

~~~
mcxx
Thanks for the 960gs, looks great. As I'm starting a small side project
without a frontend developer and I hate writing CSS, I'll consider using it.
The previous candidate was Malo (<http://code.google.com/p/malo/>).

------
run4yourlives
This debate is endless. Simply put, there is no clear answer.

Clearly, from what you've stated, CSS is not your forte. There's nothing wrong
with that. In fact, there was a time that I felt exactly like you. Now
however, I find CSS/tableless html easier, faster and cleaner overall. I use
it exclusively for general presentation. It really shines when I need to fix
websites after the fact, or two clients want different presentations of the
same code/datasets. It's a lot of fun to limit presentation to 2-3 files,
rather than your entire codebase.

That said, what's your motivation here? Do you believe/recognize the benefits
of CSS, or are you just feeling guilty because "all the cool kids are doing
it"?

If the former is your thinking, you have to realize that you are in learning
mode. Of course it's going to be harder. You're comparing a learning state to
a mastered state. Riding a bicycle is a lot harder if all you've done is ride
tricycles. It says nothing though about whether learning to ride a bike is
beneficial to you or worth the time and effort.

If you can see that moving to CSS layouts would have noticeable impact on your
production, tough it out, it gets easier I swear. If you can't see any benefit
to switching, then don't.

------
carlio
<http://www.giveupandusetables.com/>

<http://shouldiusetablesforlayout.com/>

------
gruseom
Doesn't your question include its answer? Guilt is not a very productive
motivation.

I've noticed that once people settle on something as "the" right way, they
measure everything against that yardstick. This is so common, I wonder if
having a yardstick -- an easy way to answer questions -- is the purpose of
settling on "the" right way in the first place.

Software people do this a lot because software projects are so uncertain: if
you can do anything (computable), why do X rather than Y? That's overwhelming,
so we look for paradigms and processes and yardsticks. These reduce hard
questions like "is this good" to easy ones like "is it standards-compliant".
It's like the drunk looking for his keys under a streetlight, rather than down
the block where he dropped them, because the light is better.

I noticed this when everyone around me was equating "good" programming with
"object-oriented" programming. It was too hard to answer "is this good", so
people instead would answer "is this OO". I caught myself doing it one day and
was shocked. I decided never to use the phrase "the right way" again, but
always to replace it with " _a_ right way".

The trouble with the yardstick instinct, of course, is when it produces fake
reductions. It gives you false positives ("it must be good because it's OO,
CSS, or whatever") and false negatives ("it must be bad because it isn't"). I
think the false negatives are more harmful than the false positives; they shut
down options and inhibit creativity. There's a joke in which a Frenchman says
to an Englishman, "I can see it works in practice, but does it work in
theory?" (Told by an Englishman of course.)

Coming back to CSS vs. tables: if it looks good, is fun for you to make (apart
from guilt), and does what users want (or will get you there), what's bad
about that? Conversely, if it's hard to make, not fun (apart from guilt
relief), and doesn't make things look better or work better, what's good about
that?

This is way more than I intended to write, damn you, but one more thing: if
you haven't, go read Adam Bosworth's classic 2004 talk on the web as the
triumph of the "simple, sloppy, and flexible". I can't recommend it enough. It
addresses all of this profoundly.

Edit: Surprisingly, it hadn't been posted to HN, so I just did.
<http://news.ycombinator.com/item?id=447086>

Edit 2: Whenever I recommend that piece to someone I go back and re-read it.
How's this for apropos:

 _What is more, in one of the unintended ironies of software history, HTML was
intended to be used as a way to provide a truly malleable plastic layout
language which never would be bound by 2 dimensional limitations, ironic
because hordes of CSS fanatics have been trying to bind it with straight
jackets ever since, bad mouthing tables and generations of tools have been
layering pixel precise 2 dimensional layout on top of it. And yet, ask any
gifted web author, like Jon Udell, and they will tell you that they often use
it in the lazy sloppy intuitive human way that it was designed to work. They
just pour in content. In 1996 I was at some of the initial XML meetings. The
participants' anger at HTML for "corrupting" content with layout was intense.
Some of the initial backers of XML were frustrated SGML folks who wanted a
better cleaner world in which data was pristinely separated from presentation.
In short, they disliked one of the great success stories of software history,
one that succeeded because of its limitations, not despite them. I very much
doubt that an HTML that had initially shipped as a clean layered set of
content (XML, Layout rules - XSLT, and Formatting- CSS) would have had
anything like the explosive uptake._

~~~
cninja
A agree. In the end it is about what is going to save you the most time.

For example, if you decide at some point you want all page titles to be bright
green and placed below the main text of the page, how much work will it be?

The whole argument about separating content and presentation is about speed.
If they are separate, and changes need to be made to one, then you don't have
to get knee deep in the other to change what needs to change.

CSS based layouts mean the changes might only require editing the one .css
file. Table based layouts might mean that you have to edit each page, or if
you are using a decent templating system, it might be a single page

The same goes for accessibility. Will it take more time to make your site
usable by screen readers and small screens while using one layout or another?
What types of accessibility are even important to you?

------
sanj
I'm so glad I'm not the only one that feels this way.

As far as I'm concerned, CSS is a miserable piece of work. Witness how hard it
is do a simple three column layout. It fails half of the simple edict:

Make easy things easy and hard things possible.

~~~
GHFigs
Since when is it hard to do a three column layout with CSS? It is in fact
quite easy, and always has been. What has been hard is three columns with a
liquid center column _that works in Internet Explorer without hacks_. That's a
Microsoft problem, not a CSS problem.

~~~
moe
Sorry but that is an understatement. Creating a three column layout _is_
surprisingly hard and completely counter-intuitive and it gets only harder
when you want liquid columns. IE is part of the problem but many of the other
browsers also had their own quierks until recently.

Creating a n-column layout in CSS, in a _sane_ way, has literally turned into
a pseudo-science over the years. That wouldn't be the case if it had ever been
as simple as spelling it out the obvious way and adding some IE hacks.

Even todays state of the art solution ("the holy grail") is a fairly strange
beast. It admittedly gets away without the nasty hacks and negative margins
that previous solutions required - but it took us literally years to arrive
there and it's still far from pretty.

~~~
rossriley
It really isn't complicated. Float three columns left with a combined width
less than that of the container and you have a three column layout.

~~~
moe
If you really think that then you have obviously never tried it. Look here for
the real solution, which is slightly more involved:

<http://matthewjamestaylor.com/blog/perfect-3-column.htm>

------
olavk
Here's the deal: CSS was designed to have all the styling and layout power of
presentational HTML, and more. Even universally hated features like "blink"
were supported, so nobody would have to use presenational HTML ever again.

So what whent wrong with tables? The culprit is that the CSS equivalent of
tables, the _display:table_ CSS property (defined in CSS 2) has not been
implemented in Internet Explorer yet, even though the standard is 12 years old
(IE8 will reportedly support it, though).

So there is no direct CSS equivalent to the layout properties of tables which
works in IE. You can emulate some of the properties using floats, absolute
positioning and so on, but be aware that this approach is _not_ the "correct"
CSS way. Rather it is a workaround around limitations in IE's _implementation_
of CSS. Using tables for layout is a alternative workaround for the same
problem. The approaches have different tradeoffs.

The main tradeoff is that HTML-tables are bad for accessibility, while CSS
alternatives are often convoluted and hard to maintain. So the choice is
basically if you want to cause pain for yourself or for disabled people. Its
not hard to understand how this debate turns into more of a moral than a
technical discussion.

Note that it is not _all_ uses of tables which require workarounds to
implement in table-less CSS. Before CSS, tables were used for a wide array of
layout tasks like spacing, margins, positioning and so on, which is generally
better handled by CSS today. The limitations are specifically when tables are
used as dynamically adjusting grids. I wrote a small article to point out the
concrete issues: <http://olav.dk/articles/tables.html>

BTW - it's a myth that tables render the same across browsers. Table rendering
has about the same amount of inconsistencies and browser differences as CSS.
The difference is that there is no "right way" to render tables, since table
rendering is not specified anywhere. It's all just a chain of reverse-
engeneering leading back to the first haphazard table implemtation in Netscape
1.1. With CSS there is at least a spec, and the hope that browsers
implentations move incrementally closer to the spec.

------
phoreo
I seriously find it difficult to believe that this is still a debate on YC.
Once you attempt to build a site of a reasonably level of complexity and/or
learn how to build a site using clean, valid, semantic markup, you'll never go
back - unless horribly messy code and hack piled upon hack are your thing.

This isn't about being a web standards zealot. It's about learning to do your
job. Look to any of the industry leaders in frontend development - it is
simply no longer an issue. Table-based implementations of layouts (and all
non-tabular data) are the GOTOs of modern markup.

------
tripngroove
CSS layouts offer a whole host of advantages over their ancient table-based
brethren. Historically, there has been a lot of discussion on this, but the
conversation has basically been concluded with CSS layouts overwhelmingly
recognized as the best option.

A CSS layout lets your site be flexible, scalable and semantically pure. When
you do a table-based layout, you're basically locked into that presentation
unless you choose to overhaul all your files, and chances are good that you've
also partially destroyed the semantics of your document, which ruins
accessibility and can be bad for SEO. Tables were basically a layout hack that
let designers solve a presentation problem for which adequate tools didn't
exist; their true purpose is to display tabular data. When browser support for
CSS became relatively ubiquitous, people gradually switched over because there
was no longer any reason to suffer the inherent inadequacy of table-based
layouts.

Once you learn the syntax and the basics of how the box model works, CSS makes
everything faster, easier, and more precise. By all accounts, it's the
standard for web design nowadays.

I think the proof is in the pudding though; csszengarden.com is a shining
example of the benefits of CSS. Surf there, and you can select different
stylesheets to be applied to the page. Same HTML, different CSS, hundreds of
designs.

alistapart.com is a great resource for discussion on the benefits of web
standards and how to apply them. quirksmode.org has technical tips, and
w3cshools.com has quick descriptions and examples of most almost everything
web-design related.

~~~
mattmaroon
That sounds kind of snobby, in that it's largely theoretical but just doesn't
work in the real world. It's like trying to explain to someone why a good Napa
Cabernet is so much better than the $5 Merlot they like.

"Well, it was grown from the Carneros region, fermented in French Oak barrels,
then cellared for 10 years."

"Yeah, but this Carlo Rossi Paisano tastes better."

(and I say this as a devoted wine snob.)

CSS is one of those things that sounds great "it lets you separate
presentation" but just kinda sucks for some purposes. The problem is, all of
the theory is just generally not how it functions in the real world. In the
real world, if you're running one site and redesigning it, you're doing just
as much changes anyway. You're not just changing some colors and some
background images and voila. You're moving things around drastically. (If you
could do absolute positioning, it would function a lot better in that regard,
but then your page will look crappy because it will be left-aligned in
browsers rather than centered.)

CSS doesn't really seem to be meant to do layouts anymore than tables were, as
evidenced by all of the hacky kludges you have to use to get it to work that
way. Every time I find myself typing style="clear:both" I wonder why the hell
I'm doing it. Still I did, grudgingly because guys like you tell me I should,
and I wanted to learn .

Don't get me wrong, CSS is great for some things. Defining fonts, sizes,
colors, hovers, etc. But for layouts, tables are often easier to implement,
easier to maintain, and equally hard to change later. Even though I'm highly
competent with CSS, I don't think I'd do it that way in the future.

~~~
pbhj
>>> "You're moving things around drastically."

Funnily enough I just altered two sites this week by moving columns around.
One was a simple CSS change, the other was one altered margin declaration and
one moved div - I also get to see the alterations as they will appear live in
a browser (FF).

>>> " Every time I find myself typing style="clear:both" I wonder why the hell
I'm doing it."

Because of IE?

>>> "equally hard to change later"

It depends what you're trying to achieve, if you require a pixel based layout
that renders identically in all browsers and completely misunderstands the
original web paradigm (accessibility of information, not accessibility of
design) then yeah, tables .. though you'd probably be more comfortable with
Flash or just going the whole hog and printing it out on paper and pasting it
to your screen.

When columns finally arrive in CSS3 (<http://www.w3.org/TR/css3-multicol/>)
across the major UA will you still use tables for non-tabular data?

~~~
mattmaroon
No, columns are awesome, and CSS3 in general looks like it does a lot more to
make CSS useful for layouts. HTML 5 + CSS3 is going to be a designer's dream.

------
sh1mmer
There are lots of ways to define quality. The problem is how much measure
people put in them. Guilt or coolness can be a good driver and so they are
often used instead of reasons based on quality. One of the other commenters
pointed out that guilt seems to be your motive.

There are a number of reasons not to use tables. The main 2 are maintenance
cost and accessibility.

 _Maintenance cost_ the main point here is by separating the visual styling
from the data you have much greater control over redesigning, changing the way
the data is displayed, etc.

 _Accessibility_ since many people who use the web can't see they listen to
their web pages. This means the source order of the site matters. If you
create tables that don't linearise then the information becomes out of context
and difficult for these users to understand. Using CSS it's possible to create
a source order which makes sense but display a different visual order.

My recommendation for a way to do this is to use a grid system like YUI Grids.
Like many other parts of development rolling all your CSS from scratch doesn't
make sense any more. There are plenty of libraries which take care of the hard
problems for you. My favorite CSS library for this is the YUI Grids library.
(<http://developer.yahoo.com/yui/grids>) It has tons of documentation and
examples to get started with. I use it for all my work and personal projects.

You might also consider the YUI Reset, Fonts and Base CSS libraries which
reset default CSS styles across browsers, standardises the fonts and sets back
a common default styling across all browsers respectively.

Disclaimer: I work for Yahoo!

------
tripngroove
Just for funsies, here's a pastebin that shows the CSS for a 3-column liquid
layout in its simplest incarnation, and then a second set of rules for the
same HTML that produce a 2-column fixed layout, with space for a horizontal
navbar.

<http://pastebin.com/f51ee9672>

------
davo11
I spent much time researching why the tables are bad camp exists, and this is
the result of my research:

The beginning

Initially tables were the only way to layout a web page, and so much abuse
occured - this was before CSS and the only way to make a layout was to use
'spacer' gifs. spacer gifs were one pixel gifs that you had to put in td
elements so they would retain there shape. As you can imagine this was a mess.

Then came CSS and the DIV tag, many books were written about 'spacer gifs were
evil' use Divs and CSS, and this was correct spacer gifs were a nightmare.

However what seems to have happened is the baby was thrown out with the
bathwater. Tables are the easiest way to do what's now called 'liquid layout'.
You can do these using Div's but it takes a bit of fiddling, and the result
can sometimes be wrong if the screen width becomes too small.

From a software development point of view I regard using div's for liquid
layout as an optimisation - semantically what you want is a spaced layout that
resizes dynamically. However, using tables does cause a couple of problems
that div's avoid (which I mention below), div's avoid these problems but at a
cost (which I also mention below).

The real crunch was early on - Netscape 4.7 (the one that was widely used)
crashed with multiple nested tables (try this on browsershots if you're
curious). So Div's were used and techniques for using div's in browsers became
prevalent.

The combination of the Netscape problems and spacer gifs created the 'tables
are bad' thing and new developers coming in were told 'tables are bad' and it
continues.

So people used div's and IE6 became the dominant browser, but the engineers
who built IE6 never expected anyone to use divs for layout - that's what
tables were for - and so the mess occured with div's and css and IE6. This, I
think, made the situation worse, as to use div's meant you could MS bash, it
also required a deeper understanding of HTML and CSS and so arose the
specialist web designers who used multiple incantations in DIV tags and CSS to
create what any joe could do in 5 minutes using table tags. This strengthened
the DIV/CSS camp until anyone who used table tags was openly scorned as a
newb.

In any argument you have with the DIV people the last one they always bring up
when they're on the ropes is that braille readers can't handle tables -
because the ordering isn't defined. However most of these people don't
actually write for disabled readers and this too seems to be without base, I
have asked many times for concrete examples, and never have received any.

There are some negatives with tables:

1) The whole page needs to be loaded before it can be rendered (in some
cases), as the layout can't be done until the contents of each cell are known.

2) This seems to be a big one - it's _very_ hard to edit nested tables in
notepad and figure out where you are, you need more expensive tools to
navigate the document, something web developers seem to be averse to for some
reason. Me, I buy whatever tools make my life easier.

The negatives with Div's as layout are there too:

1) If you have a few fixed width div's with the rightmost floating (the usual
way) and make the page smaller than the width of the div's the rightmost falls
below the other div's, it's not possible to stop this from happening. If you
use tables a scroll bar appears.

2) You have to have a deep understanding of CSS and a lot of time to
experiment on multiple browsers to see what works

Div's can start to display quicker as they have a fixed width usually and so
no layout algorithm is required to be calculated. (The actual time to
calculate the layout is no longer an issue, but it used to be for tables).

So that's the issues as I see them, and how we ended up with these two camps.
If anyone has some more data I'd like to see it. Personally I use a couple of
layers of nested tables to establish the rows and columns and fill it up with
div's as necessary, and don't worry too much any more. Oh and use styles to
actually describe the TABLE/TR and TD elements, which is CSS as far as I can
see.

~~~
puns
For point 1) on Div negatives: you could set a min-width on 'body' or the host
container if it's flexible to ensure the width never gets small enough for the
divs to clear.

~~~
davo11
Is that available in all browsers?

------
figured
HTML is the metadata around your content, and CSS is the style that you apply
to your content.

------
jsdalton
I used to design using tables, then I learned how to do it in CSS and now I
use CSS exclusively. There are only a few instances when I don't, namely:

* When I want vertical centering and the column height is not fixed.

* When I want the width of a column to expand to the width of its widest element, but no further.

* If I wanted a background color to run the full length of a column, not just where the content was. (Actually there are CSS hacks for this, but I don't love them. I myself never use this design pattern any more, so it doesn't matter.)

In other words, you can still deploy tables non semantically to address
certain, specific challenges that are not easy in just CSS, while still
predominantly using CSS for layout and tables for data.

------
dw0rm
I only use tables when its not possible to go without them (but it happens
very rarely). Actually, it requires some time to get used to CSS technique.
And I've never used CSS frameworks.

------
mattmcknight
If you are displaying a table of data, use <table>. <div> grids don't paste
well into Excel. Tables really aren't evil, they are a better fit for many
tasks where you effectively need a table and can generate the data in row
order. Nested tables can be pretty evil. Go with a div grid if you feel the
even the hint of wanting to nest.

See the triumph of KML (which mixes content and presentation) over straight
GML (separate content and presentation) in the GIS world for comparison.

------
Javache
Honestly, I've used CSS for as long as I've been slicing web pages (which is
now a couple of years) It'd probably cost me more time designing with tables
than with CSS. Once you understand the principles behind it, it's not that
hard... (for me it feels like a lego-construction snapping together when a
design falls into place)

On the other hand, a professional designer often needs to know how to design
with tables as well as it is practically the only way to design an email
newsletter decently.

------
auston
I feel like if it's a simple table with divs inside - it probably wont be a
big deal because it will be maintainable.

But if you're going to nest tables inside of tables nested inside of tables -
then I'd suggest not doing it.

You want to keep it maintainable for not only yourself but anyone else who
might be working on it in the future.

------
pwoods
Although tables is easier than CSS, most browsers will render CSS almost the
same way. But not always true for tables. Especially wider sites that need to
shrink to fit a screen. I just weigh amount of work I have to do against how
much I'm getting paid and do which ever way I feel comfortable with.

~~~
mattmcknight
"Most browsers will render CSS almost the same way". Either you have an odd
definition of most browsers or you are just completely wrong. CSS is
implemented differently by most of the major browsers.

------
theBobMcCormick
Use a good CSS grid framework like Blueprint, Bluetrip, or YUI. They make most
supposedly "tricky" CSS layouts (like 3 column liquid) quite easy.

And of course, remember that it's not necessarily an either/or decision.
Sometime part of your page really is a grid, and really should be a table.

------
juliend2
i used to "slice" my layouts with Adobe ImageReady then customize the
generated tag-soup with Dreamweaver. Then i transitionally changed my
techniques to adopt full-css templating. It takes me more time but i like the
way i can control several page's presentation by changing only one (ore more)
file. I also find it more php (or templating system) friendly because there
are less tags involved. I find it interesting to see other hacker's point of
view on that. It seems like the css way is not THE only way of doing things.
Maybe you can get the better of both worlds and use tables for things that
looks like tables and use css for what it's made for (i.e :floating stuff,
styling fonts).

Not that tables are made to structure the content. It's just easier.

------
timtrueman
Tables won't show up until the entire table has loaded but if that's not an
issue then use whatever you find easier (and don't feel guilty--if it works,
it works).

If it's tabular data ALWAYS use tables.

------
noodle
a 30 second review:

tables: easier to design with and more intuitive for people who aren't well-
versed in css.

css: much greater flexibility, smaller code, separation of design and
information

~~~
pmjordan
CSS-based sites are also supposed to be better in terms of accessibility as
screen readers etc. can separate out the semantically distinct parts better.

CSS layouts take some practice, and they made some design choices I'd describe
as bizarre, which make your task more difficult, but now that I've got a good
grasp on it, my markup is much more compact and I wouldn't want to go back.

------
akd
You don't have to pick just one. On one of my sites I have tables for the
navigation elements and CSS for the content elements. Use what works for you.

------
shutter
If you have the time, use CSS. For prototyping you could use tables perhaps,
but for the real thing, tables are considered bad form and inflexible.

------
kwamenum86
HTML is flawed at every level:

It's design is flawed- rather than having a minimal set of tags they have a
tag for everything and most people use only a fraction of total tags.

It's implementation is flawed- no two browsers render HTML the same way.

The way people learn HTML is flawed- some people learn to use inline styles,
some people use br's to delineate paragraphs, some people build pages without
head tags.

In conclusion, fuck it, use tables.

------
drhowarddrfine
I thought this question was not only answered, but went away, three or four
years ago. The first quick response is that tables for layout is stupid. You
lock yourself into a predefined grid which you have little control over, it
provides immovable elements that are more difficult to style and is slower to
download and render.

That's just the tip of the iceberg. Google for more. But you can get any piece
of crap markup to make a presentable page on the internet right now. So would
you continue to write crap code just because it works? Ridiculous!

Over 4 years of doing this. Never used tables for layout and I do mostly
ecommerce sites for national chains.

~~~
jasonkester
You're halfway correct. This question went away 3 or 4 years ago, but in the
other direction.

Everybody independently figured out that 35 DIV tags half-nested into each
other is actually MORE markup than a table, and it's less readable. So we all
went back to using Tables for stuff that looks like Tables.

I thought we copied you on the memo. Sorry about that!

------
bkbleikamp
This argument is over. Tables lost...like 3 or 4 years ago.

