Forum Moderators: not2easy
What about a page where you would want the following layout - top down - which I know how to build with tables:
Header: 2 cell table with left cell content floated left and right cell content centered.
Next down: table with 3 cells
Next down: table with 2 cells
Next down: table with 3 cells
Etc down to 1 cell/div footer.
In order to duplicate the above 'table layout' with 'pure CSS' is the task doable by setting up divs and then, within each div, positioning a child div floated:left, another div floated:relative, and a third div float:right?
Then move on to the next div and build child divs, with floats and sizes within it per needs?
If I'm not making sense just smack me upside the head. I've been reading about CSS for the past 12 hours and my grey matter is feeling a little more grey for the effort.
Time to go play with this, but any intervening sharing of insights would be appreciated.
What else is a fella to do on his Labor Day weekend but to labor all day about CSS?
Header: 2 cell table with left cell content floated left and right cell content centered.
Next down: table with 3 cells
Next down: table with 2 cells
Next down: table with 3 cells
Etc down to 1 cell/div footer.
As you did, from the top down, bearing in mind this only one way to skin this cat (as it were) ...
Header:
<div id="header">
<div id="headleft"></div>
<div id="headright"></div>
</div>
(widths in these examples are arbitrary, change at your discretion (sp?))
#header {
float:left;
width: 700px;
}
#headleft {
float:left;
width: 300px;
}
#headright {
margin-left: 305px;
text-align: center;
}
Okay. So this splits your header divinto two parts, the left floated chunk, and the rest offset from the float by the margin. You may have some trouble with this option if the lengths of the content in these two are radically different. You can reverse it and put #headright first in the source and float it to the right if necessary. I would float whichever one has the most content. The #header div is floated in order to force it to expand and contain the floated child.
Table with three cells:
Several ways to do this. The easiest thing for me to say here is to take all that stuff you learned about making a three column layout and confine it all within the confines of one relatively positioned, floated div.
However, I can't stand all the funky-monkey three column techniques out there. All that complication make my head all wonky. If I were you, I'd make a container div, float it, then put three child divs inside, all floated left with explicit widths the sum of which DO NOT under ANY CIRCUMSTANCES exceed the width of the container.
Table with two cells:
Again, create a container, then use either the technique from the header or the technique from above with only two children inside. Remember to give the container div a clear:left AND float it like the others.
Table with three cells...
Etc. You get the idea. Of course, there are other ways to handle this, as you're bound to find out. The key is going to be confining each row to a container div, and clearing each div as you move down the page.
I also feel obligated to give the "CSS-P does not equal tables" speil, which goes something like: The idea behind css layout is not to emulate tables based layouts but to use the flexibility of css properties to think in whole new ways about how to organize the appearance of a blah blah blah.
Tiresome, but also true. Chances are that if you're trying to mimic a tables-based layout in css and it's giving you a hard time, you'd be better off taking a step back and reassessing how you're organizing the information. Maybe there's a better layout, a CSS layout, that would work better and be less of a headache. The point being, if you THINK in css, not tables, CSS can do more for you. Just a thought.
And incidentally, relative is not a value for float. It's left, right or none.
And also, good luck.
createErrorMsg
I'd make a container div, float it,
According to the css2 specs, I thought that you could not float a container div?
Here [w3.org] is where I read this information. I'm not sure if I am not understanding what it is saying or not, but according to what this is saying, you can't float a container div, or position it?
I'm currently taking a css p class, so if I am misunderstanding what this is saying, please let me know ;)
The root of the document tree generates a box that serves as the initial containing block for subsequent layout
The initial containing block cannot be positioned or floated
my understanding is that this aplies to the <html> tag only
Next question, and I'm sure this would benefit webworks learning here as well, Why would you float the container div?
wondering that myself.....
The reason why I was wondering is that I have a layout I'm playing with that has floats, and I dont have the container div set to float. It works fine. I can resize the window, and it holds up. So naturally, I would be curious to know if you *have* to have the container div floated.
Why would you float the container div?
Because floating stuff is fun!
No, actually, there is a legitimate reason to float the container. When a containing block has floated children, you have to float the containing block in order to 'force' it to expand and contain the floated children. If you don't float the container, the floated children will...well, float right out of the container.
Look at the w3 specs on floats here [w3.org]. (and scroll up slightly). The image shows you exactly what a floated box will do. It floats over the borders of it's containing block and any other blocks that come after it.
In the layout suggested in this post, such non-containment would cause some divs to overla others lower down on the page. By floating the container, it will wrap around those children and not let the next div begin until the floated stuff ends.
Here's a little cut'n'pasteable experiment that shows you, in action, the sort of effect this can have on a page. Say you've got a container div with a #content and a #sidebar inside it. You float #content right and apply a right margin to #sidebar, then attempt to give the #container a left border...
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Float Your Boat!</title>
<style type="text/css">
#container {
/*float: left;*/
width: 700px;
margin: 0 auto;
background: transparent;
border-left: 4px solid #7b1417;
}
#content {
float: right;
width: 525px;
margin-right: 25px;
}
#sidebar {
margin-right: 555px;
}
</style>
</head>
<body>
<div id="container">
<div id="content">
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Sed semper turpis a velit. In urna. Suspendisse potenti. Sed ac dui vitae odio viverra lobortis. Duis malesuada. Nullam sed purus. Nam orci. Nulla sem nulla, facilisis ut, fringilla vitae, consequat a, diam. Fusce at eros eu massa faucibus faucibus. Ut posuere nisl tristique turpis. </p>
</div>
<div id="sidebar">
<p> </p>
</div>
</div>
</body>
</html>
As is, you'll notice that there is no border on the left side of the container div. Why? Because the container itself does not extend any further down the page than the non-breaking space in the sidebar. The #content extends down further, but is floating OUTSIDE of the container box and, thus, does not help extend the container's border down.
Now uncomment the FLOAT in #container and reload. Presto! A border! Now that the container is floating, it extends down to wrap around the floated #content, allowing the length of the #content div to affect the border on #container.
Ain't CSS a peach? :)
In the layout suggested in this post, such non-containment would cause some divs to overla others lower down on the page. By floating the container, it will wrap around those children and not let the next div begin until the floated stuff ends.
A peach? No, a beach!
The above quote is counter-intuitive to my neophyte grasp of the meaning of 'float' versus 'height', 'width', 'auto'.
So, am I too poorly, pathetically informed to understand that this business of 'overflowing the parent div' is not regulated by an intuitive property of the containing div - such as setting the height property of the containing div to 'auto' such that the container div would expand heightwise sufficient to contain the children?
You mean there's no direct property (i.e., height) way of telling the browser 'this container div with child divs inside it needs to grow in height to be certain to contain those 3 children, no matter how tall they grow'?
Arrggghhhhh. Say it ain't so! That just doesn't make sense. You mean I 'make the height flexible' by playing with float, versus playing with height attributes/properties of the parent container?
Do I make my confusion any more clear by being redundant? Howwwwlllllll!
OBTW - whilst I publicly grouse, I do greatly appreciate your assistance.
Unfortunately because IE has always incorrectly had floats stretch their parent divs it's something else that is hard to understand until you realise that it was not meant to be this way.
The addition of the float containing behaviour only came about in CSS2.1 due to design/layout requirements and is very useful in making floated layouts. It means we have no need to using clearing hacks, in theory that is ;)
But the growing use of floated layouts, now that the more compliant browsers have "caught up" is tending to highlight many of the IE bugs, which are mostly created by it's "auto enclosing" behaviour. It doesn't honour the float in a float specs and therefore you need to rely on it's enclosing behaviour to create the same effects and using the correct method of clearing floats is what triggers some of it's bugs, so instead we might still need to use hacks, but now it's for IE and not the other browsers..
It's fairly easy to create this type of layout armed with that info, treat each row as a seperate entity, much like if you were to do it with tables you could use seperate tables rather than nesting or colspans..
Suzy
there is no border on the left side of the container div
Arrgh! I see a left border (IE 6) with the container div centered on the page. Uncommenting the float left, well, simply floats everything left.
What else is a fella to do on his Labor Day weekend but to labor all day about CSS?
Yeah, ain't webmastering great? Make all of my friends with real jobs jealous as they have to go out and actually enjoy the holiday. I get to sit here banging my head against the screen.
Arrgh! I see a left border (IE 6) ..
You will :) that what we mean with IE's "auto enclosing" behaviour It does it wrongly.. always has..
The point that cEM is making that when you float the container div the compliant browsers will then make the parent enclose the children too.. the design then not being centered is a different thing and why it's best to use a wrapper div to center a design (we could just center the body if it weren't for IE5.x..) ~ or one of those reasons where it still may suit you to use a hack to clear the floated instead of containing it in a float, either way this is normal behaviour and realising that IE is misleading you is a big part of this ..
Suzy
that what we mean with IE's "auto enclosing" behaviour It does it wrongly.. always has..
Okay, so I fire up Opera and Mozilla and get (as usual) a bit more confused.
Opera's behavior is exactly the same as IE6, i.e., it appears to be auto-enclosing the children without the float left.
Mozilla behaves as cEM describes, only enclosing the children after the container is floated.
I've rewritten this part so many times I'm not sure exactly what I want to say...I think your point was that IE was the non-compliant browser, but I see Opera behaving the same way. Does that mean that Mozilla is the only one that handles this correctly?
Or am I so far out in left field that I should be doing what everybody else is doing today -- playing softball with a glove on one hand and a beer in the other.
'overflowing the parent div' is not regulated by an intuitive property of the containing div - such as setting the height property of the containing div to 'auto'
Ah...when referring to child elements of a given containing div that are in the normal flow, your intuition is right on track. Normally flowed children do, indeed, automatically cause the container to grow and stretch to contain them. As Suzy so adroitly mentioned above, the actual intention of float is to create/position an element that is not contained by it's parent, but rather 'floats' out of it.
However, given the nature of your layout (needing div rows that emulate table rows), that floating behavior could get in the way. While float provides you with an easy way to place different child divs side by side while avoiding the snake-pit that is absolute positioning, it does mean that you have to compensate for float's natural behavior, i.e., to not be contained.
Likewise, as Suzy mentioned, you can't force IE NOT to contain floats, and that means you're left with wildly different results. Since IE can't be hacked to comply, you essentially have to hack compliant-browsers to stop behaving (You kids get out there and play in the street!) then design to the broken implementation, in order to achieve cross-browser results.
Arrgh! I see a left border (IE 6)
SORRY! I really should have mentioned that all that was intended for use in Moz/FF.
intended for use in Moz/FF
Whew! I'm not as confused as I thought.
You kids get out there and play in the street!
I'm going to do just that. The day's almost gone and it's much too pretty to let it all slip away.
Am I being told, in a round about way, to just stack the tables up and apply CSS to everything else? I hate the butchery necessary to accomplish this layout otherwise. Would that be a sin?
To quote Eric Meyer
Looking to the future, there have been a variety of proposed enhancements to CSS that would allow an author to declare that an element should stretch to contain any floated elements within itself. These would obviously be welcome additions to CSS, but as of this writing, support for such abilities is likely to be a long time coming.http://www.complexspiral.com/publications/containing-floats/
If I stare at what you've said and what Eric Meyer said about 'how to do it' for several hours will I be able to do exactly what I set out to do: Create the same layout that I can do easily with tables in a manner that will look as pretty across the majority of browsers?
I hate how much one has to know about hacks and bugs to achieve a layout that works mostly until some browser is updated and throws it all off.
Opera's behavior is exactly the same as IE6..
Well blinking heck.. when did they start doing this? I know that Opera has flirted with IE methods in the past....and yes it seems Opera (but I don't know which version it started it in) mimics this IE behaviour but only if the container div is dimensioned (700px in the example above). Opera is also the first browser to incorporate the "shrinkwrapping" where floats that don't have widths will shrink to fit content, perhaps the two will go hand in hand..
No matter the fact that Moz is correct only confuses the issue even further as we can't even blame IE alone anymore! .. maybe it's a temporary weakness on Opera's behalf, they've done this before, are they sitting on the fence between compliancy and IE, if so it's not helping the CSS cause!
Webwork yes in a layout like you're describing it may well be easier to use tables to provide the framework. We didn't mean to confuse you honest, it's just that it is possible, and floats are the best way, but you have to be aware of what you're working with. It's not really as bad as it sounds, but it is what puts folks off CSS-P. You want to see the hacks we used to have to use.. different ones for each browser.. now it's generally just IE that has to be hacked and it at least provides it's own filters (conditional comments)
Again it's a case of getting what you want in Moz then hacking for IE. opera will work either way obviously ;)
Suzy
I hate how much one has to know about hacks and bugs ...
That statement alone seems reason enough to me for you to use tables. If you're not accomplishing what you want, and you hate messing with CSS, well...why do something (by choice) that you hate. It's like poking yourself in one eye because it makes the other one see better. (It doesn't, but as an analogy you can see where I'm going.)
CSS-P provides some solid, incontrovertible benefits over tables-based design, but believe me when I tell you that LOTS of people are still using tables. In my local area alone, something like 12 out of 15 design firms still use tables on EVERY DESIGN THEY DO (the ones in their portfolios, at least). While css-junkies on the forums may try to shame you for sticking to tables, the truth is there's nothing morally reprehensible about designing in tables, so long as you're willing to sacrifice css's benefits.
That said...
Am I being told, in a round about way, to just stack the tables up and apply CSS to everything else?
Not by ME you're not! I see no reason not to use css for your layout. WHile we've been pontificating about all this float stuff, it's merely been in the interest of explaining what's going on. The bottom line is this...IE automatically encloses floats. Opera (apparently) also automatically encloses floats. So the only "hack" you have to use is to force Moz, Firefox and NS to enclose floats and you've got a uniform layout scheme across browsers.
Now it just so happens that your layout, with it's stacked up rows, lends itself pretty well to floats enclosed in container divs. So use them! It really won't be much different then using a table except that..
a)you'll have more control over which boxes in each DIV come first in the source code, by choosing the direction of the float (remember, first in the code must be the first float).
b)you'll have the semantic advantage, increasing your likeability rating with search engines.
c)you'll have cleaner code.
And lastly...
proposed enhancements to CSS that would allow an author to declare that an element should stretch to contain any floated elements within itself
I am reborn a fledgling convert (but will likely need some hand-holding for the forseeable future) ;-)
Thanks again for the sage advice and encouragement.
Jeff
