
Tables vs CSS: CSS Trolls begone - iamelgringo
http://iamelgringo.blogspot.com/2009/02/tables-vs-css-css-trolls-begone.html
======
dasil003
Lets call them zealots since they're mostly not really trolls.

CSS zealots are a lot like TDD zealots. Both CSS and TDD have huge, _huge_
benefits that you shouldn't write off before you actually take the time to
learn them. The problem is the zealots talk about them as panaceas and ignore
the fact that there is no one methodology that separates the pros from the
amateurs. Instead they use their expertise in one tiny niche to prove to
themselves how their work is so much better than the majority of similar work
due to a few arbitrary criteria. Then they form small self-congratulatory
communities to pat themselves on the back about how brilliant they are and how
much everyone else could learn from them.

These are the people who you find trolling your blog. Usually they aren't even
particular skilled at what they do, which is why they cling to dogma and feel
the need to attack other people.

But let me be clear. I haven't layed out a website using tables since 2001
(and I used tables for 5 years before that), once you develop your mental
model of CSS (and browser deficiencies) there are actually only a few edge
cases where tables are easier. CSS can actually solve 90% of web design
challenges more elegantly than tables. CSS makes it easier for designers to
and developers to work together (I am both). There are many techniques which
are only available in CSS. All future technical developments in web design
will be in the realm of CSS.

So it really is worth the time to slug it out with CSS and figure out what's
what. That said, web design coding (ie. HTML/CSS) is just one tiny piece of a
huge potential set of web development skills. Why does google put CSS inline?
Because their design considerations are driven by 100 things that are so far
over CSS Zealots heads they can't even fathom it: scalability, latency, back-
end HTML generation, js compiled from other languages, etc.

~~~
iamelgringo
RE: _Why does google put CSS inline? Because their design considerations are
driven by 100 things that are so far over CSS Zealots heads they can't even
fathom it: scalability, latency, back-end HTML generation, js compiled from
other languages, etc._

From: [http://www.fastcompany.com/magazine/100/beauty-of-
simplicity...](http://www.fastcompany.com/magazine/100/beauty-of-
simplicity.html)

 _But the original [Google] home-page design was dumb luck. In 1998, founders
Sergey Brin and Larry Page were consumed with writing code for their engine.
Brin just wanted to hack together something to send queries to the back end,
where the cool technology resided. Google didn't have a Web master, and Brin
didn't do HTML. So he designed as little as he could get away with._

~~~
markup
What does the design of google back in 1998 have to do with the inline CSS
argument?

~~~
iamelgringo
I have a big hunch that design decisions at 75% of Alexa's top 20 sites aren't
really based on CSS idealogical purity, scalability, algorithmic complexity or
back-end html generation issues. I think those decisions are based on plain
and simple expediency and frustration. Much like my decision to go ahead and
use tables.

I think that's what guided Google's decision in 1998, and I still think that's
what guides their decisions now.

~~~
markup
What guided Google's decision back in '98 was to deliver the most kickass
search engine ever, the sooner the better (I guess). From that point to now
it's a matter of perfectioning every single aspect of their creature, to
ensure a great UX (therfore fidelization).

What makes a great UX? A clean UI, a fast service and possibly no hiccups (to
make it very short). The UI has changed _a lot_ from 98 to now (check out
web.archive.org) and so did their HTML code. A _single line_ HTML page is
obviously a conscious decision and so is the inline CSS.

I don't know you, so I have no idea on your experience in this field, but when
you get to deal with I'm not saying huge, but decent amount of users you
simply _have_ to deal with scalability under every single aspect. If you
don't, chances are you end up delivering a crappy service OR you spend WAY
more money (bandwidth, cpu power, etc) than you actually need to.

EDIT: google is obviously more than html and css, and if you really want to
have an idea on how they are paranoid with performances you should check out
their google app engine documentation.

------
Jasber
The people preaching 100% CSS design are purist, they're people that love
design and love CSS. These are the Eric Meyers, Doug Bowman and David Shea's
of the world.

The way you see beauty in "perfect" code, they see in pure designs.

But there are benefits to their methods. Usability, accessibility, SEO,
increased caching and reduced page load times are all side-effects of "pure"
CSS designs.

I'd suggest taking the 80/20 approach to CSS. Take the best of what works and
then just get it done and move on.

Also, my time limit for CSS problems is 1 hour. After that I use the best
solution instead of the perfect one.

~~~
ssharp
What does "pure CSS" page offer in terms of usability and accessibility that a
mixed-use table/css page wouldn't?

If anything, CSS would be worse as its difficult to render the same across all
the different browsers and platforms. With fixed width tables, you can pretty
much guarantee your results.

