I learned css with container (wrap) technique.. but after read http://www.csskarma.com/blog/styling-your-body/

I think he is right... why use container if can we go without it ?

What do you think?

Interesting post, I never really thought of using it like that, wrappers are just the way I learnt CSS. i suppose if its in a wrapper then at least you can manipulate the position of the whole bulk content of the site but this body idea is an interesting one that I'll definitely give a go

Good post

Great lovely technique! So simple, This is a new idea for me. Thanks for sharing tt189

I've actually just tried this out, and it works perfectly in Firefox, however, in IE7 I'm getting nothing. Am I doing something wrong or does IE7 not support it?

The biggest problem with "tricks" like this is somewhere along it is going to mess up your pages.
It's nothing specially new, anyone who has been designing with CSS for a appreciable time is already aware that the html & body can be resized and will be (or should be) already aware of the potential pitfalls.

One of the major benefits of using CSS is the flexibility a designer / coder has when updating or redesigning. Resizing the parent html element or the body element removes some of that flexibilty.

so lets look at one scenario;

A couple of months ago, you have designed a site for a fixed width of 800px and clever you, used this trick of html: {width:768px;} because it saved a couple of lines of HTML code and maybe 10 - 12 lines of CSS code, and it works perfectly, big pat on the back. Client happy. Pays the invoice promptly (Yep he's that happy!)

Now client returns and he has a new machine and shiny new monitor ( 22" at 1600 x 1200 ) on his desk, upon which he has decided the pages look "lost", and he wants to have it a little wider AND have the header to be full screen width with the content section centred (T shaped).
Oh Bo!!oxs !!

Now with a wrapper div this is the work of a few minutes, move the header outside the wrapper, widen the wrapper and tweak the child elements to suit, maybe not even that, if the widths are proportional. Any absolute positioned items should simply take up their positions from the wrapper or the html parent.

Your design doesn't have a wrapper and it is the ultimate parent sets that width, so now you have to add that wrapper anyway, and test all your positioning because the ultimate parent has moved.
The few minutes has gone to possibly several hours. And the bill to the client has gone from £30 - £40 to maybe £300 - £400 for what the client perceives is a minor update to a brand new site.
Whoops! repeat business, word of mouth business just took a downhill ride.

The moral is;
Always be aware that messing with the fundamentals of anything could have far reaching consequences.

I am not saying not to try this on a test site, just don't do it on a client site.

That's actually an easy fix, you just do something like:
#header, #nav, #content, #footer{width:800px;}

rather than:
body{width:800px;}

those serve as your "wrap" divs and you just take out anything you want to stretch to 100%.

There are very few situations where you actually need a <div id="wrap">

Sure, but doesn't that negate the point of your article about setting the body or html element to a fixed width?

I can't get to that site from here (blocked by our IT weenies), but I can only say that a lot of my layouts just wouldn't work using that method. I often 'stack' backgrounds plus containers to achieve a design, so constraining the size of html and/or body wouldn't be desirable.

Tim you're article is interesting, but I still prefer a wrapper div. While I agree in saving code in this case it's rather negligible amount of code.

From your article:

This technique will work in 95% of the web sites out there. The only case it wouldn’t fly is if you need to put content spanning the whole top of the browser window (with a center aligned page).

A lot of my designs fall in what you would say is that other 5% though I'd dispute your 95% stat anyway since lately 95% is the most overused number in stats. Sorry, but if I see someone quote 95% it only tells me they made up the number.

One other reason though why I think a wrapper div is a good idea is because it's descriptive. It's very easy for another developer to look at your code and understand what you're doing. I do understand the point you're making, but I think the gains of giving up the wrapper are minimal. I think what you lose in flexibility and description is greater.

However I think it's a good article for developers to read to understand what they can do. I'm using a wrapper because I think there are good reasons to. I suspect there are many who use it simply because they saw someone else use one and just copied the idea. There are times when it might be appropriate to style the body instead of adding the wrapper div and css developers should understand not only the how, but the why.

Well after trying it I think I'll just stick to wrappers - at the end of the day, even if this '95%' stat is true, wrappers have worked on 100% of the sites I've made, so it would be pointless to start using the body in that way

I always use a wrapper, even when it doesn't do anything, because it gives me a single degree of separation from the body, which gives me overall control of the web-page's dimensions from a single wrapper, in case future changes are required. It isn't exactly labor intensive to add one <div> in, and when I use shared files for the head and foot of the document, it only gets written once or twice anyhow.

However, I agree, with Van Gough's assessment that it doesn't hurt to have the understanding of what is possible, since it gives you a deeper understanding of your webpages. I used to commonly design my pages without a wrapper, but have since given up that practice, and feel what I do now is more structured.

Part of the beauty of CSS is that there are many, many ways to accomplish the various things, which is why it is so powerful. It is also a somewhat fragile system, despite its beauty, so we need to invent structures such as these to keep it within a solid framework. How we do it is not ultimately important, as long as the page doesn't fall apart and works cleanly...