Take a look at this fiddle:
http://jsfiddle.net/WTcgt/
Why is the BOX1 pushed down by the amount of border of BOX2? Is this a bug?
The box-sizing property is supported in Internet Explorer, Opera, and Chrome.
Firefox supports an alternative, the -moz-box-sizing property.
Safari supports an alternative, the -webkit-box-sizing property.
here is working example http://jsfiddle.net/WTcgt/2/
This is the behavior of inline-block:
An inline block is placed inline (ie. on the same line as adjacent
content), but it behaves as a block.
use vertical-align:top to avoid this problem. If we doesn't use vertical-align property then elements align in same line based on adjacent element. For more information read http://www.impressivewebs.com/inline-block/ and http://www.brunildo.org/test/inline-block.html
Your boxes are inline block boxes and not just regular inline boxes, so their borders sort of act as "padding" in this aspect.
To be clear, since there is a top border on BOX2, it pushes the content area of BOX2 down (it does not bleed into the content area despite what may be implied by box-sizing: border-box!). This causes the content areas of all other inline block boxes on the same line to follow suit, as described in the spec (emphasis mine):
The vertical padding, border and margin of an inline, non-replaced box start at the top and bottom of the content area, and has nothing to do with the 'line-height'. But only the 'line-height' is used when calculating the height of the line box.
Related
Here is my case code.
I create a div which contain element i. The i has width and height attribute and I achieve it with different way. So ,I encounter the line-height issue. I know a little about float vs inline-block. But, What cause out the line-height in my case?
inline-block is treated as an inline element (like text). If it is taller than other inline elements in the same line, it forces the line-height to be taller. You can use vertical-align:top|middle|bottom; to change the alignment of the inline-block element (more options for vertical-align here: https://developer.mozilla.org/en/docs/Web/CSS/vertical-align).
A floated element is just pushed to one side or the other, and the text flows around it.
I've come across a strange behavior related to the margins of a <div> element. I've added a very simple test case to jsFiddle to show you what I mean.
Interestingly the margins are used correctly when using a border. Is this the default behavior? Does this have something to do with collapsing margins? Is it possible to somehow force the margins without any hacks?
Least ugly solution so far that I thought of:
.cssContainer {
margin:10px;
padding:0.1px;
background-color:#FF0000;
}
But I don't know whether this will work in every browser.
This is another case of adding overflow:auto to the rescue!
jsFiddle example
Just add overflow:auto to your container div and voila, harmony is restored.
.cssContainer {
margin:10px;
padding:0px;
overflow:auto;
background-color:#FF0000;
}
From specs, the reason this works is because a new block formatting context is established by applying overflow other than visible, forcing margins of .cssContainer to not collapse with its in-flow children .cssElement.
From this site
the simplest way to stop the margin collapse from occurring is to add
padding or borders to each element. If we wanted 10px margins on each
element we could simply use a 9px margin and 1px of padding to get the
result we wanted
This is due to the CSS box model. The elements with the red backgrounds will not grow in height to accommodate the top and bottom padding of its children elements, but because the border was specified in the second example and encompasses the padding, the padding will show.
The overflow: auto; property works because the padding overflows its parent element. To illustrate this, in Google Chrome Developer Tools, find and click the HTML row for the green element whose bottom padding will not show. Chrome will highlight the element on the page. Notice how the padding is included in the highlighted element. The padding actually overflows the parent element. The parent element won't show it though because there's no content in or after the padding (no 'bounds').
From the css spec regarding box models:
Adjoining vertical margins collapse, except:
...
Horizontal margins never collapse.
Two margins are adjoining if and only if:
...
both belong to vertically-adjacent box edges, i.e. form one of the following pairs:
top margin of a box and top margin of its first in-flow child
bottom margin of box and top margin of its next in-flow following sibling
bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height
...
Note the above rules imply that:
...
Margins of elements that establish new block formatting contexts (such
as floats and elements with 'overflow' other than 'visible') do not
collapse with their in-flow children.
Unfortunately, text-overflow: auto is slightly risky because the spec says:
auto
The behavior of the 'auto' value is user agent-dependent,
but should cause a scrolling mechanism to be provided for overflowing boxes
However, all browsers that I have looked at appear to implement it in the following manner:
The box is expanded to the smaller amount between:
as much as its containing box allows
as much as is necessary to display the content without clipping
Then if clipping must occur, a scrollbar is added.
I'm having trouble figuring out why inline elements ignore line-height in some browsers (Chrome and Firefox ignore it, but IE9 does not).
Here is an example:
<small style="line-height: 1; font-size: 26px;">Hello, World</small>
The expected result is for the element height to be 26px, however, it's being set to 31px. If I set the element's display to block, the height is correctly set to 26px.
Everything I read says it's supposed to be set to the line height, so I can't figure this one out. Here is what I read on W3C:
The height of each inline-level box in the line box is calculated. For replaced elements, inline-block elements, and inline-table elements, this is the height of their margin box; for inline boxes, this is their 'line-height'.
Source: http://www.w3.org/TR/CSS2/visudet.html#line-height
What webkit inspector shows (and what you measured in PhotoShop) is the content area's dimensions.
See http://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced
The height of the content area [of inline elements] should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font...
Different browsers simply use a different approach here. See http://jsfiddle.net/ejqTD/1/ for an illustration of that. Note how webkit renders a higher content area, but line-height is still correct.
The content area exceeds the line box in this case, which is permitted: http://www.w3.org/TR/CSS2/visudet.html#leading
if the height specified by 'line-height' is less than the content height of contained boxes, backgrounds and colors of padding and borders may "bleed" into adjoining line boxes.
It's easy to see if you consider line-heights < 1: http://jsfiddle.net/KKMmK/
This is my code :
HTML
<div class='father'>
<div class='son'>Son</div>
</div>
CSS
.father
{
background-color:blue;
}
.son
{
margin-top:50px;
background-color:red;
height:50px;
}
Where is the background-color blue of the father?
I know how to fix this problem (putting padding-top:1px to the father) but I'd like to know why of this behaviour!
For me it doesnt make sense, because on every browsers, not only IE, this is the behaviour.
This is a result of Collapsing Margins. You can read a good article by Eric Meyer on this topic where he illustrates this exact behavior. The following image is from his article.
Here's what the CSS2 specification has to say about it.
8.3.1 Collapsing margins
If the top and bottom margins of a box are adjoining, then it is
possible for margins to collapse through it. In this case, the
position of the element depends on its relationship with the other
elements whose margins are being collapsed.
If the element's margins are collapsed with its parent's top margin, the top border edge of the box is defined to be the same as
the parent's.
Otherwise, either the element's parent is not taking part in the margin collapsing, or only the parent's bottom margin is involved.
The position of the element's top border edge is the same as it
would have been if the element had a non-zero bottom border.
Note that the positions of elements that have been collapsed through
have no effect on the positions of the other elements with whose
margins they are being collapsed; the top border edge position is only
required for laying out descendants of these elements.
Source: http://www.w3.org/TR/CSS2/box.html#collapsing-margins
This is because the div is a block-level element. Certain block-level elements don't contain any padding by default. Divs are one such element. Block-level elements will take up the entire height and width of the container while respecting any padding it may contain.
W3C Visual formatting model
The parent element's height is set to its content's height by default. Once you set a height on the parent, that's no longer the default. Checking up on it, I believe that the padding adds to the height. So, the height is originally determined by the content unless otherwise stated in the CSS. Then, in most cases (IE 6 may be the exception), the padding is added to the height.
Good thing about SO, it helps us be much more detailed in our responses. :)
In CSS, block level elements naturally fills the elements content area, so your "son" div is filling your "father" div completely. Of course, you can bypass this by adding margin/padding/height to your parent div.
You're setting blue explicitly:
.father {
background-color:blue;
}
It's overridden (thanks to the "C" in CSS a.k.a cascading) but the style remains on your parent element (here, appropriately named "father").
If your .father box receives any height at all (check in the Firebug/Chrome dev tools inspector) than the blue is going to show through. I am guessing this is what you're seeing in IE (that or perhaps there's a flash of content before your child element style comes in). I don't think the IE debug tools show bounding boxes but you can test the element for it's height using JavaScript.
Moving outwards from the content, you have padding, border, and margin (as you probably know). Background covers only padding, but not margin.
I was trying for display:inline property and I found same question for which I was looking....and here I got this answer, it makes me very clear ....but I am not clear about these lines ...
Basically margin, padding and border
can be set on inline-level elements,
but they may not behave as you expect.
The behavior will probably be OK if
there's only one line, but other lines
in the same flow will likely exhibit
behavior different from your
expectations (i.e. padding will not be
respected).
so please anybody can make me clear about these lines...I have also tried for display :inline here
You cannot set height, margin-top, margin-bottom, padding-top and padding-bottom on an inline element. You can set margin left and right an padding left an right.
You can set with on an inline element but then it will behave like a block element: See here
Inline Elements will always be displayed next to each other as long a they fit next to each other.
yes inline element behave differently other then block element. the main point of inline element is that is doesn't take vertical margin & padding.
inline elements like a, span
you can give inline-block instead of inline
this is a best example related to your question
http://www.maxdesign.com.au/articles/inline/
EDIT
yes, padding-bottom pushing the inline element down but it's not add any width to your inline element means when the content move to new line it's going to overlap each other & in block element margin, padding & border are adding width,height & space the block element
check these link for more
http://reference.sitepoint.com/css/inlineformatting
with this property set (display:inline) you can't set width and height of your element. Margin, padding & border is ok. I'd use floating instead, but that's because it gives me more flexibility sometimes. =]
It is saying that if you have an inline element that goes all the way to the right of the page and then wraps around to the left (for example, a single line of text that takes up two lines of space) then you may have unexpected consequences. In particular the padding may not display as desired.
An inline element, when it doesn't break on to multiple lines, respects left/right padding - so you see the padding-left and padding-right inside the left and right edges of the element respectively.
When the inline element does break on to multiple lines, the padding is somewhat respected, in that again both left and right inside edges of the element have padding. The part where it isn't respected is exactly the part where the element breaks, the break-point doesn't have any padding because it simply spreads itself onto the next line.
A block element on the other hand, does respect padding properly because it adds the padding and the contents of the element break inside that padding.
Here's a quick image to help explain what I've explained: