Yes it's very realistic, it always has been really, but in the past those poor floats have got a bad name because of their containment issues and IE's little quirks, however it's now OK, honest! :)
Is the how it's supposed to be? Seems rather impractical if so, but maybe I'm doing something wrong?
Yes I'm afraid it's is how it's supposed to be ;)
it's something to do with the parents containing (becoming responsible for is probably a better way to think of it) their floated children.. in this case the body does not know it contains the nav menu just like the tpl_body element does not know it contains those two floated children divs..
the boring theory is right here:
9.5.2 Controlling flow next to floats: the 'clear' property [w3.org] with the pertinent bit ref: clear:both; being (my bold!):
The clearance of the generated box is set to the amount necessary to place the top border edge below the bottom outer edge of any right-floating and left-floating boxes that resulted from elements earlier in the source document.
In short since this rule was written, all things float related have progressed a lot and their is now another property , it was a necessity eventually, which allows us to isolate one area of the page from another , though technically it just forces a parent to become responsible for it's own children
in your code there is no parent element which is actually being responsible for (containing) its floated children, so its defaulting to the above rule, and you are seeing is what you are supposed to see - as soon as you set that clear property it is doing exactly what it's supposed to and clearing
ANY previous floats
OK skip past the boring bit.. the solution is to make the tpl_body responsible for (contain) it's own floated children, in the old days this wasn't so easy as the best way was to also float the main content element and likely set a width on it too to force it to be responsible, this then meant you couldn't let your main content column be the width of the page minus the width of the nav bar (i.e. an implicit width) which ruined the flexible width layouts - so the seeming "should be easy", flexible width, two column layout got unnecessarily complicated, and the whole situation made people think floats were unstable, that and the associated IE bugs/problems.. gave floats a bad name.. but that was then..
The solution is actually to use the same property on tpl_body that you would need if you were visually vertically trying to to contain the floated children, essentially the same technique for achieving vertical containment (e.g. faux columns) is also used for horizontal containment (flexible width)
add :
overflow:hidden; to tpl_body
(the actual proper explanation is to use overflow with it's value set to anything other than visible (default), hidden is obviously best used when an elements height is not restricted as it might result in inaccessible content however overflow:scroll would do the same thing but might produce a scroll bar to allow hidden content to remain accessible, hiding an elements overflow to avoid say extra long long urls or large images breaking layouts is another logical and legitimate using for hidden over scroll, you can decide what's best for your templates!)
- this relatively new method of containing floats is backward compatible to IE7, but for IE versions before that you will still need add
zoom: 1;
If you do want that backward support you could that IE "hack" in a separate ie.css if you have one, it won't do any harm in the main.css but it will not validate as it's an IE proprietary property - "zoom:1;" is simply telling IE to display the page as 100% zoom (i.e. the default) but by declaring it explicitly it triggers their infamous hasLayout property which in this case we can use at it achieves the same effect of containing floats for those older IE versions
Now the other thing about this is that if you use this method you have actually made this template even more flexible than before,
you actually do not need that left margin either - so if and when needed you can change the left column width without having to remember to change another bit too :) - because that tpl_body div has been forced to contain not only vertically but horizontally, it is now ignoring the left floated nav completely and will not flow around it as per a usual float scenario so it now only thinks it "area" is page width less the nav width - this is really cool for many scenarios where people want an element to be an unknown width but also be self contained (i.e. think a floated image of unknown width where you would like the caption no matter how long it is not to flow around the image, but instead to take up whatever space is left over) - then of course for Older IE's or IE in quirks who
just got floats and margins wrong anyway this proper way of doing things actually avoid the need to use margins thus avoiding the more complex hacks that used to be required, completely! ;)
anyway, I'm sorry this got way longer than I meant it to but I realised that this is probably something a few people don't know about, I can't find too much on this horizontal containment out there in the blogosphere, so perhaps us "here and now" CSS users should be educating on them so we can help people start to lose the "old clearing hacks" - I know it seems counter intuitive in this situation, but bearing in mind the more convoluted methods of containing floats, or achieving flexible width templates that have come and gone in the past - it's not bad if all that's left is a one line css hack for the soon to pass IE6..
Summary: when templating with floats you really just need to remember to tell the parents (main areas) to be responsible for their own "floaty" children.