I'm not advocating either and tend to try to use as much CSS as possible but
sometimes you spend twice as long to achieve an inferior result. After many
years of working with HTML, I think most people find that happy medium.

~~~
dpifke
In theory, it offers better separation of content from presentation. For
example, a news article that renders in one column on-screen and two columns
printed. Or that renders as columns for a sighted user but is read aloud in
the correct order for a blind user.

~~~
neilk
It doesn't, not even in theory.

CSS did a good job of freeing us from layouts that were dominated by concrete
layout, stretchy invisible gifs and so on. But CSS does not separate content
and presentation. CSS still depends on concrete layout to work. You often
can't have a feature of your style that doesn't have a div or whatever
attached to it. (The pseudo-selectors are a horrible hack to try to fix this.)

The problem is that we were all collectively duped into not wanting things
that CSS didn't give us.

An example: I used to lay out the music and entertainment section of my
college newspaper. With CSS, you can't even do a multiple column layout that
flows, and PageMaker had that on day one.

Sometimes, I would design a headline that ripped right through articles in the
middle of the page. Even diagonally. I can't imagine how you could do that in
CSS, without tedious calculations and placing concrete divs into your text.

Even if some of what I've said is possible, very, very few designers seem to
be able to cope with this. The evidence is that most of them struggle just to
get two-column layouts that don't even flow, if one judges by the number of
tutorials.

------
tdavis
Article summary in 3 sentences (apply these rules to whatever you want, not
just table usage!):

If big sites do it, it must be okay!

If I can't be bothered to do proper research to learn _why_ one should not use
technique X, the reasons must be trivial and stupid!

If I am too lazy to learn how to do something properly, I must justify doing
it improperly _somehow_!

\------

I haven't used tables for page layout in roughly _a decade_. I think I used a
table improperly for the first time since then last week, when I was laying
out a form and couldn't get it to render consistently after a Javascript
update. I don't consider this the end of the world, nor do I take it to mean
that CSS is unnecessary and I'm going to go back to pretending it's 1999.

The problem with sensationalist bullshit like this article is people will read
it and form an opinion based on it, without doing their own research. Do your
own research (and looking at the table counts of Alexa Top 100 sites doesn't
fucking count as _research_ , FYI). Learn the _real_ reasons why you shouldn't
use tables for layout (or why to adhere to various other web standards). If
you don't find those reasons compelling enough to switch, _then do whatever
the hell you want_ \-- at least you know _why_ you're doing it.

Learn that if you choose to use the proper methods, all the layouts have
already been made for you, so you can be as incompetent as you'd like and
still layout a page better than Google (and yes, Google are complete shit bags
when it comes to adhering to Web Standards. Thankfully, what Google does
should be irrelevant to you!) Finally, at the end of the day, just because you
use tables occasionally doesn't magically mean CSS IS DEAD. I can't think of a
sufficiently funny metaphor for this obvious fact because I am too god damn
pissed off.

~~~
randallsquared
"Do your own research (and looking at the table counts of Alexa Top 100 sites
doesn't fucking count as research, FYI)."

Yes. Yes, it does count as research. When you see people who have done what
you want to do, looking at how they did it _is_ likely to guide you in how you
should do it. That doesn't always work, but it's a damn fine start.

~~~
tdavis
Even if I concede that it's a damn fine start, it is not research sufficient
to jump to the conclusion that (a) CSS layouts are overcompensating (based on
a "hypothesis" taken out of thin air) and (b) people who believe using tables
for layouts is bad are wrong based on said research.

Edit: He also managed to not even properly conduct this simplistic research
considering that many of the tables used on the sites were used correctly,
e.g. for _tabular data_.

------
JoelSutherland
The CSS Problem has been solved. There are a large number of people in the
world who can take any arbitrary design and make it work in all browsers using
compliant XHTML/CSS.

