CSS layout without fixed width
I am in no way good at CSS; I know this to some extent, but not very deeply; float and IE6 makes me cry. So I'm always happy to see what people can do about it.
However, most of the examples I see use fixed sizes. From what I understand, this is because the CSS is so complex and much easier to hack when the elements are wide, especially in IE6.
But I really like the flexible width. And being that, I don't understand why it is wrong to design with tables? There's a book called "Everything You Know About CSS Is Wrong!" which explain how good it is that we can now do table layouts using 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 in the end, the IS table layout is what we often need and if we have to choose between evil hacky CSS to do it and just -but-not-pure-enough HTML table, I don't understand why any of these options should be considered bad. KISS is good, isn't it?
Or maybe I don't understand it and you CAN do table layouts in CSS - that work in IE6 - without any extra pain in the ass? Any examples of such sites?
UPDATE: Yes, I am aware of the content and separation of styles. Actually, I am fanatical about DRY, SRP and other projects to be done. This is why I really tried to do things in CSS; but if it is so much more complicated and more unreliable than tables, so it is even written in books like above, why bother so hard? I am not saying that everything should be done in tables; but if it is really simpler than CSS - why should I prefer CSS for a simple and predictable solution?
That is, I am not saying that you should always use tables. Keep in mind the layout of the main page - it is independent and does not affect other pages, I can switch from CSS to tables and back again after 20 minutes (in fact, I did it already) no problem - WHY should I stick to CSS even if the table is no harm ?
UPDATE: I found this very good summary of what I was trying to say: http://www.flownet.com/ron/css-rant.html . And a discussion http://rondam.blogspot.com/2009/02/why-css-should-not-be-used-for-layout.html#comments .
For those interested, here's an even better article: http://kv5r.com/articles/dev/layouttables1.asp
source to share
You are essentially right. There is nothing wrong with using tables for layout, as for accessibility, the cell order is appropriate for this page. I personally find that fixed width degrades usability much worse than tables for layout.
When you use tables for layout, be sure to use styles width: 100%; table-layout: fixed
(and <col>
with styled width
) so that browsers can lay out the table correctly from the start (which fixes one of the usability layout tables), and so you don't depend on IE, not because for poor auto-guessing layout.
While I certainly prefer CSS for layout wherever possible, and most basic site layouts can reasonably be achieved using CSS alone (especially IE5 and its Quirky Box Model are gone now), there are some cases where CSS is not can hack it and tables can. A common case is complex fluid width shapes.
The biggest problem is the lack of the ability to say things like width: 100%-10em
to get a column that's the viewport width minus a fixed size for another column. For simple cases, you can get around this with margins and a wrapper div, but once you start reordering elements on your page and add a few wrappers just to get the CSS layout to work, you're already mixing presentation with content: not much different from tables.
In the worst case, you end up with those silly "CSS frames" that require you to use nesting and fixed class names to fully specify the layout within the markup itself. It's no better than tables; I find it absolutely amusing that this hopeless throwback to the bad old days is considered a fashionable Web 2.0 best practice.
CSS3 is working on some interesting alternatives to the current positioning options that could one day provide the promise of complete markup and markup. But this is far from today.
source to share
Check out Yaml and Fluid 960gs . Both will help you with multiprocessing layouts. Tabular layouts are not the answer, and IE6 will go away sooner or later.
source to share
There is reason to believe that HTML tables are bad for anything other than tabular data. HTML is a markup language for data content and therefore should contain the groupings of the actual data, not a layout for that data. CSS should be entirely for layout and style purposes; thus its name. Therefore, CSS should contain the entire appearance of the web page, while HTML contains the data structure; and will never meet them.
Doing everything in tables is bad for some reason.
You have to think of it as an abstraction between style and content, and you can get a good rundown from here: http://www.alistapart.com/articles/separationdilemma/
Also in the direct answer to your question goto 'A List Apart' and article search. They describe the journey you are about to do here: http://www.alistapart.com/articles/journey/
Why do I prefer CSS for a simple and predictable solution?
This is what we are trying to say. This may sound easy in the short term, but whatever you write will be less maintainable and harder to edit in the future. You can go out and write a web page that seems easier in the short term, but you just stab yourself in the leg really for later when you want to get more done. Why not just do it right the first time? (this is just a small amount of extra effort)
source to share
Just because CSS layout is a problem for you, it doesn't make it inferior to tables. By pointing this out, you are committing a logic error known as "Relativist Error".
Once you fully understand CSS, how to use it, and most of the various features of the browser, you will find that it is vastly superior to HTML tables.
The markup must be semantic. That is, it must accurately describe the content it contains. This makes it machine readable (for SEO and other applications). Tables for layout are not semantic at all.
Abstraction of different layers helps make the site much easier to maintain. Store content in HTML, behavior in Javascript, and presentation in CSS.
You are correct that CSS has its drawbacks. But tables have a lot more, which is much worse.
source to share
The reason you don't want to do markup that uses tables as the layout has to do with the decoupling of design and content.
Your markup should sit on its own like a perfect description of the content it contains. Essentially you have to tag your pages in html before touching the styles. Then you have to use CSS to change the way your default semantic markup looks.
The point is that your web content you are planning is not "Tabular Data" - the markup is for computers / bots to read and the styles are visible to us, mixing the two just confuses one or both sides, usually with the added value of maintainability ...
source to share
Here's a scenario I ran into personally that I will love. Note. I am not advocating "no-table-for-all", it is suitable for other requirements.
I created a form (visually from top to bottom):
Heading1
Label1
Textbox1
Label2
Textbox2
Heading2
Label3
Dropdown3
Label4
Textbox4
Label5
Textbox5
Then the customer wanted to create a more structured tubular shape:
Heading1
Label1 Textbox1 Label2 Textbox2
Heading2
Label3 Dropdown3 Label4 Textbox4
Label5 Textbox5
Since I am not using the TR TD sort table, I can easily (almost) transform the structure using CSS modification and minor HTML markup changes.
source to share