In CSS and HTML how does height: auto work? What do browsers consider while calculating height of the element, for which height is set to auto?
You can split two cases:
div and other containers: the height is the one the browser will use if you don't specify anything, trying to contain the element contents. (read Mathijs's answer for more details)
images and other block elements with intrinsic dimensions (width and height): if you specify the width, then "height: auto" will scale proportionally.
So, in other words, is useless unless you need to reset the browser behaviour or keep proportions to some objects.
Here's an excerpt on this copied from the W3C CSS2 spec
If it only has inline-level children, the height is the distance
between the top of the topmost line box and the bottom of the
bottommost line box.
If it has block-level children, the height is the distance between the
top margin-edge of the topmost block-level child box and the bottom
margin-edge of the bottommost block-level child box.
Absolutely positioned children are ignored, and relatively positioned
boxes are considered without their offset. Note that the child box may
be an anonymous block box.
In addition, if the element has any floating descendants whose bottom
margin edge is below the element's bottom content edge, then the
height is increased to include those edges. Only floats that
participate in this block formatting context are taken into account,
e.g., floats inside absolutely positioned descendants or other floats
are not.
Related
According to MDN, a button is an inline element.
However, button elements have default styling with display: inline-block (See this question)
button, textarea,
input, select { display: inline-block }
So far so good.
However:
If I now set the button with display:inline - width still applies!!
DEMO
button,
div {
width: 200px;
border: 1px solid red;
display: inline;
}
<button>button</button>
<div>div</div>
Now, according to the spec: width does not apply to inline elements (which are non-replaced)
Applies to: all elements but non-replaced inline elements, table rows,
and row groups
That being the case:
Why does width still apply to an inline button element?
As mentioned in the comments, I'm pretty sure this has to do with browser-specific rendering behavior as is so typical of form elements. What I believe is happening when you set display: inline on the button is... nothing. Effectively, it's the same as the typical browser default display: inline-block, on which the width property does apply.
Refer to section 10.2, which describes the width property itself. In particular it explains why exactly the width property does not apply to inline elements (or inline boxes):
This property does not apply to non-replaced inline elements. The content width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children). Recall that inline boxes flow into line boxes. The width of line boxes is given by the their containing block, but may be shorted by the presence of floats.
In short, it's because the content of inline elements resides in line boxes. The width of a line box cannot be controlled directly; it is determined entirely by the containing block and any incidental floats. You can see an example of line box rendering in section 9.4.2, which describes inline formatting contexts.
If display: inline actually made a button render as an inline box, all its contents would spill over and it would no longer look, or function, like a button. It makes sense to want to prevent that from happening, and I think that's just what browsers do.
So what exactly do they do to prevent this? Is a button a replaced element? I can't say for sure. But note, in section 9.2.2, it says:
Inline-level boxes that are not inline boxes (such as replaced inline-level elements, inline-block elements, and inline-table elements) are called atomic inline-level boxes because they participate in their inline formatting context as a single opaque box.
Section 10 does not explicitly mention atomic inline-level boxes, but it does have sections for calculating dimensions for inline replaced elements, as well as inline-block elements whether replaced or non-replaced, all of which are considered atomic inlines as mentioned above. In all of these cases, the width property applies as normal if it's not auto.
So, while it's still debatable whether or not a button is a replaced element, it probably doesn't matter at all for the purposes of this question. But it is still some kind of atomic inline element, since it still participates in an inline formatting context. For what it's worth, though, it appears to shrink to fit its contents if you don't set a width, so its behavior is probably closer to that of an inline-block in that case. One could say then that the actual value of display becomes inline-block, although this is never reflected in the developer tools because the computed value does not change (again a side effect of browser-specific rendering behavior).
Since like Boltclock, I don't think that there's a simple answer to this, this is as much a dump of my thoughts on the subject as an answer, but I hope it will be informative.
Although the CSS display property is superficially quite simple, it actually contains a multitude of aspects. The CSS level 3 draft spec css-display captures some of this complexity, but still doesn't seem to cover it adequately.
The HTML5 spec says for the rendering of <button> elements:
When the button binding applies to a button element, the element is
expected to render as an 'inline-block' box rendered as a button whose
contents are the contents of the element.
An inline-block box has a number of aspects to it:
1. An inline-level element
This means that it participates in a inline formatting context within a line box. It flows in sequence with other elements that are on the same line. The line box's content can be centre aligned with text-align:center property on its container, and the line box is shortened by avoiding floated elements.
2. Applies a width property and the auto value is shrink-to-fit
Unlike non-replaced display:inline elements, the width value applies. But also, if a width value is not specified, a shrink-to-fit algorithm is applied to determine the width. This is like floated elements, or display:table elements, but different from display:block elements which are as wide as possible if no width is specified. It's also unlike replaced inline elements and replaced inline-block elements which, if no width is specified, use their intrinsic width if they have one and a default value of 300px if they don't. Shrink-to-fit is a meaningless concept for replaced elements.
3. A block-container element
Block container elements are make up of a stack of line boxes. The content flows from one line box to the next and the height of the inline-block elements grows (subject to overflow) to fully contain all the line boxes.
4. The baseline is the baseline of the last contained line box
When the inline-block element contains multiple lines, its baseline is the last of those lines. This is unlike floats or display:table-cell elements which are also shrink-to-fit, block container elements. Floats are outside normal flow so they do not have a baseline, which display:table-cell elements have a baseline that is the baseline of their first line box. A button that has multiple lines does vertically align according this last line box rule.
Now, this is fine for the default display setting. and the HTML5 rendering requirement means that the used value of display for buttons is inline-block even when the specified value is inline. But it doesn't account for the behaviour when specified value is block. In this case, the element has a line-break before and after it, and margin:auto centres the box as a display:block element would, and is not what would be expected of inline-block.
However, its width for a specified value of auto is shrink-to-fit like inline-block, whereas the expected behaviour for display:block is as-wide-as-possible. As far as I know, the only display value that behaves like that is display:table, but there is nothing else to suggest that display:table is being used.
So there's nothing in the spec that I can find which matches this precisely. We can only hope that when the css-display spec gets completed, that it will cover this behaviour.
There are 2 types of element.
Non-replaced elements
Replaced elements
Button belongs to replaced element category.
You can find more on below link.
Littlewebhut
SitePoint
So, for button, according to spec, it becomes right.
Inline, non-replaced elements
The width property does not apply. A computed value of auto for margin-left or margin-right becomes a used value of 0.
Inline, replaced elements (This section applies to button)
A computed value of auto for margin-left or margin-right becomes a used value of 0.
If height and width both have computed values of auto and the element also has an intrinsic width, then that intrinsic width is the used value of width.
If height and width both have computed values of auto and the element has no intrinsic width, but does have an intrinsic height and intrinsic ratio; or if width has a computed value of auto, height has some other computed value, and the element does have an intrinsic ratio; then the used value of width is:
(used height) * (intrinsic ratio)
If height and width both have computed values of auto and the element has an intrinsic ratio but no intrinsic height or width, then the used value of width is undefined in CSS 2.1. However, it is suggested that, if the containing block's width does not itself depend on the replaced element's width, then the used value of width is calculated from the constraint equation used for block-level, non-replaced elements in normal flow.
If width has a computed value of auto, and the element has an intrinsic width, then that intrinsic width is the used value of width.
If width has a computed value of width, but none of the conditions above are met, then the used value of width becomes 300px.But, if 300px is too wide to fit the device, UAs should use the width of the largest rectangle that has a 2:1 ratio and fits the device instead.
My understanding is,
Width of an element = (left border width + left padding width + content width + right padding width + right border width)
Height of an element = (top border height + top padding height + content height + bottom padding height + bottom border height)
Below is the diagram for the same.
width of an element = (10+10+140+10+10) = 180
height of an element = (10+10+150+10+10) = 190
margin is not included in the size of an element.
content & padding are only included in the click region.
Is the above formula correct on computing width and height of an html element?
It sounds like what you are describing is the offsetWidth and offsetHeight of an element, which returns the "layout width and height" of the element, i.e. the final width after all calculations.
MDN defines offsetWidth the following way:
The HTMLElement.offsetWidth read-only property returns the layout width of an element. Typically, an element's offsetWidth is a measurement which includes the element borders, the element horizontal padding, the element vertical scrollbar (if present, if rendered) and the element CSS width.
So to answer your question, the final layout width of an element is typically the sum of the element's borders, horizontal padding, vertical scrollbar width, and content width.
The final layout height (offsetHeight) would be similar.
The way CSS calculates height and width is not as simple and straightforward as it may seem.
The most direct answer to your question...
How to compute width & height of an element?
...is: It depends on the type of box being used.
According to the CSS Visual Formatting Model:
10.3 Calculating widths and margins
The values of an element's width, margin-left, margin-right,
left and right properties as used for layout depend on the type of
box generated and on each other... The following situations need to be
distinguished:
inline, non-replaced elements
inline, replaced elements
block-level, non-replaced elements in normal flow
block-level, replaced elements in normal flow
floating, non-replaced elements
floating, replaced elements
absolutely positioned, non-replaced elements
absolutely positioned, replaced elements
inline-block, non-replaced elements in normal flow
inline-block, replaced elements in normal flow
10.6 Calculating heights and margins
For calculating the values of top, margin-top, height, margin-bottom, and bottom a distinction must be made between various kinds of boxes:
same list as above
I was actually hoping to create a simple reference guide here by listing the variables that make up the width and height for at least a few of the box types. So I started with block-level and found that calculating the width, in general terms, was easy enough:
containing block width = margin-left + border-left-width + padding-left + width + padding-right + border-right-width + margin-right
However, when I got to height, I found this:
10.6.3 Block-level non-replaced elements in normal flow when overflow computes to visible
This section also applies to block-level non-replaced elements in
normal flow when overflow does not compute to visible but has been
propagated to the viewport.
If margin-top, or margin-bottom are auto, their used value is 0.
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). Note
that the child box may be an anonymous block box.
There are many factors to consider when calculating height.
TL;DR
For an accurate and specific reading of the calculations used to determine the width or height of an HTML element, refer to the CSS Visual Formatting Model. To learn the exact height or width of an element refer to the computed values tab in developer tools.
The width CSS property specifies the width of the content area of an element. The content area is inside the padding, border, and margin of the element.
https://developer.mozilla.org/en-US/docs/Web/CSS/width
This page explains the box model in more detail: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Model/Introduction_to_the_CSS_box_model
According to MDN, a button is an inline element.
However, button elements have default styling with display: inline-block (See this question)
button, textarea,
input, select { display: inline-block }
So far so good.
However:
If I now set the button with display:inline - width still applies!!
DEMO
button,
div {
width: 200px;
border: 1px solid red;
display: inline;
}
<button>button</button>
<div>div</div>
Now, according to the spec: width does not apply to inline elements (which are non-replaced)
Applies to: all elements but non-replaced inline elements, table rows,
and row groups
That being the case:
Why does width still apply to an inline button element?
As mentioned in the comments, I'm pretty sure this has to do with browser-specific rendering behavior as is so typical of form elements. What I believe is happening when you set display: inline on the button is... nothing. Effectively, it's the same as the typical browser default display: inline-block, on which the width property does apply.
Refer to section 10.2, which describes the width property itself. In particular it explains why exactly the width property does not apply to inline elements (or inline boxes):
This property does not apply to non-replaced inline elements. The content width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children). Recall that inline boxes flow into line boxes. The width of line boxes is given by the their containing block, but may be shorted by the presence of floats.
In short, it's because the content of inline elements resides in line boxes. The width of a line box cannot be controlled directly; it is determined entirely by the containing block and any incidental floats. You can see an example of line box rendering in section 9.4.2, which describes inline formatting contexts.
If display: inline actually made a button render as an inline box, all its contents would spill over and it would no longer look, or function, like a button. It makes sense to want to prevent that from happening, and I think that's just what browsers do.
So what exactly do they do to prevent this? Is a button a replaced element? I can't say for sure. But note, in section 9.2.2, it says:
Inline-level boxes that are not inline boxes (such as replaced inline-level elements, inline-block elements, and inline-table elements) are called atomic inline-level boxes because they participate in their inline formatting context as a single opaque box.
Section 10 does not explicitly mention atomic inline-level boxes, but it does have sections for calculating dimensions for inline replaced elements, as well as inline-block elements whether replaced or non-replaced, all of which are considered atomic inlines as mentioned above. In all of these cases, the width property applies as normal if it's not auto.
So, while it's still debatable whether or not a button is a replaced element, it probably doesn't matter at all for the purposes of this question. But it is still some kind of atomic inline element, since it still participates in an inline formatting context. For what it's worth, though, it appears to shrink to fit its contents if you don't set a width, so its behavior is probably closer to that of an inline-block in that case. One could say then that the actual value of display becomes inline-block, although this is never reflected in the developer tools because the computed value does not change (again a side effect of browser-specific rendering behavior).
Since like Boltclock, I don't think that there's a simple answer to this, this is as much a dump of my thoughts on the subject as an answer, but I hope it will be informative.
Although the CSS display property is superficially quite simple, it actually contains a multitude of aspects. The CSS level 3 draft spec css-display captures some of this complexity, but still doesn't seem to cover it adequately.
The HTML5 spec says for the rendering of <button> elements:
When the button binding applies to a button element, the element is
expected to render as an 'inline-block' box rendered as a button whose
contents are the contents of the element.
An inline-block box has a number of aspects to it:
1. An inline-level element
This means that it participates in a inline formatting context within a line box. It flows in sequence with other elements that are on the same line. The line box's content can be centre aligned with text-align:center property on its container, and the line box is shortened by avoiding floated elements.
2. Applies a width property and the auto value is shrink-to-fit
Unlike non-replaced display:inline elements, the width value applies. But also, if a width value is not specified, a shrink-to-fit algorithm is applied to determine the width. This is like floated elements, or display:table elements, but different from display:block elements which are as wide as possible if no width is specified. It's also unlike replaced inline elements and replaced inline-block elements which, if no width is specified, use their intrinsic width if they have one and a default value of 300px if they don't. Shrink-to-fit is a meaningless concept for replaced elements.
3. A block-container element
Block container elements are make up of a stack of line boxes. The content flows from one line box to the next and the height of the inline-block elements grows (subject to overflow) to fully contain all the line boxes.
4. The baseline is the baseline of the last contained line box
When the inline-block element contains multiple lines, its baseline is the last of those lines. This is unlike floats or display:table-cell elements which are also shrink-to-fit, block container elements. Floats are outside normal flow so they do not have a baseline, which display:table-cell elements have a baseline that is the baseline of their first line box. A button that has multiple lines does vertically align according this last line box rule.
Now, this is fine for the default display setting. and the HTML5 rendering requirement means that the used value of display for buttons is inline-block even when the specified value is inline. But it doesn't account for the behaviour when specified value is block. In this case, the element has a line-break before and after it, and margin:auto centres the box as a display:block element would, and is not what would be expected of inline-block.
However, its width for a specified value of auto is shrink-to-fit like inline-block, whereas the expected behaviour for display:block is as-wide-as-possible. As far as I know, the only display value that behaves like that is display:table, but there is nothing else to suggest that display:table is being used.
So there's nothing in the spec that I can find which matches this precisely. We can only hope that when the css-display spec gets completed, that it will cover this behaviour.
There are 2 types of element.
Non-replaced elements
Replaced elements
Button belongs to replaced element category.
You can find more on below link.
Littlewebhut
SitePoint
So, for button, according to spec, it becomes right.
Inline, non-replaced elements
The width property does not apply. A computed value of auto for margin-left or margin-right becomes a used value of 0.
Inline, replaced elements (This section applies to button)
A computed value of auto for margin-left or margin-right becomes a used value of 0.
If height and width both have computed values of auto and the element also has an intrinsic width, then that intrinsic width is the used value of width.
If height and width both have computed values of auto and the element has no intrinsic width, but does have an intrinsic height and intrinsic ratio; or if width has a computed value of auto, height has some other computed value, and the element does have an intrinsic ratio; then the used value of width is:
(used height) * (intrinsic ratio)
If height and width both have computed values of auto and the element has an intrinsic ratio but no intrinsic height or width, then the used value of width is undefined in CSS 2.1. However, it is suggested that, if the containing block's width does not itself depend on the replaced element's width, then the used value of width is calculated from the constraint equation used for block-level, non-replaced elements in normal flow.
If width has a computed value of auto, and the element has an intrinsic width, then that intrinsic width is the used value of width.
If width has a computed value of width, but none of the conditions above are met, then the used value of width becomes 300px.But, if 300px is too wide to fit the device, UAs should use the width of the largest rectangle that has a 2:1 ratio and fits the device instead.
The title is fairly self explanatory. Additional details to consider are...
The element i'm applying the css to will be position:relative
The element will be embedded onto a web page
I'm using left: -9999px to move the element off screen temporarily
The element may or may not move 'over' or 'through' other elements on the page.
Will doing this have any negative effects such as altering the layout/placement of other elements on the page?
Thanks
In most cases, offsetting a relatively-positioned element will not affect the layout of other elements in the same flow, because other elements will only respect the "original" position of the element (i.e. the position if it had not been offset). The offset properties only create a visual effect on the element being offset. From the spec:
Once a box has been laid out according to the normal flow or floated, it may be shifted relative to this position. This is called relative positioning. Offsetting a box (B1) in this way has no effect on the box (B2) that follows: B2 is given a position as if B1 were not offset and B2 is not re-positioned after B1's offset is applied. This implies that relative positioning may cause boxes to overlap.
However, the spec does point out an edge case (immediately after the above portion):
... However, if relative positioning causes an 'overflow:auto' or 'overflow:scroll' box to have overflow, the UA must allow the user to access this content (at its offset position), which, through the creation of scrollbars, may affect layout.
For example, scrollbars can reduce the width of a container and cause other elements to wrap where they otherwise would not.
No.
From MDN:
relative
This keyword lays out all elements as though the element were not positioned, and then adjust the element's position, without changing layout (and thus leaving a gap for the element where it would have been had it not been positioned). The effect of position:relative on table-*-group, table-row, table-column, table-cell, and table-caption elements is undefined.
As you can see in this Demo, the relatively positioned element simply overlaps other elements, without affecting the original layout - the other elements stays as it was previously (other than the fact that currently it's overlapped, obviously).
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.