I am trying to code a layout in CSS for the first time. I noticed that many coders use nested <div>. Is the outer <div> and nested ones separate or can some attributes be inherited? Can someone point me to a tutorial showing how they work and what is not workable?
Most things not declared to be different are inherited. A type and size call in the body will apply to all divs unless you change it in any one as will a BG color. IE and FF play differetly with the padding calls. As a specific question and I may be able to help but I am not experieced enough to rattle on. I do very little nesting. I do place all my divs in the container div which is simple nesting.
Yes, that's what I was trying to do. A container <div> with nested <div>. I am having some problems centralizing the layout using margin-left and margin-right.
Here's a demo - a tool to generate CSS for 2 column nested DIVs http://www.pagecolumn.com/2_col_generator.htm
If you want to center a div using margin-left and margin-right, make sure it has a width to begin with. Also make sure the div surrounding it isnt constraining it.
You can look up specific things in the CSS specs to see if some particular thingie is inherited, but in general what others here have said about nesting goes: do as little of it as possible, and chances are you will find yourself nesting the most when you want multiple background images (one bg image per element until css3 gets into all browsers). ++ I'd also add that, by default, if you don't set any widths then a static block (like a typical div) is 100% wide by default— and you can't center something that's filling ALL the space, can you? So it also needs a less-than-100% width to work. I am talking specifically about "auto margins" rather than explicit margins: <div id="container"> the whole friggin page </div> #container { width: something less than 100%; margin: 0 auto; } centers it by automatically making the left and right margins the same. Too bad this doesn't work vertically... a mistake by the CSS makers in my opinion.
Maybe a pragmatic issue reared its head. The horizontal dimension is naturally constrained by the viewport or whatever width is assigned the parent container, not to mention the block element's expanding to fill the available width. No such natural constraint exists for the vertical dimension. How would you determine the margins of any but fully determined heights of both the centered element and its parent. If you do set both heights, then centering is trivial. Its the variable case that breaks. CSS does provide for vertical centering, but not with margins. Use the display property with table or table-cell values. The royal PITA that we've lived with is IE and its non-support of the display property. IE8 changes that, and maybe one day we can sh*t-can the work-arounds and simply do it as designed. cheers, gary
Any parent has a height if it has children, unless those children are empty. If automargins can magically detect how much space is left on the left and right side of a child to the edges of its container (even if that container has no stated width) then I'm not sure what the difference is vertically. Just as the parent container must be wider than the child and/or the child must be less wide than the parent, I don't see a difference just because we turn 90°. When a parent is wider than the viewport, the parent is used in centering. If a vertically-aligned child's parent is taller than the viewport, why not do the same? I'd rather have margins work in four directions rather than changing the display state of my boxes and pretending they're tables.
The width is constrained by the viewport's width. That's an implicit value. No such constraint exists vertically. I agree to a point. You just have to declare both heights. Otherwise, the necessary limits are missing. And, how does a width exceed the viewport's width? It can only be declared, or be a table group element. Remember, and I should have mentioned it above, that margin collapse applies to vertical margins. As for the display property's table group, that's not pretending to be a table; that's describing a set of presentation behaviors that tables and their related elements use by default. You are free to choose a different value. cheers, gary
I forgot about those, though I'm no fan of margin collapse either. I figure if I'm declaring 5px top and bottom of every element going down the line, I'd like them to be just that. But whatever, I deal with it. Declared was what I was thinking of at the time, though if can go back to the great great granddaddy... of some ultimate parent was given either a stated width or, as I found in Konq with my horizontal page, a negative-margin element wrapping around to the right can pull a page pretty wide. Stupid Konq. Made my whole page a bazillion units wide : ( I guess I'd rather that those behaviours they chose to give tables were freely available to other elements in other display states. Just wishes and mod_p0nies but, I has them.
I have never declared a vertical height on anything. I use a 3 column layout under a full width header and over a full width footer. The height of the 3 center divs is the same as the tallest of the three. All of these are inside the container div. You guys may be making this more difficult than it needs to be.
Not really; we simply moved far off topic, into an area that IE<8 has made ridiculously difficult. cheers, gary
Probably because its rendering engine was built on a Hoover. IE6 could suck-start a Harley. It could suck the chrome off a bumper hitch. Whew, stop me! I got a million of'em. IE prior to v8 had a serious problem with its version of the block formatting context. They used their model from desktop applications, hasLayout, which was inappropriate for html+css. IE8 has eliminated hasLayout in favor of a more correct model. Then, they expanded their range of support for css 2.1, which had been sadly lacking. cheers, gary