I've been trying to get rid of table layouts for a while, apparently they are bad.

DIV layouts have some good things about them, but some things are a fucking pain in the ass. Like getting div's that adjust size to content to line up with other divs. The fucking cawk smokers just don't want to line up. And that is something table cells do without even thinking about. Plus there's all kinds of different fixes for different browsers. Tables don't give a shit about browsers.

After being pissed, I took a look at w3schools source, and their layouts are in tables!

I think the problem with tables was only the BAD use of nested nested nested tables tables tables....

Big over-arching tables are still the best way (IMHO) to provide your base layout for fully liquid designs. But the document types have also rendered some table tricks invalid too, so you lose either way. CSS has a lot of hacks to make liquid designs work consistently.

I'm finding out about the hacks, bit by by. But it seems like some basic stuff that should have been built in from the beginning. CSS has some great stuff, don't get me wrong. It's just the basic functions of laying out a page that are making me buggy.

you should look into one of the css frameworks. blueprint, 960 etc.

Tables are meant for tabular data, not for markup. There's no harm in using them for markup, but it's not semantically correct. Proper division between semantic content, markup with stylesheets and a page's functionality is all the rage with the kids these days.

Stick with it - it's worth it in the end.

Using css is so much more versatile than using tables. It takes a little to get your head round to start with but once you stop thinking in 'tables' it all comes together quite naturally.

Also, and this has been said a few times on 12s, develop in FF using the Firebug extension and then tweak with an ie specific stylesheet to overide as necessary.

There are also a couple of great little tools for developing for ie (back to 5.5) here.. ietester will render your url for all available versions of ie from 5.5 to 8.

Install the toolbar and you get firebug like debugging tools for css etc. And compact.js lets you debug in javascript.

I'm also going to recommend firebug lite for debugging in IE. It lacks functionality and is not 100% stable, but it beats the IE developer toolbar and can be injected with a bookmark.

well a table is designed for something to be tabular, which in my opinion means having ANY row requirement. Hence html's lack of a tc tag for a table column. Columns don't make a table, sensible rows do.

So if your page design has a head, content area, and footer, you got yourself a table. Within that there may be parts that are unrelated to any row structure, and those ought to be divs, spans, 'p's, etc.

If you find you cannot extract a table row and display it individually without breaking then you used a table where it shouldn't have been used.

Qualify your table, make sure it makes sense, and code guilt free.

HERESY!!!!

I can see your point, but a table with rows denotes tabular data.

Three divs (--> from "divisions") with IDs of "header", "content" , "footer" will do the same job and are more flexible.

For example, on several sites, for SEO purposes, our "header" is below the "content" in the HTML structure. You could not achieve the header appearing above content, but actually coded below, with a table layout.

Post-initial-design changes would require more work with tables than with divs, including more etc

I think using a "div" is semantically more sensible than tables.

Plus I hate tables, after supporting a site for 7 years that had up to 8 levels of nested tables.

Originally posted by: persist So if your page design has a head, content area, and footer, you got yourself a table.

Gotta say I'm surprised to hear you say that Persist. I think it's just a really stretched definition of what a table is to allow the use of tables for layout.

What benefit, apart from layout, is there to that approach?

IMO we should all abandon tables for layout, for our own sakes. If you choose to use a table for layout that's fine, but be aware that you are using a hack, and that you can't rely on your hacks being supported in the future.

The main disadvantage of a table IMO is that by its nature its layout is pretty much fixed. By defining the structure of your page semantically, (in theory at least) with CSS you can then change the layout without altering the structure at all.

Yes CSS can be a pain in the ass to get right -- believe me I've had my fair share of "Jesus Fucking Christ why doesn't this fucking work?" moments with it -- but the more you work with it the more it makes sense. The big breakthrough for me was when I finally learned the difference between static, relative, absolute and fixed positioning (it's explained quite well here) and how to combine that with floats to achieve pretty much whatever I needed to.

There's really no no need to work with tables for layout purposes. What persist suggests, is a step backwards from where we are heading towards to with html5 - with it's transition from class/id defined container divs to tagnames identifying the layout part.

• what Stickman said, with table layouts you are bascially diminishing your options to apply designs to the content using css.

There may be no need to, but this is my point. If a Div layout is so great, why is it such a pain in the ass to do something basic, that tables do in all browsers.

