As you may know, elements that contain floating elements won't stretch around their child elements unless you either add clear elements after them or set the parent's overflow to hidden. See example.
My question is, are there any real life scenarios in which one would want to not stretch the parent element around it's children, as in the "Overflow visible" box in the above example?
Interesting thought, but I doubt anyone would want that as first, you can just do a border + padding to reproduce that scenario, and second, the clear thing is actually thought of as a bug/something that isn't the right behavior.
In the real world, if you didn't know any better, you can settle with that "solution" where a box was there that didn't have any height and the element they're containing is showing outside of it, but since you know better, it is better to just do it correctly, meaning, clearing the div, using absolute positioning, or using borders and padding to achieve the same effect.
EDIT
It is not actually a bug but it was the "right" behavior because if float containers cleared themselves, it would propose a much harder problem as discussed in this page: http://css-tricks.com/all-about-floats/
Related
I was just wondering if there was any disadvantages for having empty divs in place in order to have a layout that I desire. Is there any other way around having hidden divs because I know that it adds to messy code.
See images below for what I am trying to demonstrate:
As you can see, the bullet points on the left are level with the h2 element but when I add a h2 element before the bullet points, it lowers them to the level of the paragraph (which is how I want it). Obviously I can make this h2 element invisible and therefore achieve my desired effect but is there more of a professional way of doing this?
But why you want to do that? Whats margin-top property for?
I'll go lil brief here, you should first learn floats than go for positioning, also learn what block and inline elements are, you got a lot of CSS things out there, margins,paddings` etc, take a look at box-model too so that you don't pull your hair later
And if you want to stick to a dirty markup than empty div's and br are options for you, but you won't get a specific height from top using br so for that you need to use an empty div but DON'T USE THIS
Two suggestions which will provide a quick fix:
Margin-top on the bullet points element or.
Add an H2 with a non-breaking space inside it e.g.
<h2> </h2>
If you want to add extra space without CSS, you can use <br/>
tags - its definitely a much better than empty divs, which is messy and a bad practice.
CSS is really the best way, though.
Give the h2 a width so it takes up the entire rest of the row. The bullet list will then automatically drop to the same height as the left paragraphs.
Or, give the bullet list a margin-top or padding-top.
I suggest that you use either margin-top for the second div or margin-bottom for the first one.
Example: If the hidden div's height is 100px, you better write: <div style="margin-bottom:100px">...</div>
I'm trying to make a box with rounded corners where the height and width of the div depends on the content, so it's automatically adjust to it...
You can see the example here: http://pastehtml.com/view/1duizyf.html
The problem is that i can't get the "test_mid_left" (black background) and "test_mid_right" (turquoise background) to inherit the height from the "test_mid_center" (green background). I have tried height: 100% and auto, but none of thoose work. So how do I get them to inherit the height from the content?
(The reason why I have used "min-height: xx" in the left and right content on the example is just to show which boxes I am talking about)
As already mentioned this can't be done with floats, they can't inherit heights, they're unaware of their siblings so for example the side two floats don't know the height of the centre content, so they can't inherit from anything.
Usually inherited height has to come from either an element which has an explicit height or if height: 100%; has been passed down through the display tree to it.. The only thing I'm aware of that passes on height which hasn't come from top of the "tree" is an absolutely positioned element - so you could for example absolutely position all the top right bottom left sides and corners (you know the height and width of the corners anyway) And as you seem to know the widths (of left/right borders) and heights of top/bottom) borders, and the widths of the top/bottom centers, are easy at 100% - the only thing that needs calculating is the height of the right/left sides if the content grows -
This you can do, even without using all four positioning co-ordinates which IE6 /7 doesn't support
I've put up an example based on what you gave, it does rely on a fixed width (your frame), but I think it could work with a flexible width too? the uses of this could be cool for those fancy image borders we can't get support for until multiple background images or image borders become fully available.. who knows, I was playing, so just sticking it out there!
proof of concept example is here
The Problem
When an element is floated, its parent no longer contains it because the float is removed from the flow. The floated element is out of the natural flow, so all block elements will render as if the floated element is not even there, so a parent container will not fully expand to hold the floated child element.
Take a look at the following article to get a better idea of how the CSS Float property works:
The Mystery Of The CSS Float Property
A Potential Solution
Now, I think the following article resembles what you're trying to do. Take a look at it and see if you can solve your problem.
Equal Height Columns with Cross-Browser CSS
I hope this helps.
The negative margin trick:
http://pastehtml.com/view/1dujbt3.html
Not elegant, I suppose, but it works in some cases.
You need to take out a float: left; property... because when you use float the parent div do not grub the height of it's children... If you want the parent dive to get the children height you need to give to the parent div a css property overflow:hidden;
But to solve your problem you can use display: table-cell; instead of float... it will automatically scale the div height to its parent height...
Most of the times, the Previous parent has a heigt manually set, so you can use that value as reference, no other dirty tricks will be needed, and if the number is not the same for any reason maybe a comment can be added with the original number so in case you need to change it, by searching at the all the values, this one can be adjusted or even changed, in the time someone resolve this one for us.
is the fact parent collapses when children are floating a bug?
If so why are newer browsers not fixing it
Is it intentionally? for what good reason?
I know at least 6 solutions to get around this issue, I am only asking if this is a bug or not.
Thanks
from: css-tricks
As anti-intuitive as collapsing seems to be, the alternative is worse. Consider this scenario:
If the block element on top where to have automatically expanded to accomodate the floated element, we would have an unnatural spacing break in the flow of text between paragraphs, with no practical way of fixing it. If this were the case, us designers would be complaining much harder about this behavior than we do about collapsing.
Collapsing almost always needs to be dealt with to prevent strange layout and cross-browser problems. We fix it by clearing the float after the floated elements in the container but before the close of the container.
When you float an element, you take it out of the flow of the page. Due to this, the parent won't expand to accommodate the child. Yes, it is intentional (and defined, I believe) behavior.
Here is a tutorial that talks about enclosing floats.
I believe thats a function of the float. You are removing the element from its location in the flow and pushing it left. The "space" that it takes up is freed. As opposed to absolute/relative positioning where the object still takes up the space.
I think that's how it goes!
it's meant to be that way. Half way down this article there is a solution to fix some of the potential problems you have have with it.
http://www.smashingmagazine.com/2009/10/19/the-mystery-of-css-float-property/
What's the most common way to deal with a series of block elements that need to be on a line (if javascript needs to be able to modify their widths, for example)? What are the pros and cons to applying float:left to each of them vs. using positioning to place them?
Well, if you're not too concerned with older browsers (I'm looking at you, IE6) the best way here is to go with
display:inline-block;
Basically, it creates a box-model element without clearing before or after it, so it remains in the line. Every modern browser interprets it well.
Floating would be my choice, but it really depends on what you wish to achieve. If you can provide a more specific example I would be able to give you a clear reason as to what and why I think you should use. However here is a brief set of pros and cons that I have come accross (I'm assuming that by positioning you mean absolute positioning):
Positioning pros:
very precise positioning in relation to the next ancestor marked as position relative - allows for great flexibility
allows for elements to be in a different order visually than they are in the DOM
Positioning cons:
Harder to line up with other elements since the positioned element is no longer in the document flow and also because of the level of precision required.
Other elements ignore the absolutely positioned element which means you could have a potential overlap, unless you account for the minimum and maximum size of the positioned element
harder to implement a footer if you are using absolute positioning for your columns.
Float pros:
really easy to construct simple and advanced layouts
no footer problem
no worrying about precision, browser takes care of that for you
parent container stretches
Float cons:
Lots of pitfalls for those less experienced with float layouts that may lead to many questions being asked on SO :)
As to the clear:both element that Sebastian mentioned, There's a simple way around that. Lets say you have a container div and 2 floated divs inside.
Html:
<div id="con">
<div class="float"></div>
<div class="float"></div>
</div>
CSS:
#con { background:#f0f; }
.float { float:left; width:100px; height:100px; background:#0ff; }
if you were to run this code you would notice that the container div (the magenta coloured one) is only a single pixel high whereas the floated divs were correct - which is the problem Sebastian mentioned. Now you could take his advice and add a br or float the container which would not be very semantic - so here is a slightly more elegant solution. Just add overflow:hidden; to the container div like so:
#con { background:#f0f; overflow:hidden; }
Now your container should wrap the floated divs properly.
The parent container does not stretch with them unless it is also assigned a float tag or there is a br with clear:both; at the bottom.
I would go with the float:left instead of the positioning. The browser does all the aligning when one object stretches. So there is less for you to care about.
I think i wouldn't explicitly position the elements but rather instruct the browser to use an inline layout for the elements using display:inline and let the browser handle the positioning.
regarding float vs positioning i think the only way to line them up using positioning is by using absolute positioning, and that means you need to handle re-sizes(of the browser view port) in order to keep the elements in place.
I think that by using the float property the browser handles the re-sizing issues for you and re-renders the element in the correct place.
Only disadvantage to float in situations like this for me has been that you'll either need to left justify them or right justify them -- centering is not an option. However you've mentioned you're using absolute values for widths, so you could just nest all the floated elements in a DIV element and add either margin-right or margin-left to the parent DIV to simulate center alignment.
For example I have a situation where I have something like this (contrived) example:
<div id="outer" style="margin: auto>
<div id="inner1" style="float: left">content</div>
<div id="inner2" style="float: left">content</div>
<div id="inner3" style="float: left">content</div>
<br style="clear: both"/>
</div>
where there are no widths set on any elements, and what I want is #inner1, #inner2 and #inner3 to appear next to each other horizontally inside #outer but what is happening is that #inner1 and #inner2 are appearing next to each other and then #inner3 is wrapping on to the next line.
In the actual page where this is happening there is a lot more going on, but I have inspected all of the elements very carefully with Firebug and do not understand why the #inner3 element is not appearing on the same line as #inner1 and #inner2 and causing #outer to get wider.
So, my question is: Is there any way to determine why the browser is sizing #outer the way it is, or why it is choosing to wrap #inner3 even though there is plenty of room to put it on the previous "line"? Baring specific solutions to this problem, what tips or techniques do you hardcore HTML/CSS/Web UI guys have for a poor back end developer who has found himself working on the front end?
It would be nice to have a tool that could tell you exactly what all your layout problems are, but in this case the browser rendered the page exactly how it should have -- the combined width of the floats exceeded the width of the containing block, so the last one drops to a new line (this is slightly different than the IE6 expanding box/float drop problem which is typically caused by content inside the float, not the floats themselves). So in this case, there was nothing wrong with your page.
Debugging this is simply a matter of walking through your HTML in Firebug and figuring out which children of a block is exceeding the block's width. Firebug provides plenty of information for this purpose, although sometimes I need to use a calculator. I think what you described about being able to see which elements constrain other elements would simply be too complex and overwhelming, especially for elements that are removed from normal flow (such as floats or positioned elements).
Also, a deeper understanding of how CSS layout helps a lot as well. It can get pretty complicated.
For example, it is generally recommended to assign explicit widths to floated elements -- the W3C CSS2 spec states that floats need to have an explicit width, and does not provide instructions of what to do without it. I think most modern browsers use the "shrink to fit" method, and will constrain themselves to the width of the content. However, this is not guaranteed in older browsers, and in something like a 3-column layout, you'll be at the mercy of at the width of content inside the floats.
Also, if you're striving for IE6 compatibility, there are a number of float related bugs that could also cause similar problems.
Try the Web Developer Plugin for Firefox. Specifically, the Information -> Display Block Size and Outline -> Outline Block Level Elements options. This will allow to see the borders of your elements, and their size as Firefox sees them.
In Firebug's CSS tab, you can see what style rules apply to a selected elements in the cascading order. This may or may not help you in your problem.
My guess would be that something about the content of #inner3 is causing it to wrap below the first line, and the #outer is just getting sized to accommodate the smaller needed space.
So I found the answer in my specific case -- there was a div much further up in the DOM that had specific left/right margins set which compressed it and everything in it.
But the heart of the question is really how can you easily debug this sort of issue? What would be perfect in this case for example would be something in Firebug that, when hovering over an element's size in the layout panel would display a tool tip that says something like "width constrained by outer element X; height constrained by style Z on element Q" or "width contributed to by inner elements A, B and C".
I wish I had the time to write something like this, although I suspect it would be difficult (if not impossible) to get that information out of Firefox's rendering engine.