tags:

views:

309

answers:

6

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

+4  A: 

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.

Fabian Buch
This is one of the rare answers that is helpful and answers my question ;-)
queen3
YAML - slow. FireFox has really big problems scrolling its forms example.
queen3
960 looks good, though doesn't seem to be obvious to easy or learn. I'll have to investigate, but thanks.
queen3
Hmm, seems like 960 still uses fixed width cells, even though it's expressed in percents. 5% width is not good; I need width based on content.
queen3
`display:inline-block;` will fit the width of the content...
Alex Sexton
A: 

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.

Alex Sexton
+1  A: 

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)

Robert Massaioli
Because YAGNI (you ain't gonna need it) still applies here. It's SO much easier to do in tables. And if (and only if) I can't do in tables, I'll switch to CSS (calling for smart CSS designer of course). I do not say this should be for everything; I always try to use CSS; but for site layout which is single instance in master page and does not affect anything - WHY should I bother? I would be easily convert it to CSS without affecting anything - IF I need to. But I don't do premature optimiz... CSS-zation.
queen3
And here's a quote from your journey link: "For instance, the WaSP’s site has always been standards-compliant, and has always used CSS to control its typography. But the layout is done with HTML tables so the site will work in any desktop browser.". Huh?
queen3
@queen3 the journey document is 8+ years old, back then browsers that self-ignited when confronted with high doses of CSS were still more common.
fvu
Your argument really does not hold up with me. This is not premature. How is doing something right the first time round premature optimisation?... or CSS-zation as you put it. And you should program to standards and agreed conventions first and make hacks for browsers later. (Just look at ROR to see how successful that is; using conventions) It seems like a much larger premature move to specifically break convention just to support dated and non-compliant browsers. But i'm done trying to convince you; you seem pretty certain that you want to go down that path, do what you will.
Robert Massaioli
No I'm not (or I'd accept bobince's answer right away). One part of my question is can I see an example of a site with flexible layout (width based on content) that is done pure-CSS? I've only seen two examples (960 and YAML) and they're either fixed-width or slow. And I can't program for standards; I have to program for IE6 and only then for other browsers.
queen3
For example, the current alistapart site: when I resize my browser, it doesn't resize it's content. While it may be appropriate for some designers, that's what I look for to avoid.
queen3
And here's the quote about semantics of the tables and layouts that I agree with: "The reason this was so easy is that tables have the correct semantics for doing layout. CSS doesn't". (c) http://www.flownet.com/ron/css-rant.html.
queen3
A: 

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.

o.k.w
My question came (among other things) from the same reason, customer wanted to restructure the site. And I found it MUCH easier to tweak both master page and site.css than ONLY site.css. To me, converting to table structure was the easy answer. In your case, I'd have several TD's with the old IDs - so almost everything in CSS still applies, and it's easy to arrange table like your new design. And since page layout and CSS work together, I don't see why I should strive for CSS-only solution so that I don't have to touch HTML markup.
queen3
@queen3: Yes, you've got your point. For my case, I've programming markup's together with HTML. So a designer can work on the CSS files without touching (almost) the form file itself. Like I said, I'm not saying CSS-layout is the only way to go, 'traditional' table still gives a better sense of confidence and control (in some ways).
o.k.w
+3  A: 

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.

bobince
+1  A: 

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.

Kevin C.
I do not agree that tables for layout is not semantic. They are - I want may layout be table-like, with 3 cells on top, and two on bottom... this is the semantics of my layout, not 5 divs. And the fact that CSS invented table-layout just proves that. And I'm not alone, actually, here's the quote: "The reason this was so easy is that tables have the correct semantics for doing layout. CSS doesn't". (c) flownet.com/ron/css-rant.html.
queen3
Yes, tables do not allow rearranging with CSS so users lack this ability... and so on... but unless I know that users need that (and since I work with IE6 you can imaging that corporate users won't need that) why should I bother?
queen3
Could you post some links to designs that you think are un-doable in CSS?Semantics in HTML is not about the "semantics" of your "layout." It's about the semantics of your content...this is a header, this is a paragraph, etc. A table is for tabular data. That's what the W3C spec says.
Kevin C.