Layout blocks of content that always line up and expand to fit the space.???? I know why, cause the dumb fucks that came out with css weren't designers.

CSS isn't terrible, and they werent dumb. Unfortunately at the time most support architectures going into newly minted dom engines for browsers, there was little consensus on supporting one standard or another. As much as we like to claim IE does not support standards, it did support standards at the time which fell out of favor, for good reasons. The feature set and support of styling is hardly the fault of the folks who invented the language. The dom/style paradigm has been copied to countless platforms, and many with no similarity to html at all. It's simply that good of an idea.

And of course I wouldn't suggest tables for html 5.

In terms of a semantic, service driven web, of course you wouldn't want to slap tables around, and you'd want to code well within standards so your snippet works well within any sandbox, like a component that can be placed, skinned and plays well with others on the page.

As far as i knew, the table was solving page level layout issues without cross browser hacks.

Such a table will never require any objecitonable legacy maintenance because as you say HTML 5 is on the way which is going to change everything anyways. You're going to be rewriting styles and containers anyhow.

As well, anyone with practical experience knows a redesign is never a re-skinning or simple moving elements around. If and when I have to simply skin and move things around, and suddenly HTML 5 is ready, or old flavors of safari and IE 6 have finally died, you can bet I'd rather delete a table tag, and change a td tag to a div tag and be done with it, than figure out and undo all the nested css that was needed to keep a hacked cross browser div structure in place. But the poor soul using a table tag is using a hack? When the very technique of using divs is called cross browser hacks? Are you kidding? So who's entrenching themselves deeper into legacy? Who's looking backwards?

If you're looking to latch onto divs as a portable UI container you're looking in the wrong place. Even if you work with divs and CSS to claim separation of data/services from view, you're still latching yourself to the browser.

If you must go with a DOM, you have to use XSLT (fully supported on Sarissa and IE 6+) to provide any true separation of code and view. And really if you're that hot for gearing up for the shift to HTML 5, XSLT should rock your socks. XSLT provides a layer of disassociation from html entirely, providing you with a framework for porting to a different application framework than the browser entirely, releasing you from html/css without the need to undo your application.

Yeah tables suck. But so do divs. I'll use the one that sucks less in the scenario I am coding for every time. I may even opt for Flash, or an iphone app- whatever is best for the client. I say I am keeping my options wide open.

My first all css site was a bit of mess if i remember correctly. But now its quite silly how little code is needed compared to table based design.

Jestros, are you having a problem with columns?

Originally posted by: creepylurker My first all css site was a bit of mess if i remember correctly. But now its quite silly how little code is needed compared to table based design.

Jestros, are you having a problem with columns?

Yeah, that's my current problem. Sometimes I have problems with getting rows to square up too. I just search each problem as it comes up and usually find something.

Best column trick I know is applying a background image to the parent div of your columns.

I respectfully don't entirely agree with you persist. You are basically stating that for browser content it's fine to use tables because once you are going into redesign you are going to have to rework your project anyway.

If you are working from IE6 upwards, the amount of cross-browser css work is mostly limited to ie6 in particular. It's a pain, true, but the css to support legacy browsers can easily be seperated from the regular css for the time being. The particular use of tables to structure and centre your main layout for let's say a portal can be done with css without any cross browser css. The use of large encapsulating tables will still limit your ability to redesign through the css.

Now I use XSLT quite a lot, but I wouldn't say it's always the right tool for the job. To layout content that's variable and pulled from a database, sure - but regardless I'll make the XSLT spit out tables only when I have to deal with tabular data. If it's going to be for instance a page with newsfeeds I'll have the XSLT create div's to add structure, and lay it out through the stylesheets. I'm cringing at the thought of using XML through XSLT to create the main structure of a wepportal. It's viable, sure, but not practical imho. At least not if you are only publishing to the web.

To me it seems you are approaching it more more from a cross-platform, cross-media mindset, but - for me at least - almost 100% of my work is going to be published to browsers. At this point seperating structure from view for me is most easily done by creating semantically correct structure adding container-like divs when necessary and adding layout through stylesheets.

~

Jestros, give us a look at the code if you want. There are a couple best practices out there for this sort of stuff, but they can be hard to filter from all the junk code out there.

Plus I hate tables, after supporting a site for 7 years that had up to 8 levels of nested tables.

Thanks for making my point. People hate tables because of how they got abused. Exactly like how everybody hates Flash because of how it was abused. Bad design and bad development.