In fact, there are so many, that the rate to do such a think is between $100
and $200:
[http://www.google.com/search?hl=en&rlz=1C1GGLS_enUS291US...](http://www.google.com/search?hl=en&rlz=1C1GGLS_enUS291US304&q=css+slicing+service&btnG=Search)

In my mind this leaves only two defenses for not having a website done in
(roughly) proper CSS + HTML:

1\. You believe that it is _better_ to layout pages in tables.

2\. You can't do it personally and don't have $150

~~~
pg
Or

3\. You just don't care.

which is by far the most common explanation in all situations of this type.

~~~
JoelSutherland
I fail to see how that is different than #2? Maybe I should have said "don't
want to spend $150".

------
shaunxcode
Dude what you need in your life is something like malo. It allows the
simplicity and elegance of the nested tables paradigm but with out the cruft
of using tables! <http://code.google.com/p/malo/>

Personally I have an abstraction layer which allows me to express my layouts
as s-expressions and then be rendered either as "html" (tables, great for
quick development) and then rendered to "xhtml" (divs + css) for when I am
polishing things up.

Right now it is written in php (yes the s-expression reader and everything,
and yes it caches the interpreted files so the overhead is worth it) and I
plan on releasing it on googlecode when I am happy with the "interface" of
required methods for each "layout adapter".

edit: I forgot to mention malo is like 9 lines of css w/out comments.

~~~
jaxn
Thanks for the pointer to Malo. I have looked at 960.gs and Blueprint as well
before I decided to use use CSS Reset and then my own layout using the same
technique as 960.gs

------
mattmaroon
Inlining styles can be a good way to boost performance for webpages that tend
to be viewed once and left, like Google or Yahoo's home page.

<http://developer.yahoo.com/performance/rules.html>

It seems as if having external CSS is only good for scalability due to
caching. If you knew a page wasn't going to be revisited, you would inline it
to save an extra http request.

------
willwagner
I'm not a CSS purist by any means but I think heavy use of nested tables can
be a real hassle for the visually impaired. I think if you find yourself
putting a table within a table strictly for layout, you should at least
consider other alternatives.

Personally, I like using tables for forms, which makes it relatively easy to
line things up for both the labels and the input elements, and it also makes
the css rules fairly straightforward to read. I'm sure CSS purists might
disapprove, but I think it's a good tradeoff and hopefully not much of an
additional hassle for screen reader users.

------
jballanc
I'm sorry but I don't see how you can write an article comparing Tables to CSS
and not mention Internet Explorer...not even once! In my experience, the only
reason I've resorted to tables for layout is when I need to worry about IE
compatibility (well, that and when I actually want a table).

This is also why the author's argument doesn't interest me in the slightest.
Claiming that "all the popular sites" use tables is nothing more than an
appeal to authority. Furthermore, it's a blind appeal since the author doesn't
even consider the backwards compatibility logic in using tables.

If you're going to tell me why tables are better than CSS, then tell me why
tables are better than CSS. Don't just show up to the argument with a bigger
gun...

------
sjs382
Am I the only person who finds CSS easier to write and easier to wrap your
head around? I don't think I could go back to tables without a significant
effort in changing the way I do things. CSS has just become natural. Maybe the
author just needs more experience or practice.

------
cakeface
I've always been confused by google's use of tables and inline styles in their
homepage also. Is it to shrink the file size and send less over the wire? Is
it to maintain support for IE 4 or some other archaic browser?

Using one of the css frameworks like yui grids or malo gives you table like
designs quickly and easily. Yeah there could still be cases where a table is
easier for layout but I feel like there are less and less excuses for that.

~~~
bk
Tables probably for cross-browser support with minimal code size.

Inline css and javascript for 1 http request instead of 3. Much faster, and
less load. The content-length of the google home page is 2752 bytes (gzip).

------
mcargian
Is there any reason you can't use an unordered list with one of the pre-made
jquery tree plugin's to give indentation, collapse and expand?

<http://jquery.bassistance.de/treeview/demo/>

~~~
iamelgringo
It would probably work, but then, you're creating a work-around for a CSS
shortcoming with javascript.

~~~
GHFigs
How so? You'd be effectively solving the problem using both CSS and JavaScript
they way they were intended, as opposed to using tables for layout, which has
always been a hack around HTML's lack of any other layout support. Seems like
if you're going to reject one approach on the grounds that it's too hackish,
it'd be the other one.

------
lisper
<http://news.ycombinator.com/item?id=463234>

------
zain
Really? You use Photobucket and Rapidshare as examples of sites whose design
examples you want to follow?

I'm certainly not a CSS purist, but I'm sure you could've found better
reasoning than "all the big guys use tables, so I should too."

~~~
webwright
He's not saying they have wonderful design. He's saying that most of the top
sites liberally use tables, which is interesting given that they probably have
some pretty great devs and an infinite budget.

I've walked the same road as the author has and currently use tables for
layout and CSS for text style, paddings, margins, borders, colors,
backgrounds, rollovers...

------
poppysan
He references Google finance. Google finance only uses tables for tabular
data, not layout which goes against his own point....

I completely think this is cheer leading for anti-CSS trolls.

------
vaksel
as long as it works, it doesn't matter if you use CSS or tables. The end users
just don't care.

------
tlrobinson
I'm very wary of people who cling to principles as if they're sacred truths
that shall never be broken. I think these sorts of things serve better as
guiding principles.

------
jlft
Learn the pros and cons and then use whatever fits the job better.

------
volida
what? i think you are focusing on the wrong problem people.

