
Why CSS should not be used for layout - lisper
http://www.flownet.com/ron/css-rant.html
======
alain94040
The article's argument would carry more weight if the author gave an example
using tables where he changes the order without affecting the layout.

The whole point of the argument is to show that if you change the order with
the CSS version, things move around. Then he goes on to show a static table.
What the article really proves is that tables are not better than CSS. And CSS
can do millions of things that tables can't (I'm not trying to start a troll
on that topic). So I'll stick with CSS, thanks.

There is one valid point in the argument: improving CSS so that you can
position elements in relation to each other _by name_ would help. So I could
say that the DIV element called "left" should be on the left of the "center"
element. Right now, relative order is based on the order in the HTML source.

~~~
randallsquared
"What the article really proves is that tables are not better than CSS."

Well, no. What the article shows is that, for layout, CSS has one of the same
chief defects that people complained about for tables (content and
presentation codependence), and that CSS doesn't even have the saving grace of
allowing the content to be in the same order people read in (in Western
languages, yes, yes), as tables do.

~~~
GHFigs
This is only true if you use CSS floats in a particular way which was not
foreseen when the specs were written, which is only necessary if you want a
certain kind of layout and don't want to use positioning or scripting. That
strikes me as a step forward from _always_ having that codependence.

~~~
mbreese
If this is true, then the CSS spec is bad. You should not have to require
scripting to position elements. Period. If you do, then it shouldn't be called
CSS, it should be called CSS/JS or some other merged acronym.

I've spent many hours tweaking a design with CSS and javascript to replicate
what would have been a simple table layout. There are just somethings that CSS
isn't good at, for example, it's bad a fluid column layouts. Particularly
where you want to have a vertical alignment of a block line up with the bottom
of the longest column. (I probably didn't explain that well...) I'm not aware
of any CSS that can handle this well w/o javascript.

~~~
GHFigs
Who said you have to require scripting to position elements? I most certainly
didn't mean to suggest that. That said, CSS is not a programming language, so
by nature there are things possible in combination with JavaScript that would
not otherwise be possible. I think it's worth considering when attempting to
go against the grain of the language, just as it's worth considering changing
direction to do something the language is better equipped to deal with.

------
tripngroove
I have the sneaking suspicion that there are a lot of coders contributing to
this recent rash of CSS vs. table discussions who flat-out don't know how to
write CSS very well, and can't be bothered to learn.

That was my obligatory quasi-offensive hook to get you reading. Now, before
you actually get angry... there's nothing wrong with that! You're a coder! Do
what you do best - write awesome useful stuff! ...and don't be afraid to
acknowledge that there's a language out there that looks like code, but that
you don't have a handle on.

As someone who has spent the last several years doing nothing but writing HTML
and CSS in a professional capacity, I am here to tell you that if all you
beautiful, intelligent hackers out there (I'm only being facetious about the
beautiful part, 'cause I've seen some of you ;) really understood front-end
layout the way you understand all your programmy stuff (which I do NOT), we
wouldn't be having this discussion.

If you're just working on a personal project, or trying to hammer out the beta
version of your web app... sure, use tables, so you're not wasting time trying
to do something that's not your core competency. However, if you're taking it
beyond that, or trying to get into front-end stuff in a professional capacity,
you need know CSS like the back of your hand. Someone who's competent at
layout should be able to write something from scratch that does whatever they
want it to without having to debug it for hours.

If you're at the point where your biggest problems would be solved by using
table layout instead of CSS, you're probably not at a point on the CSS
learning curve where it's appropriate to make assertions about which layout
technique is superior.

All that said, if you're a coder, why do you want to get into layout anyway?
Your skills are WAY more valuable... designers like me are just here to make
your work look good ;)

~~~
fauigerzigerk
Well, is there anything you have to say on the substance of this debate? The
good thing about Ron Garret's article is that he said specifically why he
thinks that CSS is unsuitable for doing layouts. You're free to come up with a
counter argument.

Instead what you do is talk in general terms about the competence of people
whose CSS competence you know nothing about. That's just not very convincing.

And by the way, you're "argument" reminds me of what C++ advocates keep going
on about. Templates are turing complete, etc, you just need know how to use
them. But even if competent CSS experts can make most things work, that
doesn't mean they wouldn't be much more productive using something better
suited to layout.

~~~
pj
* that doesn't mean they wouldn't be much more productive using something better suited to layout*

What would you suggest is better suited to layouts than CSS?

~~~
fauigerzigerk
I agree with Ron Garret that tables are a better fit in most cases, even
though they do have their own drawbacks that I'm not denying.

I don't buy the argument that tables somehow imply semantics that contradict
their use in layouting. Tables have no semantics without a formal system that
lends them semantics (like the relational model).

I'm not aware that the W3C or anyone else defined the formal meaning of
tables, and since HTML is a UI technology I don't see why "table" should not
be interpreted as a form of laying out content in rows and columns.

~~~
tripngroove
"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."

<http://www.w3.org/TR/html401/struct/tables.html#h-11.2.1>

~~~
fauigerzigerk
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119] <http://www.ietf.org/rfc/rfc2119.txt>

From that RFC:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.

------
moe
A well written and compelling argument. Way above the average CSS/Table rant
for sure.

~~~
olavk
Above average, sure, but still misinformed and one-sided.

It is correct that some layouts are easier created using tables rather than
CSS. However, there is also many types of layouts which cannot be created with
tables, but require CSS.

A serious article (rather than a rant) would explain the limitations of both
approaches, given the limitations of current browsers.

~~~
ambition
I for one would be interested in an HN submission that fleshes out the
suggestions you're making here.

~~~
olavk
I have an article which explains when to use tables:
<http://olav.dk/articles/tables.html>

But now that the pendumlum seem to have swung from _never use tables for
layout_ to _always use tables for layout_ , I suppose it should be extended
with an explanation of when _not_ to use tables :-)

------
sh1mmer
The author's point might have been better if there weren't a bunch of CSS
libraries which have already solved this
(<http://developer.yahoo.com/yui/grids/> and
<http://code.google.com/p/blueprintcss/> to pick two).

You wouldn't rewrite cstdlib why would you rewrite your CSS framework for
every project?

More over I think a lot of people neglect the real issue which is the high
touch point of the Web, it's the multiple clients. You try to write cross-OS
GUIs in Java and Swing and find out how easy that is (it isn't, obviously).

The reason people advocate CSS is that it presents some real tangible
benefits. CSS was specifically designed to present the semantics of layout
rather than HTML tables. The author doesn't even talk about CSS tables
([http://thinkvitamin.com/design/css/tables-the-next-
evolution...](http://thinkvitamin.com/design/css/tables-the-next-evolution-in-
css-layout/)).

Again I wish people would talk about technologies they were familiar with and
had even made spent time with. You don't see me critiquing the algorithmic
design of search engines because I didn't choose to follow CS down that route
of expertise.

~~~
Spyckie
Grids need more coverage, as they are by far the best way to bypass css misery
and create a flexible, controllable layout for your website. They require a
whole lot less markup than tables, are more intuitive, are much more
controllable, and in general should never be not used. With Grids, you start
thinking about ratios rather than pixels, which is a real help in making your
site aesthetically pleasing and flexible.

------
ars
When you first start learning CSS you learn how to get rid of tables. When you
get _really_ good at CSS you learn when to bring them back.

------
windsurfer
First, <http://shouldiusetablesforlayout.com/> for the idealist in me.

Second, <http://giveupandusetables.com/> for practicality.

~~~
mbreese
I particularly like that the first one uses a single table for layout.

If you're reading the page's source, you'll also find this eternal wisdom:
"Fact: Chuck Norris hates layout tables!"

~~~
windsurfer
Actually, if you check the first one again, it uses CSS, but it has a table
layout commented out.

------
geuis
His html example for the 3 column layout is subpar anyway. The wonderful
advantage of CSS is that I can create a multi-column layout where the html
might put the content div first and the nav last, if I have a reason to do so.
My underlying html structure doesn't need to be in any particular order in
order to achieve the layout that I want. He completely misses the fact that
CSS2.1 has had display: options to do table-like alignment for years. These
are well supported in modern browsers, except for IE6 and 7.

I completely recognize this is an argument of "what should be" versus "what
is". As it stands though, I have been doing this for years and have never,
never EVER needed to use tables for layout purposes. I get that some people
are more interested in writing applications and just don't have to time to
learn all of the idiosyncrasies that go into dealing with cross-browser
display problems. However most of these are easily overcome, most without even
needing CSS hacks.

~~~
gnaritas
"except for IE6 and 7"

So it doesn't work for the majority of browsers, yea, that's a technique I
really want to count on.

~~~
Jem
That's the fault of IE6 and 7 though, NOT CSS. Blaming CSS for the
inadequacies of MS browsers is flawed logic.

~~~
tlrobinson
It doesn't really matter who's to blame, it doesn't change the sorry state of
things...

------
iroboto
The arguments presented seem like a half truth to me.

1 HTML multiple CSS not 1 CSS multiple HTML

The whole concept should be that HTML should be written to have 100%
accessibility across all readers (browsers and mobile devices), meaning
someone with the most ancient browser can read the page and understand the
content of everything without any form of presentation.

What the author has done essentially is the following: Try reversing some
words in a sentence and then later complain that English is flawed because the
sentence no longer makes sense reading it left to right.

The HTML won't make any sense if you start reversing it... I mean what is the
point of putting <h2> tags below your <p> when it's obvious that the <h2> tag
is acting as the heading for the <p> below. I wouldn't be able to read that,
so why is CSS @ fault?

The logical flow of the content should be based upon the reading the raw HTML
in a procedural order. This will keep it simple for coders to update the
content, and css artists can pump many different layouts and show many
different layouts to clients in a matter of seconds.

Good CSS also requires good HTML. Why the author of the article is using a div
container to wrap them all when a body tag exists is beyond me.

I think as much as we point our fingers at css as a flawed language, we need
to point our fingers at how write our HTML as well.

www.csszengarden.com

~~~
chairface
> I mean what is the point of putting <h2> tags below your <p> when it's
> obvious that the <h2> tag is acting as the heading for the <p> below. I
> wouldn't be able to read that, so why is CSS @ fault?

Nobody is talking about putting headers after the content they're introducing.
The author is talking about a situation where it makes sense to order the
markup one way, but CSS demands it to be done a different, not easily readable
way. Which does happen sometimes.

> Why the author of the article is using a div container to wrap them all when
> a body tag exists is beyond me.

This looks like a ridiculous statement to me. But please, explain further what
you want him to do.

I find it comical that you go on about "good HTML" and then point to CSS Zen
Garden, where the HTML is inextricably bound up with the presentation (ie,
adding wrapper elements to allow for flexibility in styling). CSS Zen Garden
is an example of HTML as it should not have to be.

~~~
iroboto
CSS doesn't demand it to be done differently though. If the HTML is written
with a different flow the CSS will need to be written to accompany that.

I won't say it's perfect, but if you wrote div col 1 div col 2

and then you wanted col 2 to be on the left of col 1, you'd write the css
differently then you would the forward method.

>This looks like a ridiculous statement to me. But please, explain further
what you want him to do.

Well look at it this way <html><body><div container><stuff><div
container></body></html>

What is it that div container is doing so well that body isn't already doing
as a binding tag?

> I find it comical that you go on about "good HTML" and then point to CSS Zen
> Garden.

I will have to disagree. CSS Zen Garden reads perfectly and logically without
css. It's something that 90% of sites are missing out there. And although the
HTML is inextricably bound up with the presentation as you write, it is 100%
readable by Netscape 1.0.

He uses HTML to describe the data that is being wrapped in the tags, and the
information that is grouped by divs are grouped by the fact that the content
is related, not by the fact that the data should be visually sitting beside
each other.

While there is excessive usage of <span> tags written throughout, it was a
design decision to enable css artists to replace text with images, or allow
them to get around browser quirks that are challenges that CSS still face
today.

~~~
chairface
> and then you wanted col 2 to be on the left of col 1, you'd write the css
> differently then you would the forward method.

At the cost of a lot of flexibility. Most people, when faced with a change in
design like this, simply reorder their HTML. So perhaps "demand" was
hyperbole, but CSS does still push developers to rewrite their HTML when
design changes happen.

> Well look at it this way <html><body><div container><stuff><div
> container></body></html>

The container is providing a hook for layout information that the body tag
cannot. For instance, if I wanted the body background color to be blue and the
container's background to be white. Also, if you want your content to be
restricted in width, it's a lot easier to wrap it with a div than deal with
the lack of the > operator in IE 6.

> CSS Zen Garden reads perfectly and logically without css.

I didn't say that it's hard to read. I said that by the standards community's
definition it is not good HTML, because it mixes content and presentation.

Just to be clear, I think that "bad HTML" is pretty much the only practical
way to go right now. So, I don't have a problem with the way CSS Zen Garden
uses wrappers, nor do I have a problem with the wrappers in this blog post.
But you are criticizing one and making excuses for the other.

~~~
iroboto
>At the cost of a lot of flexibility. Most people, when faced with a change in
design like this, simply reorder their HTML. So perhaps "demand" was
hyperbole, but CSS does still push developers to rewrite their HTML when
design changes happen.

I don't doubt that cost/time is a factor. As programmers, we would all love to
do without the additional overhead of coding practices, and for an unlimited
number of reasons.

I realize that css isn't the best language in the world. But if it was
intuitive to write css forwards and backwards regardless of document flow --
this wouldn't be a discussion topic. The question is the amount of time
invested to learn it.

>The container is providing a hook for layout information that the body tag
cannot. For instance, if I wanted the body background color to be blue and the
container's background to be white. Also, if you want your content to be
restricted in width, it's a lot easier to wrap it with a div than deal with
the lack of the > operator in IE 6.

This is true. I was looking purely from layout perspective, but yea, body
bleeds background-color and image everywhere regardless of limiting the width.

>Just to be clear, I think that "bad HTML" is pretty much the only practical
way to go right now. So, I don't have a problem with the way CSS Zen Garden
uses wrappers, nor do I have a problem with the wrappers in this blog post.
But you are criticizing one and making excuses for the other.

Practical -- yes I don't disagree. With the way browsers interpret things
differently, it's just about the only way you can get compatibility across the
board.

Though you are right that I criticizing one and making excuses for the other:
at least one follows a clear stated goal -- html describes the content, css
draws the presentation. Provided items are added to make do with
incompatibility issues, but at least at the core we can see that HTML is
purely being used to describe the content. Allowing _enough_ separation
required for programmers to be nearly clueless of a designer's job.

The other has no such goal; creating a massive grey area between the
programmers and the designers.

~~~
chairface
> I realize that css isn't the best language in the world. But if it was
> intuitive to write css forwards and backwards regardless of document flow --
> this wouldn't be a discussion topic. The question is the amount of time
> invested to learn it.

Quite right. The argument, as I see it, is that it's much more practical to
use the best cross-platform tool for the job, which in many cases is tables
and not CSS. He's arguing that it's not worth the time.

> at least one follows a clear stated goal -- html describes the content, css
> draws the presentation.

This isn't even close to CSS Zen Garden's stated goal. Its goal is to show
what is possible to do using CSS. It's goal is to be "A demonstration of what
can be accomplished visually through CSS-based design." There's nothing about
content/presentation separation anywhere on the site.

> but at least at the core we can see that HTML is purely being used to
> describe the content

That's certainly not what I see at all, especially at CSS Zen Garden, if
that's what you're still referring to here.

> Allowing _enough_ separation required for programmers to be nearly clueless
> of a designer's job.

If you mean programmer == HTML, and designer == CSS, then this is simply
wrong.

~~~
iroboto
Programmer == backend html // designer = AI/PS/CSS cutter, and css writer

 __When I view source csszengarden this is what I see: <div id="intro"> <div
id="pageHeader"> <h1> <h2><acronym>

    
    
         <div id="quickSummary">
            <p class="p1"><acronym>
            <p class="p2">
         <div id="premable">
             <h3>
             <p class="p1">
             <p class="p2">
             <p class="p3">

<div id="supportingText"> etc etc. And it goes on.

All I see are information grouped by content. The ids, and class tags describe
the information. The paragraphs are ordered p1,p2,p3, because for them to make
sense they have to be in that order.

Page header, quick summary and preamble are all items that belong to an
introduction.

I think it's great.

~~~
chairface
In the source of csszengarden, do you also see this

> There are more classes and extraneous tags than needed, and in a real world
> situation, it's more likely that it would be much leaner.

and this

> <!--extra div for flexibility - this list will probably be the trickiest
> spot you'll deal with --> <div id="linkList2">

and this

> <!-- These extra divs/spans may be used as catch-alls to add extra imagery.
> --> <!-- Add a background image to each and use width and height to control
> sizing, place with absolute positioning --> <div
> id="extraDiv1"><span></span></div><div
> id="extraDiv2"><span></span></div><div id="extraDiv3"><span></span></div>
> <div id="extraDiv4"><span></span></div><div
> id="extraDiv5"><span></span></div><div id="extraDiv6"><span></span></div>

The HTML guy could not be "nearly clueless" about the designer's needs if CSS
Zen Garden's flexibility is what you're looking for.

~~~
iroboto
Sure I see it.

But your whole argument is on the basis points of 2 commented divs? <!-- These
extra divs/spans may be used as catch-alls to add extra imagery. -->

Add extra imagery -- it's posted at the bottom and away from the content. It's
not like it's messing with what the programmer needs to develop. You could
have easily have removed those tags and only the designs that decided to take
use of them would get hurt -- but it is optional, not a requirement.

<!--extra div for flexibility - this list will probably be the trickiest spot
you'll deal with --> I thought we discussed that browsers incompatibilities
are the reason for this.

The core of the content is listed at the top of the HTML page which is
organized properly.

TBH: I would hardly call this level of adding extra markup anywhere close to
other HTML where the presentation is completely ingrained.

~~~
chairface
> it's posted at the bottom and away from the content

But it's HTML, and should therefore should BE content. But it's not; it's
presentation.

> I thought we discussed that browsers incompatibilities are the reason for
> this.

You seem to be missing my point. If CSS, as implemented NOW, worked as
advertised and offered a way to separate content from presentation while
retaining flexibility, then we'd have no argument. I'd happily be using it for
what is intended. You just can't do that now, and I'm tired of people telling
me that I can.

> I would hardly call this level of adding extra markup anywhere close to
> other HTML where the presentation is completely ingrained.

Of course it's not completely ingrained. But I want it to be able to be
completely separated before I'm going to join your camp.

------
pj
Do we really want this kind of bickering around here? There's a time and a
place for every technology. Everything has pros and cons. There's no _perfect_
solution. There are lots of _good_ solutions. Sometimes CSS is one and
sometimes Tables are one.

Usually tables are used for tabular data. It is helpful for understanding what
is on the page. It helps the robots.

CSS knows nothing about the data. It doesn't care what's in whatever it is
making pretty and the robots are fine with that.

There's so much work to do. Why do we argue over these silly things. If you
can do it with tables, do it with tables. If you can do it with CSS, I'll pay
you 5 or maybe 10 dollars more per hour.

Look, for every weakness you can find in the CSS route, I can find a weakness
in the tables route. Try doing a fluid design with tables. Show me a search
results page that will automatically fill in tiles to fit the users'
resolutions. That's hard to do with tables, you have to use JavaScript and
it's nuts.

With CSS, just make them float left.

That's why CSS is cool, little things like that. Yes, Tables are easier, they
are. No one denies it. Easier does not make it better. Just because CSS has
_some_ flaws doesn't mean you shouldn't use it.

CSS is good, it's separation of data and presentation. It's division of labor.
It's not bad. It's good.

If you have an application for example and you want to let your users put
information anywhere using only one text file and without programming, let
them do it with CSS. That makes sense. Tables are hard to make dynamic...

Maybe that's the divide: static vs. dynamic

Static layout with tables, fine. Dynamic layout with tables, not fine.

Look, anyway, why all the animosity toward the CSS'ers? CSS is totally fine.
No need to be hatin. It's not a popularity contest, it's a technology that can
be used to do things.

~~~
jimbokun
Who are you arguing with? Mr. Garrett states very clearly that both tables and
CSS have a proper use.

------
nx
He makes a great point. Besides, your tables will work on more browsers than
the CSS layouts.

------
bouncingsoul
It doesn't matter if the logic behind using xhtml+css is flawed: the xhtml+css
evangelists have so saturated the development world with their propaganda that
I'm worried if I make an educated decision to use html 4.01 or occasional
layout tables it will hurt me when potential employers, clients, or even the
general webdev community review my code and think I don't know what I'm doing.

Does anyone else feel that way?

~~~
brianmckenzie
Yes and No.

It isn't just propaganda anymore. Pure CSS is what you're going to see in
almost every code base you might work on. The last several gigs I've had
wouldn't even allow tables for tabular data, which I think is ridiculous.

If I were reviewing your code, I'd give you points for using tables to deal
with tabular data. I might not even hold it against you if you used it in a
layout, depending on context. Unfortunately the person reviewing your markup
will probably expect pure CSS, even if it is data displayed in a table format.
Adjust your expectations accordingly.

~~~
eli_s
Wow - not allowing tables for tabular data - this just shows how much kool-aid
some people have drunk

------
wooby
A related argument against table-based layouts, which I don't see any
discussion about yet, is that "it's important to maintain a high ratio of
content to markup for SEO purposes."

In my view, a complicated div-based layout is just about as markup-heavy as a
table layout, given separate CSS files in both cases. So I would think the
point is moot. And my suspicion is it's just SEO firms blowing smoke in an
effort to figure out things to sell.

So, is this at all a substantiative claim?

------
jrockway
I agree with this guy -- CSS is horrible :)

One of my Great Plans For The Future is to write a language that abstracts
away HTML, CSS, and (some) JavaScipt. You describe your layout in a format
that makes sense, and the compiler will decide whether to use tables, CSS
hacks, or whatever.

Ideally, this wouldn't be necessary, but I've never written CSS without the
knowledge of the HTML it's going to be applied to, nor have I written HTML
without considering how to style it.

I am not being dumb, either. HTML needs all sorts of hooks for styles
(classes), since HTML doesn't have any meaningful elements. (Oh boy, I get
<p>, <strong>, and lists.) When I have done three-column layouts, my HTML has
always needed tweaking -- the content has to be in a certain order (usually
left/right/center, which is stupid), and it has needed hacks like <br
class="clearfix">.

