Question

I'm not expert in CSS in any way; I know it to some extent but not very deep; float and IE6 makes me cry. So I'm always excited to see what people can do with it.

However, most of the examples that I see use fixed dimensions. As far as I understand this is because CSS is so tricky and it's much easier to hack when elements have width, especially in IE6.

But, I really like flexible width. And being so, I don't understand why it's wrong to make design with tables? There's a book called "Everything You Know About CSS Is Wrong!" which explain how it's good that now we can do table layouts with CSS with recent browsers... but, couldn't we do it all the time with HTML tables? Yes it's not CSS and maybe not as clean as pure CSS... but, after all, table layout IS what we often need, and if we have to choose between wicked hacky CSS to do it and simple-but-not-pure-enough HTML table, I don't understand why any of these choices should be considered bad. KISS is a good thing, isn't it?

Or, maybe I don't understand it and you CAN make table-like layouts in CSS - that work in IE6 - without too much pain in the ass? Any examples of such sites?

UPDATE: Yes I know about content and style separation. In fact, I'm fanatic about DRY, SRP and other design must-do things. That's why I really tried to do things in CSS; but if it's SO much harder and more unreliable than tables, such that it's even written in books like mentioned above, why try so hard? I do not say that everything must be done in tables; but if it's really easier than CSS - why should I prefer CSS to a simple and predictable solution?

That is, I do not say that you should use tables always. Keep in mind master page layout - it's independent and do not affect other pages, I can switch from CSS to tables and back in 20 minutes (in fact I did so already) with no problem - WHY should I stick to CSS even though tables are no harm?

UPDATE: I've found this to be a very good summary of what I was trying to say: http://www.flownet.com/ron/css-rant.html. And the discussion http://rondam.blogspot.com/2009/02/why-css-should-not-be-used-for-layout.html#comments.

For those who's interested, here's an even better article: http://kv5r.com/articles/dev/layouttables1.asp

Was it helpful?

Solution

You are essentially right. There is nothing really wrong with using tables for layout as long as, for accessibility, the order of the cells is appropriate for the page. I personally find fixed-width a much worse degradation of usability than tables-for-layout.

When you do use tables for layout, be sure to use the styles width: 100%; table-layout: fixed (and <col> with a styled width) so that browsers can lay the table out correctly from the start (which fixes one of the usability problems table layouts had), and so that you're not reliant on IE's rather poor auto-layout width-guessing.

Whilst I certainly prefer CSS for layout wherever possible, and most simple site layouts can be reasonably achieved using only CSS (especially now IE5 and its Quirky Box Model is gone), there are some cases where CSS can't hack it and tables can. A common case is complex fluid-width forms.

The most significant problem is the lack of ability to say things like width: 100%-10em to get a column that's the width of the viewport minus a fixed size for another column. For the simple cases you can get around this with margins and a wrapper div, but once you start re-ordering the elements on your page and adding multiple wrappers just to get the CSS layout to work, you're already mixing up the presentation with the content: not really so very different from tables.

In the worst case you end up with those silly ‘CSS frameworks’ that require you to use nesting and fixed class names to completely specify the layout inside the markup itself. This is no better than tables at all; I find it absolutely hilarious that this hopeless throwback to the bad old days is considered a trendy cutting-edge Web 2.0 technique.

CSS3 is working on some interesting alternatives to current Positioning options that may one day deliver on the promise of total markup and layout separation. But that's a long way off today.

OTHER TIPS

Have a look at Yaml and Fluid 960gs. Both help you a lot with cross-browser layouts. Table-Layouts are not the answer and IE6 will vanish sooner or later.

There is a reason that HTML tables are bad for anything else other than tabular data. HTML is a markup language for data content and thus should contain groupings of actual data, not the layout for that data. CSS is meant to be completely for layout and style purposes; thus its name. Therefore the CSS should contain the entire look and feel of the webpage while the HTML contains the structure for the data; and never the twain shall meet.

Doing everything in tables is bad for a reason.

You should think of it as the abstraction between style and content and you can get a good rundown from here: http://www.alistapart.com/articles/separationdilemma/

Also in direct answer to your question goto 'A List Apart' and search through your articles. They kind of describe the journey you're about to make here: http://www.alistapart.com/articles/journey/

why should I prefer CSS to a simple and predictable solution?

That's what we're trying to say. It may seem easier in the short term but anything that you write will be less maintainable and harder to edit in the future. You can go and write a webpage that seems easier in the short term but you're just stabbing yourself in the foot really for later when you want to do more. Why not just do it right the first time round? (it's only a small amount of extra effort really)

Just because CSS layout is a challenge for you, that doesn't make it inferior to tables. By stating this, you're committing a logical fallacy known as the Relativist Fallacy.

Once you fully understand CSS, how to use it, and most of the different browser quirks, you will find that it is vastly superior to HTML Tables.

Markup should be semantic. That is, it should accurately describe the content that it contains. That makes it machine readable (for SEO and other applications). Tables for layout is not semantic at all.

Abstraction of different layers helps to make a website much more easier to maintain. Keep the content in the HTML, the behavior in the Javascript, and the presentation in the CSS.

You are right that CSS has its shortcomings, though. But tables have many more, which are much worse.

The reason you don't want to make markup that uses tables as the layout is because of the decoupling of design and content.

Your markup should sit, on its own, as a perfect description of the content that is in it. Essentially you should mark up your pages in html before you ever touch the styles. Then you would use CSS to modify the way that your semantic markup looks by default.

The fact of the matter is that your web content that you are laying out is not 'Tabular data' - Markup is for computers/bots to read, and styles are for us to see, mixing the two just confuses one or both parties, usually at the added cost of maintainability.

Here's a scenario which I encountered personally which I'll like the share. Note: I'm not advocating "no-table-at-all", it does come in handing for other requirements.

I've created a form (visually top-down flow):

Heading1
 Label1 
 Textbox1
 Label2 
 Textbox2

Heading2
 Label3 
 Dropdown3
 Label4 
 Textbox4
 Label5 
 Textbox5

Then customer wanted a more structured tubular one like this:

Heading1
Label1 Textbox1     Label2 Textbox2

Heading2
Label3 Dropdown3    Label4 Textbox4
Label5 Textbox5

As I am not using table of the TR TD sort, I can easily (almost) convert the structure using CSS modification and minor HTML markup changes.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top