CSS2.1 Section 10.6.1 specifies:
The height of the content area 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.
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'.
Then, the statements that seem contradictory follow in 10.8 Line height calculations:
The height of a line box is determined as follows:
The height of each inline-level box in the line box is calculated. For inline boxes, this is their 'line-height'....
And:
User agent must align glyphs in a non-replaced inline box to each other by their relevant baselines....
The height of the inline box encloses all glyphs and their half-leading on each side and is thus exactly 'line-height'
There is something I am not fully understanding here.
Is the height of inline-level boxes equal to the line-height property set on them (with the minimum being the line-height set on the parent block container element), OR is it just determined by the font height (and UA implementation)?
EDIT
Just to avoid confusion (since there are many posts about this):
I know that an inline-level element's content height is equal to the font it contains (and UA implementation)
I realize the spec does state that in 10.6.1, but in 10.8.1 it states that the height of an inline-level box is equal to its line-height
That seems contradictory to me
My purpose with this post is to discuss the wording in the spec, in order to fully understand what it means and how it ties in with reality
EDIT:
To avoid the "opinion based" close votes, I have changed the title. It is not my opinion that the spec is contradictory, and I am not asking for anyone else's opinion on whether it is contradictory either.
I realize it is not actually contradictory, I was just trying to understand why it is not, given its wording.
Is the height of inline-level boxes equal to the line-height property set on them (with the minimum being the line-height set on the parent block container element),
Yes it is.
OR is it just determined by the font height (and UA implementation)?
No it isn't
CSS is really about boxes, not elements, and you should try not to confuse the two.
So an inline element has associated with it a number of boxes. A content box, padding box, border box and margin box. It also has zero (if display:none), one, or multiple inline boxes. The content box, paddings, borders and margins may be divided among the inline boxes so that the inline content can be spread over more than one line.
The inline box's height is the content height adjusted by the leading. It's the leading that does the magic here. The leading is defined as the line-height of the element minus the content height of that inline box.
Simply rearranging that equation tells us that the height of the inline box depends only on the line-height and not on the content box (or padding, border, margin boxes).
Note that none of the above discusses the line box, which is a different thing again and not a direct property of inline elements or their boxes. The line box is constructed by arranging the inline boxes that occur on the same line such that their vertical alignments fit the rules computed for the elements, including the zero width inline box formed by the strut.
Each line box is bounded by the top of uppermost inline box and the bottom of the lowestmost inline box that that line box contains.
Digression: On why the height of the line box can surprise.
Suppose we have a simple case of a containing block which just contains one short inline element (i.e. short enough that it fits in a single line box). Also suppose that everything is aligned on the baseline. Let's say that the line-height is set on the containing box to 20px, and the inline element inherits that. Also suppose that the font-size (em-square) of the containing block is 16px, and that means that the font metrics compute to an ascent (above the baseline) of 14px and a descent (below the baseline) of 4px.
So the content area for the strut is (14px + 4px =) 18px high. The line-height is 20px, so there is 2px leading, 1px goes above the ascent, and 1px below the descent. So the line-height of the strut is made of 15px above the baseline and 5px below the baseline.
Now, suppose that the font-size of the inline element is set to 0.5em (i.e. half that of the containing block). The content area for the inline element will be an ascent of 7px and a descent of 2px. The line-height is still 20px, so the leading is 20px - (7px + 2px) = 11px, meaning that 5.5px goes above the ascent and 5.5px goes below the descent. This results in the line-height for the inline element is made of 12.5px above the baseline and 7.5px below the baseline.
Since the strut and the inline element are aligned vertically to their baselines, the top of the uppermost inline box (the strut) is 15px above the baseline and the bottom of the the lowermost inline box (the inline element) is 7.5px below the baseline, the actual height of the line box is not 20px but (15px + 7.5px =) 22.5px.
As I explained in this previous question (Why is there space between line boxes, not due to half leading?) we have the content area and the line box.
The content area is defined by the font properties and the UA (like described in your first quote) and the line box is defined by the line-height (like described in your second quote). Here is some example to show different height of content area based on different fonts and to illustrate the difference with the line box:
span {
border-left: 1em solid red;
background: rgba(255, 0, 0, 0.2);
}
.container>div {
margin-bottom: 5px;
border: 1px solid;
line-height: 30px;
}
.container>div:nth-of-type(1) span{
font-family: arial;
font-size: 25px;
}
.container>div:nth-of-type(2) span{
font-family: "open sans";
font-size: 20px;
}
.container>div:nth-of-type(3) span{
font-family: monospace;
font-size: 30px;
}
.container>div:nth-of-type(4) span{
font-family: cursive;
font-size: 22px;
}
<div class="container">
<div>
<span>Hello World</span>
</div>
<div>
<span>Hello World</span>
</div>
<div>
<span>Hello World</span>
</div>
<div>
<span>Hello World</span>
</div>
</div>
As you can see the background and border apply to the content area that is defined by the font-family and font-size. For all the cases, I set the line-height to be equal 30px thus all the line boxes are equal.
We can also notice that the border-left behave differently which indicates that indeed the height of the content area depends on the font and UA.
Here is the same example with some vertical padding/margin/border in order to illustrate how they affect the content area and has nothing to do with line-height:
span {
border-left: 1em solid red;
background: rgba(255, 0, 0, 0.2);
font-family: arial;
font-size: 25px;
}
.container>div {
margin-bottom: 5px;
border: 1px solid;
line-height: 40px;
}
.container>div:nth-of-type(1) span {
padding: 10px;
}
.container>div:nth-of-type(2) span {
border-bottom: 5px solid red;
}
.container>div:nth-of-type(3) span {
padding: 10px;
background-clip: content-box;/*I limit the background to content-box only*/
}
.container>div:nth-of-type(4) span {
margin: 20px;
}
<div class="container">
<div>
<span>Hello World</span>
</div>
<div>
<span>Hello World</span>
</div>
<div>
<span>Hello World</span>
</div>
<div>
<span>Hello World</span>
</div>
</div>
Related
I thought 'what determines height of content-box' and thought line-height might.
It seems to be the case you can determine it for block elements with line-height.
<p style="background-color: grey; font-size: 16px; line-height: 2em;">Is line-height same as height of p tag?</p>
<div style="background-color: lightsalmon; font-size: 16px; line-height: 2em;">Is line-height same as height of div tag?</div>
<span style="background-color: aquamarine; font-size: 16px; line-height: 2em;">Is line-height same as height of span tag?</span>
Inline elements seems a different story. Would someone be able to elaborate?
For block elements its quite easy but you need to distinguish between two different cases. When we have an IFC (inline formatting context) or BFC (block formatting context). From the specification you can read
If 'height' is 'auto', the height depends on whether the element has any block-level children and whether it has padding or borders:
The element's height is the distance from its top content edge to the first applicable of the following:
the bottom edge of the last line box, if the box establishes a inline formatting context with one or more lines
the bottom edge of the bottom (possibly collapsed) margin of its last in-flow child, if the child's bottom margin does not collapse with the element's bottom margin
the bottom border edge of the last in-flow child whose top margin doesn't collapse with the element's bottom margin
zero, otherwise
Only children in the normal flow are taken into account (i.e., floating boxes and absolutely positioned boxes are ignored, and relatively positioned boxes are considered without their offset)
If we consider an IFC then the line boxes will define our height exactly like your examples where in the div and p you have one line box defined by the line-height.
If we consider a BFC then the (2) and (3) apply. Here, you can see it as a recursive definition because having a BFC means we have other blocks inside and those blocks will follow the same rules (either BFC or IFC and so on). In addition, we consider the margin collapsing rules to get the final height.
If the block is empty then it's zero.
Of course, this consider the case of height:auto. If you explicitely set a height then it's trivial.
For inline elements you can refer to this part of the specification:
The 'height' property does not apply. The height of the content area 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. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.)
Here is a bit tricky but the rule is simple: you cannot control or set the height of the content area. Only the font properties you will be using will define the final height.
You should also note that the content area is different from the line box.
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.
<span style="background-color: aquamarine; font-size: 16px; line-height: 2em;">Is line-height same as height of span tag?</span>
<br>
<span style="background-color: aquamarine; font-size: 16px; line-height: 4em;">Is line-height same as height of span tag?</span>
<br>
<span style="background-color: aquamarine; font-size: 16px; line-height: 8em;">Is line-height same as height of span tag?</span>
If you increase the line-height you will clearly notice that the background won't cover a bigger area but only the line box will be bigger
Some related question to get more details and understand the difference between line box and content area:
Can specific text character change the line height?
Box Model for Inline Elements
Why is there space between line boxes, not due to half leading?
So line-height will indeed define the height of block element and not inline element since the block element height will depend on the height of the line boxes and the height of line boxes are defined with line-height1
Here is an example to show a block element having its height defined by the line box and the content area of the inline element inside will oveflow because they play no role in defining the line boxes:
p {
margin:50px;
font-size:35px;
border:1px solid red;
line-height:0;
}
span {
background:green;
line-height:10px;
}
<p>
<span>some text here and there</span>
</p>
<p>
<span style="font-family:cursive">some text here and there</span>
</p>
In both examples, we have a height equal to 12px for the p (10px of line-height + 2px of border) and our inline element is having a different height in each case because the font is not the same.
1: We should note that in practise it can be more complex and the value of line-height alone isn't enough.
If we read the specficiation we can see that:
On a block container element whose content is composed of inline-level elements, line-height specifies the minimal height of line boxes within the element.
Then
On a non-replaced inline element, line-height specifies the height that is used in the calculation of the line box height.
That's why in the last example I made the line-height of the block element to be 0 so only the line-height of the inline elements inside will define the final height of the linebox
Even the vertical alignment play a role here because if we have multiple elements not aligned the same way and with different line-height, finding the result will be more complex:
p {
margin:50px;
font-size:35px;
border:1px solid red;
line-height:0;
}
span {
background:green;
line-height:1;
}
<p>
<span>AB</span> <span >AB</span>
</p>
<p>
<span>AB</span> <span style="vertical-align:super">AB</span>
</p>
To find the height of a linebox you need to consider 3 factors:
The line-height of the block container (the IFC)
The line-height of the inline elements inside
the vertical alignment of inline elements
Let's not forget that line-height is inherited so if we don't set it explicitely we need to either consider the value of the parent element or the default one.
I'm testing some css styles on a blog-like div layout. I used div{border: 1px solid black;} to see the divs and look at its positions.
When this line is in my style, it looks right, but I don't want to have the borders (just had it for development).
As soon as I comment it out everything changes it's positions. Why is this so?
JSFiddle Link
div{border: 1px solid black;} /* Comment this to see the problem */
body{ text-align:center; }
.postTabs{
float:left;
background-color: #c8c8c8;
width: 60px;
height: 38px;
padding: 27px 5px 5px 5px;
border-radius: 50%;
}
.postContent{
padding: 15px 15px 15px 50px;
margin-left: 35px;
margin-top: 36px;
text-align: left;
background-color: #a7a7a7;
}
<div class="postContainer">
<div class="postTabs">asdf</div>
<div class="postContent">
<div class="postBody">adf</div>
</div>
</div>
This is because of collapsing margins:
8.3.1 Collapsing margins
In CSS, the adjoining margins of two or more boxes (which might or
might not be siblings) can combine to form a single margin. Margins
that combine this way are said to collapse, and the resulting combined
margin is called a collapsed margin.
Also the spec states:
Two margins are adjoining if and only if:
both belong to in-flow block-level boxes that participate in the same block formatting context
no line boxes, no clearance, no padding and no border separate them (Note that certain zero-height line boxes (see 9.4.2) are ignored for
this purpose.)
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
top and bottom margins of a box that does not establish a new block formatting context and that has zero computed 'min-height', zero
or 'auto' computed 'height', and no in-flow children
In this case, the first child is floated to a side and it is removed from normal flow. Hence the first in-flow child of the .postContainer container is .postContent element which has a margin-top of 36px.
Since the container doesn't establish a block formatting context, and there's no border, padding between them, the margins would be collapsed into one.
You could prevent that by giving the container:
A padding-top of 1px - for instance - Example here.
A border-top of 1px solid transparent Example here.
An overflow of anything other than visible which creates a new block formatting context - Example Here.
For further info you could refer to the spec.
Check the fiddle here
JS Fiddle
it was happening because of float:left for .postTabs class
.postContainer{
clear: both;
float: left;
width: 100%;
}
This is because of the default box model in CSS. The element is as wide as the width, plus any padding, plus any border.
You may have expected the border to sit inside of the element, but it actually makes it wider (by 2px in your case) and taller (again by 2px).
You can adjust your width and height accordingly, or you can change the box-model being used with the CSS box-sizing: border-box;
In your case, though, you are only applying the border for development purposes, so changing your CSS to support the border will mean changing it all back again later.
Rather than do all that work, use your browser tools. The screenshot below shows the browser tools in Firefox (all browser have similar tools to this). When you highlight the element in the HTML shown in the tools, it shows the outline of the element on the actual page.
This gives you your development view whenever you need it without having to change the code.
See http://jsfiddle.net/6taruf65/1/
The following html appears as 20 pixels tall in Firefox31 and Chrome36 on Windows7. I expected it to be 16 pixels tall.
<style>
* { margin: 0; padding: 0; border: 0; overflow: hidden; vertical-align: baseline; }
</style>
<div style="font-size: 16px;">help 16px</div>
Notice the bottom of the p is cut off when you limit the div's height to 16px. That suggests to me there's unused space above the text. It might be a problem with vertical alignment. But then how would I go about preventing that issue when I want to precisely control the height and alignment of the text?
This is because the default line-height value that is applied by the user agent. Some of web browsers apply a line-height of 1.2em or 1.2 or 120% to the elements while the spec recommends:
We recommend a used value for normal between 1.0 to 1.2.
CSS Level 2 Spec states:
line-height
On a block container element whose content is composed of inline-level
elements, line-height specifies the minimal height of line boxes
within the element. The minimum height consists of a minimum height
above the baseline and a minimum depth below it, exactly as if each
line box starts with a zero-width inline box with the element's font
and line height properties.
The accepted values are normal | <number> | <length> | <percentage> | inherit
Hence, you could override the applied value by adding a line-height of 16px or simply a value of 100% or 1em or 1 to the element. (Click on each one to see the demo).
<number> - e.g. line-height: 1 - is the preferred value of line-height as it always refers to the element's font size. Therefore you don't have to specify different values for different font sizes.
For further info about the difference between these values, you could refer to my answer here:
Calculate line-height with font in rem-value
Maybe you need line-height: 16px;
The div size is not 20px because the font-size is larger than 20px when you have letters that hang below the baseline (such a p and q). If you want the div itself to be of height 20px, just set the div css to height: 20px.
JSFiddle
<div style="height: 20px; font-size: 20px; border:1px solid #444;">help 20px (with cut off text)</div>
<br />
<div style="height: 23px; font-size: 20px; border:1px solid #444;">help 20px (without cut off text)</div>
<br />
I'm working through a CSS problem at http://www.codecademy.com/courses/web-beginner-en-jNuXw/0/1?curriculum_id=50579fb998b470000202dc8b (actually, just helping a friend learn HTML/CSS) and came across a curious issue. If you erase the content in any of the <p> tags within a <div>, the div shifts upward. For example, delete the word 'Mom' without deleting the <p>. As best as I can figure out, this is because the element is set to vertical-align: baseline and for some reason the baseline is changing. I just can't figure out exactly why it's changing or what is causing it to change.
To be clear, I'm not asking for help to get the div's to align. That's simply a matter of setting their vertical-align to 'top'. I'm just trying to understand how the document flow is calculated. The specific question is: why does the empty div shift upwards?
DEMO: jsFiddle
UPDATE: Here is a new jsFiddle - http://jsfiddle.net/tonicboy/2DtTw/3/ which removes a lot of rules to boil the problem down to a simplified use case. From this, we can see that when a <p> tag has text in it, the baseline of the parent <div> is set at the baseline of the text. When you remove the text, the baseline of the parent <div> is set to the bottom of the <div>. Why is that?
HTML:
<div class="friend" id="best_friend"><p>Arthur</p></div>
<div class="friend"><p>Batmanuel</p></div>
<div class="friend"><p>Captain Liberty</p></div>
<div class="friend"><p>The City</p></div>
<div class="friend"><p>Justice</p></div>
<div class="family"><p></p></div>
<div class="family"><p>Dad</p></div>
<div class="family"><p>Bro</p></div>
<div class="family"><p>Sis</p></div>
<div class="family"><p>Rex</p></div>
<div class="enemy"><p>Baron Violent</p></div>
<div class="enemy"><p>The Breadmaster</p></div>
<div class="enemy"><p>The Deadly Nose</p></div>
<div class="enemy"><p>Dinosaur Neil</p></div>
<div class="enemy" id="archnemesis"><p>Chairface</p></div>
CSS:
div {
position: relative;
display: inline-block;
height: 100px;
width: 100px;
border-radius: 100%;
border: 2px solid black;
margin-left: 5px;
margin-top: 5px;
text-align: center;
}
div p {
position: relative;
margin-top: 40px;
font-size: 12px;
}
.friend {
border: 2px dashed green;
}
.family {
border: 2px dashed blue;
}
.enemy {
border: 2px dashed red;
}
#best_friend {
border: 4px solid #00C957;
}
#archnemesis {
border: 4px solid #cc0000;
}
I think I've mostly figured out the reason, after digging through W3C specs. Here are three key items from the spec which may explain this behavior:
"Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose."
When you delete the text, the <p> element is no longer in-flow.
"The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge."
Because there are no in-flow elements within the parent div, the baseline becomes the bottom margin.
Because the div's are set to display: inline-block, their default vertical alignment is 'baseline'
Because the other div's have in-flow elements (the <p> tags), their baseline is set to the text baseline.
And that is why the empty box's bottom margin aligns with the baseline of the <p> tags in the other div's.
The baseline of the element is shifting because the text inside the <p> determs the baseline height:
In an inline formatting context, boxes are laid out horizontally, one
after the other, beginning at the top of a containing block.
Horizontal margins, borders, and padding are respected between these
boxes. The boxes may be aligned vertically in different ways: their
bottoms or tops may be aligned, or the baselines of text within them
may be aligned.
source: http://www.w3.org/TR/CSS2/visuren.html#block-formatting
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
CSS assumes that every font has font metrics that specify a
characteristic height above the baseline and a depth below it. In this
section we use A to mean that height (for a given font at a given
size) and D the depth. We also define AD = A + D, the distance from
the top to the bottom.
source: http://www.w3.org/TR/CSS2/visudet.html#inline-box-height
So with this block being a inline-block and baseline is calculted based on the line-height which is calcuted by different font types. Because this <p> has no font/text the baseline will not be positioned.
place all the line-height: 0; and you will see that the one with no text/font doesn't react like the other does:
jsFiddle
So why are the other two elemets shifting that have text in them?
Well it's because the text excist of two lines of text. The margin of the text is bigger and uses more space, thus the baseline is pushed further
Why isn't the image centered in the li? The dimensions of it is 25x25px.
#information-list li {
height: 50px;
line-height: 50px;
padding: 0 10px;
border-bottom: 1px solid #c1c0bf;
}
#information-list li img {
vertical-align: middle;
margin-right: 10px;
}
<ul id="information-list" class="flat-list">
<li>
<img src="images/test.png" />
<strong>Foo</strong>
</li>
...
Try this instead:
#information-list li {
height: 50px;
line-height: 50px;
padding: 0 10px 0 20px;
border-bottom: 1px solid #c1c0bf;
background:transparent url(images/test.png) no-repeat left center;
}
<ul id="information-list" class="flat-list">
<li>
<strong>Foo</strong>
</li>
...
It is vertically centered for me (tested your css/markup in Chrome/Firefox/IE)
Do you have a valid doctype?
You can read about vertical-align, and how it works here.
As commented by animuson, here is how you should use inline elements and vertical-align.
Essentially, you need to vertically align both inline elements, and you did it on one only.
You should also try to keep line-height properties on blocks that contain text.
Here's a JSFiddle example - I also included some proof that it is in fact centered
CSS
#information-list li {
padding: 0 10px;
border-bottom: 1px solid #c1c0bf;
}
#information-list li img,
#information-list li span{
vertical-align:middle;
}
#information-list li span{
font-weight: bold;
line-height: 50px;
}
HTML
<ul id="information-list" class="flat-list">
<li>
<img src="images/test.png" />
<span>Foo</span>
</li>
...
Here's a screenshot
W3C will give us a bit of insight.
www.w3.org - line-height:
On a block container element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element.
The minimum height consists of a minimum height above the baseline and a minimum depth below it, exactly as if each line box starts with a zero-width inline box with the element's font and line height properties. We call that imaginary box a "strut." (The name is inspired by TeX.).
The height and depth of the font above and below the baseline are assumed to be metrics that are contained in the font. (For more details, see CSS level 3.)
On a non-replaced inline element, 'line-height' specifies the height that is used in the calculation of the line box height.
www.w3.org - vertical-align:
This property affects the vertical positioning inside a line box of the boxes generated by an inline-level element.
Note. Values of this property have different meanings in the context of tables. Please consult the section on table height algorithms for details.
The following values only have meaning with respect to a parent inline element, or to the strut of a parent block container element.
In the following definitions, for inline non-replaced elements, the box used for alignment is the box whose height is the 'line-height' (containing the box's glyphs and the half-leading on each side, see above). For all other elements, the box used for alignment is the margin box.
The default blocks
The HTML you provided consists of 4 blocks which have these display properties by default.
<ul> - treated as a block
<li> - treated as list-item
<img> - is treated as an inline-block (placed as inline, but formatted as a block)
<strong> - treated as inline
Try to remember them. Though they have little impact on this particular scenario, it is good to know the defaults and what they do and what they are for.
See also
9.2.2.1 Anonymous inline boxes
Any text that is directly contained inside a block container element (not inside an inline element) must be treated as an anonymous inline element.