So clearly we don't live in an ideal world; we are stuck with HTML and CSS the
way they are. It is time to abstract away the stupidity like programmers
abstract away the computer with high-level languages.

------
jneal
I'll stick with CSS. I've never once had to place CSS items out of order that
is a ridiculous statement. There is a place for tables from time to time but
once you actually "understand" CSS, life becomes much easier. I think the
problem with most people is, they are told to use CSS, but without guidance
they might not understand the core and basics.

~~~
axod
Please paste an update to the example, that just 'behaves' like the table
then? eg the background goes to the bottom, bad things don't happen depending
on size of the content etc.

I've never seen a css example that behaves like a table.

~~~
lhorie
Just out of curiosity... why do you want something that is not a table but
behaves exactly like a table? Isn't that what tables are for?

I think starting from the premise that CSS (as it is currently implemented by
major vendors) is a super set of tables, and as such, must do everything
tables do is misguided. From my experience, the absolute need to use tables
doesn't appear in every layout (for me, at least, it's rather rare), and
pragmatic CSS developers tend to use tables only as a fallback when CSS / IE /
whatever doesn't quite work.

I've seen css examples that can't be done with tables, so I don't know exactly
where we are trying to get with this line of reasoning.

------
run4yourlives
I would be more inclined to be sympathetic to the cause of the author, and the
ridiculous amount of people who upvoted this (wow, demographics change on HN,
pg wasn't kidding) were he/she to show more than a three hour understanding of
CSS.

Obviously, when you can produce something like this:
<http://www.csszengarden.com/>, showing how a single html page can be
manipulated in an infinite number of ways, it isn't CSS that's lacking, but
your knowledge of it.

I'm sorry if this isn't the popular opinion on this board, but as someone that
coded tables and then made the transition, I can assure you that css is a much
more powerful medium for web page layout, despite its quirks.

~~~
wheels

      > wow, demographics change on HN, pg wasn't kidding
    

Right Click -> View Source

~~~
bdr
I thought grandparent was referring more to the quality of the content than
the claims of the argument.

~~~
run4yourlives
I was thanks.

------
jacquesm
One of the most compelling arguments _for_ css is to use it rearrange the
content of your webpage so the most relevant content appears earlier in the
data. Apparently this can have a significant effect on your search engine
optimization.

~~~
euccastro
If it's your choice, making the most relevant content appear earlier in the
layout too (thus removing the need to reorder) sounds like a good idea.

------
bravesirrobin
One thing that CSS does especially badly that tables do well is correlated
sizing. It's easy with tables to make all the elements in a layout row all
have the same height. Doing the same in CSS is possible but requires so many
hacks that the net result makes you feel dirty.

I've watched this war for years now, and just wish both sides would give some
ground. As long as you do your layout with the fewest amount of tables needed
(trending toward zero), the you shouldn't need to guilt yourself out about it.

------
nw
Conceptually, styles and positioning are two different animals. We need a
tripartite model of 1) content, 2) styles, and 3) layout/positioning.
Unfortunately neither tables nor CSS handle positioning well in all cases,
hence the perpetual argument.