With the iPhone and smart phones (that aren't really smart fyi) doing table-based designs isn't really a good option. But along those arguments against tables, CSS has a lot of arguable problems as well. At least the browser will render your page more consistently with the table than it will the css across all possible desktop browsers so providing the base structure of your page in a liquid design will work with a flexible table as the foundation.

Also, referencing another thread we had and being the devil's advocate, why are the devs mad at the designers for not "designing" on the grid? After all, if CSS doesn't necessarily force you to rely upon rows and columns and is more flexible, why are the devs screaming "GRID GRID!!" when a table is truly a grid? [/devilsadvocate]

Shoot, I think I've got it to work. Give this a look. I couldn't get the nav to expand. Finally I took out height: auto !important; which is supposed to be in there for some crap reason. Colors are just for mock up purposes.

Edit: Actually it doesn't work. When I drop in the content, and it gets bigger than page size, every thing goes wonky.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Untitled Document <!-- html{height:100%;}

body{ background-color:black; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; height:100%; margin:0px; padding:0px; height:100%; }

div#container { background:white; position: relative; width:750px; height:100%; min-height: 100%;

margin: 0 auto -40px; }

div#header { height:80px; border-bottom: 1px solid black; background:#666666; }

div#nav { position: relative; margin: 0px auto -40px; float:left; width:120px; background:#AB4D1F; height:90%; min-height: 90%;

overflow:hidden; }

div#content{ background:white; float:left; padding:10px; width:610px;

} div#footer{ width:750px; height:20px; text-align:right; background:#666666; clear:both; position: relative; margin: 0 auto; } div#push{ margin: 0 auto; width:750px; height:20px; clear:both; }

div#dataStream { width:450px; margin: auto; } -->

<div id="header">header</div>

<div id="nav">
Nav Bar here. Needs to fill up space.
</div>

<div id="content">


    <div id="dataStream">
    Dynamic content dropped here
    </div>


</div>

Footer

Yes, stretching columns combined with a footer locked to the viewport is notoriously hard to pull of in css, and I reluctantly agree that if you are never going to try different designs, using a table would make your life easier in this case.

It's not a very popular layout these days, but if I were to do it I would use faux columns like creeplurker suggested. There are other methods but they require more div nesting and additional css. This way you can still throw your design around and play with your header/menu/content/footer boxes by just editing your stylesheets.

Content growing out of the columns will push the footer down.
/edit : add h t t p : // to the img url

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Untitled Document

    html, body{
        height:100%;
    }

    body{
        margin:0px;
        padding:0px;
        background-color:black;
        font: 12px Verdana, Arial, Helvetica, sans-serif;
    }

    div#container {
        position: relative;
        background:white;
        min-height: 100%;
        width:750px;
        margin: 0 auto; 
        background: url(http://awakenings-guild.net/forum/picture.php?albumid=17&pictureid=93);
    }

    div#header {
        float: left;
        height:80px;
        background:#666666;
        width:100%;
    }

    div#nav {
        float:left;
        width:100px;
        padding:10px 10px 30px 10px;
    }

    div#content{
        float:left;
        width:610px;
        padding:10px 10px 30px 10px;
    }

    div#footer{
        position: absolute;
        bottom:0px;
        width:100%;
        height:20px;
        background:#666666;
    }

    div#dataStream{
        border: 1px dotted #ccc;
    }
    div#clearer{
        clear:both;
    }
</style>
<!--[if lte IE 6]><style type="text/css"> #container { height: 100%; }</style><![endif]-->

    <div id="header">
        header
    </div>

    <div id="nav">
        menu<br/>(10 padding)
    </div>

    <div id="content">
        <div id="dataStream">Dynamic content dropped here ( 10 padding )</div>
    </div>

    <div id="clearer"></div>
    <div id="footer">
        Footer
    </div>

</div>

That actually works pretty well. That seems like a much better solution for the sticky footer.

The problem is I am trying not to use any layout images, I'm creating a php-xml cms setup, and I'd eventually like the colors to be changeable.

I could go to a horizontal nav bar, but in that case there is a finite number of menu items the user could add. Vertically they could add till their hearts content.

I just wanted to come up with a simple layout and not spend too much time on it. If anyone has any suggestions I'd appreciate it.

So the basics that I think I need, a) liquid b) vertical navigation c) no images.