wrapping div not displaying

div,content wrapper

[dupalo]

HI there,
I have a questiona bout a div that is not showing up in the coorect position.

Now, in the css I wrapped the navigation in a div called "navigation" with a

border: 1px solid magenta;

Now the issue I am having is that the magenta div is not enclosing the navigation at all but it is above it, and I am going crazy trying to understand why.
I have floated the navigation left, therefore I added an empty div called "clear" and gave it

.clear
{
clear:both;
}

in the "containers.css" file, but no luck, the magenta box is not wrapping around my navigation still.
I am not sure what I am doing wrong, any suggestion please?
thanks

[edited by: alt131 at 1:34 pm (utc) on Sep 11, 2011]
[edit reason] Thread Tidy [/edit]

[Marshall]

If I'm understanding you correctly, you want something like

______________
| NAV NAV NAV |
______________

but are getting something like
______________
|_____________|
NAV NAV NAV

An easy method is to add a <br style="clear: both;" />

<div id="container">
NAV NAV NAV
<br style="clear: both;" />
</div>

See if this helps.

Marshall

[alt131]

Hi dupalo, and welcome to css :)

Now the issue I am having is that the magenta div is not enclosing the navigation at all but it is above it, and I am going crazy trying to understand why.

If Marshall has identified the desired layout, I would also suggest asking why the magento div is being drawn "above" the navigation div in the first place. For example, has it been positioned, or does it have an explicitly set height that is less than the height of the navigation div?

[dupalo]

hi thanks you both for the feedback. You're actually both right. Marshall, I have done something similar, rather than having a <br> I inserted an empty <div class="clear"> after the navigation and gave it .clear{clear:both;}.

alt131, good point I didn't know I had to give it a height, I thought that giving a height to the element inside the div would have been enough. I have now given the div the same height as the element, and that sorted everything out. I will bear this in mind in the future,
thanks for your help

[alt131]

Hi dupalo, pleased you have solved the issue, but I was asking for information, not making a suggestion. You see, neither clear or an explicit height should be necessary, and adding them both will probably be "fixing" another issue. I'm an advocate of avoiding the original issue rather than adding more and more fixes.

The reason I asked about positioning and height is because I wondered if you were working with a theme, and the ones we see here are frequently what I call "over-engineered". That is, have lots of extra code to control the html very specifically, but which is not really necessary, and so creates the sorts of issues you identified. A common response is to add "fixes" - that is "over-engineer" some more ... creating issues which are dealt with by adding more code .. which creates more issues ... To my mind, best resolve the original issue.

For the future, just keep in mind that a block element should contain it's contents unless it has an explicitly set height, and/or the contents have been removed from the flow (using float or positioning). Also, that clearing elements add extra html elements that have no semantic value. Rather than an extra div it is often possible to apply the clear to the element itself. Marshall's suggestion of using <br> is (to my mind) much less worse than a whole div, but the ideal is to code to avoid them. If you must, and are supporting modern versions only, the pseudo elements :before/:after are much less invasive.

[dupalo]

Hi alt131,
I see what you mean, it actually makes a lot of sense.
so about the containers, you are saying that if an element has an explicit height or a floating applied to it I shouldn't put it into a div?
I understand what you mean about the clearing, next time I will apply to the actual element rather than another div. I have kind of noticed on the net, from my own research, that some developers really like the idea of an empty div, whereas others loathe it : - )

[alt131]

so about the containers, you are saying that if an element has an explicit height or a floating applied to it I shouldn't put it into a div?

Almost :)

Floats remove an element from the flow so the parent (container) of a floated element should not "expand" to contain the child element. See the introduction at 9.3 Positioning schemes [w3.org] for more detail. Second, an explicit height on a parent (container) should be obeyed, so the parent may not expand to contain child elements if the total height of those elements is taller than the height set on the parent. I say "should" and "may" as some legacy versions did.

However, I'd suggest the best question is whether "divs-as-containers" are required (or any other "container" element). Divs should "<div>-ide" sections of content (text/images) of the page. A common use is to create divisions for the heading, main content and footer if necessary to apply different styles to those parts of the page. (Note HTML5 deals with this by providing more elements than just the generic div.) However, another common coding issue is "div-itis" - where "every" HTML element is contained in a div, or div's are used instead of the semantically correct HTML elements. So, as with applying clear, I suggest ask if a container is really required - frequently styles can be applied directly to the appropriate html element itself.

I have kind of noticed on the net, from my own research, that some developers really like the idea of an empty div, whereas others loathe it : - )

- which can be confusing when starting. I just look to the recommendations, such as 2.4.1 Separate structure and presentation [w3.org], and 2.4 CSS design principles (Complementary to structured documents) [w3.org]. Otherwise: just because you can (insert an empty div) doesn't mean you should ;)

[dupalo]

I see, thanks for your help alt131. It's that having each element in a div seems to make life much easier when it comes to make an element float. You float the div and it seems less likely to break the layout