Maybe I'm just ignorant, but I've found it necessary to use CSS, tables, &
JavaScript (yes, all three) to produce acceptable dynamic layouts for web-
based apps. This is unfortunate.

------
Lucent
The paradox is that CSS was not meant for precise layout. It was meant to only
vaguely suggest a layout. That's why it deliberately excludes the ability to
force elements next to each other the way tables can and spread them out
evenly. It's not for generating pixel-perfect PDFs. It's for saying, "Hey, put
some content here, make it kinda look like this, and if it doesn't fit, let it
flow to the next line. No big deal."

Yet the people who are so gung-ho about how it's superior to tables are...get
ready: the people who think CSS is for controlling every pixel of a layout.
Those people should really be using tables not because they're easier for what
they want to do, but instead on principle!

Instead we end up with some horrible, disgusting hybrid. Pixel counters for
whom tables work perfectly instead abusing CSS to force a precise layout all
the while gloating about how they're doing something noble and difficult and
looking down their nose at those who do it the "easy way."

~~~
olavk
I thing you got that backwards. _CSS_ supports pixel-precise sizing and
positioning. However, CSS _also_ supports sizing and positioning based on the
properties of the viewport, which adapt better to different screen sizes. Both
approaches have advantages and drawbacks.

HTML-tables OTOH does _not_ support pixel-precize positioning, although you
can get some of the way if you combine it with transparent gifs, as people
used to do before CSS support became widespread.

