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.

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.

They live in their inbred web standards blog world where they have a very polished view of what is "semantic" and what it means to separate content and presentation. All the while completely oblivious to the ecosystem in which web standards live and the constant tradeoffs that must be made in any software system.

Ignoring what should be obvious: there's precious little semantic information in an HTML document. The standardized tags are all but completely presentational. Naming CSS classes strictly according to some pedantic definition of "semantic" meaning "not presentational" is deluded. First, because we add classes to things because need a hook for presentational purposes. Second, because 99% of the time, the actual goals of writing HTML/CSS are presentation, concision, maintainability, and maybe SEO. It turns out you should name your classes descriptively, which may align with a semanticist's notion of best practice 80% of the time. But then the remaining 20% of the time they'll rip you new one for use class="red" instead of using a half-dozen "semantically pure" names like class="slightly_more_important_block", class="second_heading_in_a_row", class="something_i_just_want_to_be_different", class="sometimes_i_just_want_to_be_different", class="why_web_design_sucks_in_96" and class="i_love_you_man"

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.

http://shouldiusetablesforlayout.com/

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.

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?

You're tapping into a quite a bit of psychology there :) I've been thinking about the idea of popularity as a measurement of "goodness" (think PHP vs Python), and I think in the end, the answer depends on the programmer.

Some might like to get things done quickly so that their not-necessarily-geeky idea is off the ground early (which is arguably a strong factor for a technology's popularity), and some might prefer to "invest time" and learn about complicated problems (scalability, for example) as they go along. I'd say things are (as usual) a mix of both extremes, so we need to prioritize what's important to us.

As far as tables vs css goes, I find that tables make layouts easy for the average person to visualize while building it, but css is far easier to maintain (especially when you are responsible for maintaining/revamping 50+ stylesheets per year in sites and apps of varying degrees of complexity - think heavily widgeted layouts)

Beautiful.

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.

We have decades of experience with real layout models in both traditional graphic design software and in developmental software that has layout manager.

And nobody thought that being able to flow several columns on a webpage would be useful?

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.

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

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.

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.

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.

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

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?

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!

http://pastebin.com/f51ee9672

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.

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

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

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.

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.

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.

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

If it's tabular data ALWAYS use tables.

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

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.

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.

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!