------
olavk
This whole CSS vs. HTML-Tables discussion is ridiculous. It is not either/or.
There are some specific cases where Tables are superior over CSS, but many
things can be done with CSS which is impossible to achieve with tables.

This article explanin the _concrete cases_ where you should use tables:
<http://olav.dk/articles/tables.html>

The submission shows some examples where tables are needed. However, one could
easily show other layouts where HTML-tables would be useless and CSS is
necessary. Any serious web developer need to know the limitations of _both_
tools.

BTW. the submission also contains some major misunderstandings:

> when it comes to layout, the design of CSS is fundamentally flawed. Use
> tables instead

This is blaming the shortcomings of Internet Explorer on the design of CSS.
The CSS spec supports exactly the same layout model as HTML-tables, it's just
that IE doesnt support this CSS feature.

------
Klonoar
I'll tip my hat to the author for writing the first well-formed, non-ranting,
description of why one should use Tables over CSS (that I've come across),
though I'm sure with the amount of these people that are coming out of the
woodwork I'm sure I'll end up seeing more...

I still feel the need to disagree with him though. This kind of mentality is
counter-productive to the web moving forward - CSS can be a bit more difficult
at points, yes, but 90% of the issues that are generally encountered with it
stem from IE's horrific rendering engine. We've finally gotten to a point
where IE's market share is declining, and with that CSS based development will
only get easier.

On one last note, CSS is being adopted in more places than just the web - for
instance, there's various projects attempting to integrate CSS into the GTK
setup. If CSS was really that bad and unusable, do you think it'd be getting
any further adoption at all?

~~~
jrwoodruff
Just my two cents but I would say that this argument is not counter-
productive, but rather essential to the web moving forward.

Until CSS is improved, tables will never go away.

~~~
Klonoar
I guess the way I'm looking at it is that this argument has already happened.
CSS doesn't necessarily need to be improved, rather the browser situation
does, which is certainly not helping CSS to look better in comparison to
Tables.

CSS3 (and CSS 2.1, which is still not fully supported in some cases) have
various properties for forcing display models, but the caveat always ends up
to be IE6/7.

Though to be fair, I guess you're right, this argument is rather essential to
the web moving forward, I just have to wonder if this is really the argument
worth having.

------
GHFigs
I find his choice of "typical" CSS layout to be misleading, when neither his
site (which uses CSS, naturally), his blog (CSS), any of the pages he links to
(CSS), or this site (tables) use such a layout.

Yes, he chose it to illustrate his point, but that point doesn't connect to
the trollish overstatement of the title. It is evident that person can use CSS
for other layouts (even using floats) without ever encountering the problems
he describes. The real conclusion here is that CSS is hard or even impossible
for some desired layouts--something just as true with tables. I doubt that
that's news to anybody.

~~~
chairface
The auto-expanding equal height three column layout is such a standard layout
on the web, and ways to do it are so often requested that it is referred to as
the "holy grail" by the CSS community. So I find your critique and accusation
of trolling to be rather misplaced.

~~~
GHFigs
I did not say it was uncommon, I said his choice was misleading. It's a trick:
it allows him to demonstrate a problem with one kind of layout using floats
(which by definition do not behave like tables) but then claim it is generally
applicable to all layouts and CSS in general. It is not.

I stand by my statement that his title is a "trollish overstatement". It was
chosen for the sake of continuing argument, not reflecting the content,
educating, or informing.

~~~
chairface
You said it was misleading that he implied it was "typical", which is a
synonym for "common". You can take issue with his conclusions, but
illustrating your thesis with a common case can in no way be construed as a
trick.

~~~
GHFigs
You're missing the point. Yes, it's a _common_ case in that it occurs
frequently, but it is not a _typical_ case in that it is characteristic of the
whole set.

That is my problem with it, as stated for the third time. His conclusion
reaches far beyond what his carefully selected evidence supports.

~~~
chairface
And for the second time, "common" and "typical" are synonyms. Furthermore,
there is no one case that is "characteristic of the whole set". Apparently, in
order to satisfy you, a blog post (!) must cover every type of layout. Awfully
demanding, aren't you?

~~~
GHFigs
> And for the second time, "common" and "typical" are synonyms.

That two words can be synonyms does not mean they have only one shared
meaning. In context, a thing can sometimes be one but not the other, e.g. A
dictionary is a common type of book, but it is not typical of books to consist
of lists of definitions set in very small type on very thin pages.

I don't understand why you're insisting on interpreting the word as "common"
as I have already stated that that was not my meaning and in the context of
the article (in which the author uses a single example to reflect badly on the
whole) it's likely not that of the author's.

> Furthermore, there is no one case that is "characteristic of the whole set".

My point. I disagree with the author's attempt to depict _this_ case as
characteristic of the whole set of CSS layouts.

> Apparently, in order to satisfy you, a blog post (!) must cover every type
> of layout.

Hardly. I only wish for the author to restrict his conclusion to one that is
supported by his example.

------
dezwald
i hope this comment speaks for most.

In a perfect world, CSS is awesome.

tables are good, except when it comes to a point when you have to start
nesting tables within each other to format your your layout.

explanation is below: \---------------------------

people who love tables would switch over to CSS if it did what everyone(and
standards) makes it out to be and actually worked and/or rendered the same in
ALL browsers (css hacks don't count as css)

but no matter what you say about CSS....(and i'm all for CSS) ...CSS can't
solve all design issues...and if it can...it takes way to long to figure
out... and if only a 10 year veteran/css master can implement flawless layouts
then CSS isn't a practical language.

in theory is CSS is awesome!

i use tables for tables (tabular data) and i use CSS to layouts and comesic
design.

think about it...if CSS rendered the same way in every browser abiding by CSS
standards ...even developers who are pro tables...would switch over.

the reason why there is such conflict between tables and CSS is because many
of people have tried CSS countless number of times and hours trying to make
their template/layout work...however they've came across so many road blocks
...they give up.

i'm not saying tables are the ultimate design language...and i think people
agree....they just use it because it works. in ALL browers!

but me say ONE LAST THING!

its not CSS the language that is problem....is the number of browsers that
choose not to render CSS properly.

------
rgrieselhuber
I still don't get this debate. Before, it definitely used to be easier to just
use tables, but now there are so many examples and frameworks out there that I
never spend more than 20 minutes or so with CSS, even on very complex layouts.
What am I missing?

------
tripngroove
This is going to sound totally flippant, but I think it's always worth
considering sources... let's take a look at the author's site, and reflect on
how we feel about taking front-end design advice from this person.

~~~
jacquesm
I agree, so I read a bit further after looking at the page (which is,
conceded, not exactly a high point in design), here is an interesting bit of
information about the author:

<http://sitereservation.com/xooglers/index.cfm?entryid=16>

------
lsb
Okay, so why isn't "Center" centered?

With the CSS, Top Center Bottom are all centered, but with the tables, they're
not.

Edit: am I wrong? Why am I being downvoted? I'm on Mac OS X 10.5 Safari 3.2.1

~~~
irrelative
Even if they weren't, it's trivially easy to center it with CSS, or
attributes. In the td tag, align="center", or in CSS text-align: center;

Another pet peeve of mine with any CSS layout is that vertical alignment is a
huge pain. With tables, you can use valign="top" in the td, or via CSS,
vertical-align: top.

------
drawkbox
If CSS at this level of browser support isn't working for you then you are
doing it wrong.

------
eli_s
I think it's pretty obvious that often tables are better and more intuitive to
use for layout than CSS. The problem is that we've been told for so long that
tables for layout are bad that it makes one feel kind of dirty using them.

Web page layout should be simple it shouldn't require months/years of
experience to work around CSS limitations and browser quirks to get some text
and pretty pictures to display right.

Sometimes I spend (waste) hours working on a CSS layout because it makes me
feel clever, but lately I've been shrugging my shoulders, going the easier
route, sending an invoice and moving on :)

------
knieveltech
Fail.

------
jcapote
Have fun seeing your SEO go down the drain.

Also there are tons of CSS frameworks which do enforce layout semantics,
possibly even better than tables ever could.

~~~
motherwell
> Have fun seeing your SEO go down the drain.

What rubbish are you reading? Tables vs css make zero difference. never has,
likely never will, for all the obvious reasons (why bother? What difference
does it make to users etc).

~~~
dchest
I'm not a SEO expert, but I think the commenter referred to the fact that you
can position _content_ before _navigation_ with CSS.

