> values
and those used in functional notations such as ''width/fit-content()''.
In contrast,
non-quantitative values such as ''width/auto'' and ''width/min-content''
are not influenced by the 'box-sizing' property
(unless otherwise specified).
For example, the following properties set
the content-box size of the box to ''100px'',
with the border-box size calculating to ''120px'':
.box {
box-sizing: content-box; /* default */
width: 100px;
padding-left: 10px;
border-left: 10px solid;
}
On the other hand, by changing to ''border-box'',
the border-box is set to ''100px'',
with the content-box size calculating to ''80px'':
.box {
box-sizing: border-box;
width: 100px;
padding-left: 10px;
border-left: 10px solid;
}
The
inner size can't be less than zero,
so if the 'padding' + 'border' is greater than the specified border-box size,
the box will end up larger than specified.
In this case, the content-box size will floor at ''0px''
so the border-box size ends up at ''120px'',
even though ''width: 100px'' is specified for the border box:
.box {
box-sizing: border-box;
width: 100px;
padding-left: 60px;
border-left: 60px solid;
/* padding + border = 120px */
}
This example uses box-sizing to evenly horizontally split
two divs with fixed size borders inside a div container,
which would otherwise require additional markup.
sample CSS:
div.container {
width:38em;
border:1em solid black;
}
div.split {
box-sizing:border-box;
width:50%;
border:1em silver ridge;
float:left;
}
sample HTML fragment:
<div class="container">
<div class="split">This div occupies the left half.</div>
<div class="split">This div occupies the right half.</div>
</div>
demonstration of sample CSS and HTML:
This div should occupy the left half.
This div should occupy the right half.
The two divs above should appear side by side, each (including borders) 50% of the content width of their container. If instead they are stacked one on top of the other then your browser does not support 'box-sizing'.
To avoid ambiguities,
specification authors should avoid ambiguous uses of terms such as width or height without further qualification,
and should explicitly refer and link to
the
inner size,
the
outer size,
the size of the
border-box,
the
computed value of the
sizing properties,
etc,
as appropriate for each case.
New Column Sizing Values: the ''column-width/min-content'', ''column-width/max-content'', and ''column-width/fit-content()'' values
Name: column-width
New values: min-content | max-content | fit-content(<>)
Computed value: as specified, with <> values computed
Animation type: by computed value type
When used as values for 'column-width',
the new keywords specify the optimal column width:
- min-content
- Specifies the optimal column width as the min-content inline size
of the multi-column container's contents.
- max-content
- Specifies the optimal column width as the max-content inline size
of the multi-column container's contents.
- fit-content(<>)
-
Specifies the optimal column width as
min(max-content size, max(min-content size, <>))
Note: The column width never varies by column.
When the column width is informed by the multi-column container's contents
(as in the keywords above),
all of its contents are taken under consideration
and the calculated width is shared by all the columns.
Extrinsic Size Determination
Extrinsic sizing determines sizes based on the context of an element,
without regard for its contents.
Percentage Sizing
Percentages specify sizing of a box with respect to the box’s containing block.
For example, in the following markup:
<![CDATA[
<article style="height: 60em">
<figure style="height: 50%;">
<img style="height: 50%;">
</figure>
</article>
]]>
* the
<figure> would be ''30em'' tall
= 50% of the [=definite=] ''60em'' height of the
<article>
* the
<img> would be ''15em'' tall
= 50% of the
<figure>’s height
(which is itself [=definite=] because it's a percentage resolved against a [=definite=] length)
Intrinsic Size Determination
Intrinsic sizing determines sizes based on the contents of an element,
without regard for its context.
Intrinsic Sizes
The min-content size of a box in each axis
is the size it would have if it was
a float given an ''width/auto'' [=preferred size=] in that axis
(and no minimum or maximum size in that axis)
and if its containing block was zero-sized in that axis.
(In other words, the minimum size it has when sized as “shrink-to-fit”.)
The max-content size of a box in each axis
is the size it would have if it was
a float given an ''width/auto'' [=preferred size=] in that axis
(and no minimum or maximum size in that axis),
and if its containing block was infinitely-sized in that axis.
(In other words, the maximum size it has when sized as “shrink-to-fit”.)
The [=min-content size=] and [=max-content size=] are collectively referred to
as the [=intrinsic sizes=].
Note: When the box has a [=preferred aspect ratio=],
size constraints in the opposite dimension will transfer through
and can affect the ''width/auto'' size in the considered one.
See CSS2§10.
This specification does not define how to determine the sizes of floats.
Please refer to [[CSS2]].
However, the [=intrinsic sizes=] of [=replaced elements=] without [=natural sizes=]
are defined below:
- If it has a [=preferred aspect ratio=]:
-
For the [=min-content size=], use zero.
For the [=max-content size=]:
* If the available space is definite
in the inline axis,
use the stretch fit into that size for the inline size
and calculate the block size using the aspect ratio.
* Otherwise
if the box has a <> as its [=computed value=]
for 'min-width' or 'min-height',
use that size and calculate the other dimension using the aspect ratio;
if both dimensions have a <> minimum,
choose the one that results in the larger overall size.
Note: This case was previous calculated from a 300x150 default size,
rather than the box's min size.
This is believed to be a better behavior,
and likely to be Web-compatible,
but please send feedback to the CSSWG if there are any problems.
* Otherwise
use an [=inline size=] matching
the corresponding dimension of the [=initial containing block=]
and calculate the other dimension using the aspect ratio.
- If it has no [=preferred aspect ratio=]:
-
For both the [=min-content size=] and [=max-content size=]:
* If the box has a <> as its [=computed value|computed=]
[=minimum size=] ('min-width'/'min-height') in that dimension,
use that size.
Note: This author-controllable behavior is made possible
by the new ''min-width/auto'' value for the [=min size properties=].
This is believed to be a better behavior,
but it is not yet clear if it is Web-compatible,
so please send feedback to the CSSWG if there are any problems.
* Otherwise,
use ''300px'' for the width
and/or ''150px'' for the height
as needed.
Since a block-level or inline-level replaced element
whose 'height' or 'width' behaves as auto
is effectively defined to use its max-content size
(CSS2§10.3.2),
this specification applies the rules above
to the undefined case of a replaced element
whose 'height' and 'width' both behave as auto.
Note: This specification does not define how to determine
the size of a float.
Please refer to [[CSS2]],
the relevant CSS specification for that display type,
and/or existing implementations
for further details.
A future specification will define this in detail,
replacing the CSS2 “definition”,
such as it is.
Although the ''width/auto'' size of text input controls
such as HTML’s <input type=text> and <textarea> elements
is typically a fixed size,
the contents of such elements can be used to determine a content-based [=intrinsic size=],
as for non-replaced block containers.
The ''width/min-content'' and ''width/max-content'' keywords of the sizing properties
thus represent content-based sizes
for form controls which render their value
as text contained within their box,
allowing such controls to size to fit their visible contents
similarly to regular non-replaced elements.
The content in this case is defined to be the input control's values
(the [=raw value=] in the case of <{textarea}>,
or the value in the case of <{input}>),
possibly transformed to a more human-readable and/or localized display format,
which is then treated as child text sequences of the input control,
allowing soft wrap opportunities
only where the input control would actually allow wrapping
(whether keyed off of CSS properties or other, UA-internal constraints).
If the input control has designated placeholder text
to be overlaid in its value display area,
then that text is also measured for the purpose of calculating the content-based size--
whether or not the placeholder text is visible at the moment.
(Thus the content-based [=intrinsic size=] of the input control
is the larger of the size to fit the placeholder text and the size to fit the value.)
The UA may enforce a minimum
(such as the size required to contain a single zero-width character,
or the smallest usable size of a touch target)
on the form control’s
min-content and max-content sizes
to ensure sufficient space for the caret
and otherwise maintain usability of the form control.
Note:
This might be extended to <{iframe}> or other content-containing replaced elements
(see discussion),
but text inputs are a major use-case;
and being document-internal,
have the least additional complications.
Intrinsic Contributions
A box’s min-content contribution/max-content contribution in each axis
is the size of the content box
of a hypothetical ''width/auto''-sized float
that contains only that box,
if that hypothetical float's containing block is zero-sized/infinitely-sized.
Note: This specification does not define precisely how to determine these sizes.
Please refer to [[CSS2]],
the relevant CSS specification for that display type,
the rules for handling percentages (below),
and/or existing implementations
for further details.
Intrinsic Contributions of Percentage-Sized Boxes
Sometimes the size of a percentage-sized box’s containing block
depends on the [=intrinsic size contribution=] of the box itself,
creating a cyclic dependency.
When calculating the intrinsic size contribution of such a box
(including any calculations for a content-based automatic minimum size),
a percentage value that resolves against a size
in the same axis as the [=intrinsic size contribution=]
(a cyclic percentage size)
is resolved specially:
-
If the box is [=non-replaced=],
then the entire value of any
[=max size property=] or [=preferred size property=]
('width'/'max-width'/'height'/'max-height')
specified as an expression [=containing a percentage=]
(such as ''10%'' or ''calc(10px + 0%)'')
that is cyclic
is treated
for the purpose of calculating the box’s [=intrinsic size contributions=] only
as that property’s [=initial value=].
For example, given a box with ''width: calc(20px + 50%)'',
its max-content contribution is calculated as if its 'width' were ''width/auto''.
(The percentage is honored as usual, however,
during the actual sizing of the box itself; see below.)
-
Likewise, if the box is [=replaced element|replaced=],
then the entire value of any
[=max size property=] or [=preferred size property=]
specified as an expression containing a percentage
that is cyclic
is treated
for the purpose of calculating the box’s max-content contributions only
as that property’s [=initial value=].
-
If the box is [=replaced element|replaced=],
a cyclic percentage in the value of any
[=max size property=] or [=preferred size property=]
('width'/'max-width'/'height'/'max-height'),
is resolved against zero
when calculating the min-content contribution in the corresponding axis.
(See [[#min-content-zero]] for a list of which elements in HTML this applies to.)
If the box also has a [=preferred aspect ratio=],
then this [=min-content contribution=] is floored
by any <> [=minimum size=] from the opposite axis--
resolving any such percentage against zero--
transferred through the [=preferred aspect ratio=].
ISSUE: Should we resolve transferred percentages against their containing block instead of zero before transferring them? See discussion.
The UA may additionally floor the [=min-content contribution=]
based on UI considerations,
such as ensuring certain UI elements remain visible
(for example, the dropdown arrow on a <{select}>).
Note: The [=min-content contribution=] is, as always,
also floored by the [=minimum size=] in its own axis.
This rule also applies when calculating
a content-based automatic minimum size
or its corresponding size contribution,
yielding a definite “specified size suggestion”.
For example,
an <{input}> assigned ''width: calc(50% + 50px)''
has a
min-content contribution of ''50px'',
plus any horizontal margin/border/padding.
-
For the [=min size properties=],
as well as for [=margins=] and [=paddings=]
(and [=gutters=]),
a cyclic percentage is resolved against zero
for determining [=intrinsic size contributions=].
Summary of the Cyclic-Percentage Intrinsic Size Contribution Rules (Above)
| Element Type
| [=Replaced=]
| [=Non-replaced=]
|
| Contribution Type
| [=min-content contribution|min-content=]
| [=max-content contribution|max-content=]
| [=min-content contribution|min-content=]
| [=max-content contribution|max-content=]
|
| [=min size property|min size=] & [=margin properties|margin=]/[=padding properties|padding=]
| zeroᵈ
| zeroᵈ
| zeroᵈ
| zeroᵈ
|
| [=max size property|max=] & [=preferred size property|preferred size=]
| zeroᶜ
| initialᵇ
| initialᵃ
| initialᵃ
|
Then, unless otherwise specified,
when calculating the used sizes and positions of the containing block’s contents:
* If the cyclic dependency was introduced due to
a [=block-axis=] size other than a [=minimum size=] on the containing block
(i.e. a 'block-size' or 'max-block-size' in most layout modes,
or a 'flex-basis' in [=flex layout=])
that causes it to depend on the size of its contents,
the box’s percentage is not resolved and instead behaves as auto.
Note: Grid items and flex items
do allow percentages to resolve in this case.
* Otherwise, the percentage is resolved against the containing block’s size.
(The containing block’s size is not re-resolved based on the resulting size of the box;
the contents might thus overflow or underflow the containing block).
Note: These rules specify the previously-undefined behavior of this cyclic case
in CSS2§10.2,
CSS2§8.3,
and
CSS2§8.4.
Note also, the behavior in CSS2§10.5
is superseded in their respective specifications for layout modes
(such as flex layout)
not described in CSS2.
For example, in the following markup:
<![CDATA[
<article style="width: min-content">
<aside style="width: 50%;">
LOOOOOOOOOOOOOOOOOOOONG
</aside>
</article>
]]>
When calculating the width of the outer
<article>,
the inner
<aside> behaves as ''width: auto'',
so the
<article> sets itself to the width of the long word.
Since the
<article>’s width didn't depend on "real" layout,
though, it's treated as
definite
for resolving the
<aside>,
whose width resolves to half that of the
<article>.
In this example,
<![CDATA[
<article style="height:auto">
<aside style="height: 50%;">
<div class=block style="height: 150px;"></div>
</aside>
<section style="height: 30px;"></section>
</article>
]]>
because the percentage
block size ('height', in this case) on block-level elements
is defined to not resolve inside content-sized containing blocks,
the percentage height on the
<aside> is ignored,
that is, it behaves exactly as if ''height/auto'' were specified.
Issue: Letting percentages still resolve against a definite 'height'
when the min-height is intrinsic is an open issue.
(CSS2 has a general statement about "height depending on contents",
which this technically is,
even though CSS2 didn't have content-dependent keywords for 'min-height'.
Since this is new, we think we could have this different behavior.)
The following examples illustrate how block-axis percentages resolve against a containing block whose size depends on its contents.
<![CDATA[
<article style="height:100px; min-height: min-content;">
<aside style="height: 50%;">
<div style="height: 150px;"></div>
</aside>
<section style="height: 30px;"></section>
</article>
]]>
The initial height of the
<article> is 100px, as specified,
which would make the
<aside> 50px tall
when it resolved its percentage.
However, we must calculate the min-height,
by substituting it in for 'height'.
This causes the percentage on the
<aside> to
behave as auto,
so the
<aside> ends up 150px tall.
The total height of the contents is thus 180px.
This is larger than the specified 100px height,
so the
<article> gets adjusted to 180px tall.
Then, since the percentage could
originally resolve against the (100px) height,
it now resolves against the 180px height,
so the
<aside> ends up being 90px tall.
<![CDATA[
<article style="height:auto; min-height: min-content;">
<aside style="height: 50%;">
<div class=block style="height: 150px;"></div>
</aside>
<section style="height: 30px;"></section>
</article>
]]>
In this case, the percentage on the
<aside> won't normally resolve,
because the containing block's height is ''height/auto''
(and thus depends on the size of its contents).
Instead it
behaves as auto,
resulting in a height of 150px for the
<aside>,
and an initial height of 180px for the
<article>
The 'min-height' doesn't change this;
''height: min-content;'' acts similarly to ''height: auto;''
and results in the same sizes.
<![CDATA[
<article style="height:100px; min-height: min-content;">
<aside style="height: 200%;">
<div style="height: 150px;"></div>
</aside>
<section style="height: 30px;"></section>
</article>
]]>
This is a variation on the first code block,
and follows a similar path;
the
<aside> initially wants to compute to 200px tall
(200% of the 100px containing block height).
When we calculate the effects of 'min-height',
the percentage
behaves as auto,
causing it to become 150px tall,
and the total ''height/min-content'' height of the containing block
to be 180px tall.
Since this is larger than 100px,
the
<article> gets clamped to 180px,
the percentage resolves against this new height,
and the
<aside> ends up being 360px tall,
overflowing the
<article>
Compressible Replaced Elements
In addition to the [=replaced elements=] listed
in HTML§14.4 [[!HTML]],
the following HTML elements are also considered to be [=replaced elements=]
for the purpose of the percentage-sized replaced element rule above,
and can have their min-content contribution compressed
when their 'width'/'height' or 'max-width'/'max-height'
is expressed with a cyclic percentage size:
* <{input}> with any <{input/type}> that is not "button-like";
this can vary depending on the UA.
A type is "button-like" in a particular UA if it displays similar to a <{button}> element,
where it can contains actual content that determines the layout of the element.
In most UAs, the "button", "reset", "submit", and "color" types are button-like;
the "file" type is also partially button-like in some UAs,
when it's displayed as a combination of a text input (shrinkable)
and a button (button-like, and thus not shrinkable).
* <{select}>, <{textarea}>, <{progress}>, <{meter}>, <{marquee}>.
Issue(6348): Tracking web-compat & implementation progress of applying this to max-width/height in Issue 6348.
Changes
Recent Changes
Changes since the 18 December 2020 Working Draft include:
- Fixed the order of 'contain-intrinsic' size values
when ''contain-intrinsic-size/auto'' is combined with other values
so that parsing is unambiguous.
(Issue 6391)
- Clarified which elements are allowed to not have a last remembered size for ''contain-intrinsic-size: auto''.
(Issue 6220)
- Limited ''contain-intrinsic-size: auto'' to when ''content-visibility' is ''content-visibility/auto''.
(Issue 6308)
Changes since the 18 December 2020 Working Draft include:
-
Fixed various errors in definition of max-content sizes of replaced elements
in [[#intrinsic-sizes]].
(Issue 6072)
-
Added missing statement handling [=min-content constraint=]
to definition of [=fit-content size=].
-
Renamed replaced element “intrinsic” dimensions to “natural” dimensions
in order to avoid confusion with [=intrinsic sizes=]
(see Issue 4961).
-
Various other minor editorial fixes and improvements.
Major changes since the 22 May 2019 Working Draft include:
-
Defined that ''width/min-content'' and ''width/max-content''
do not necessarily behave the same as the property’s initial value
if otherwise specified (by the relevant layout module).
(Issue 3973)
-
Switched intrinsic contribution of ''width/fit-content()''
to treat its argument as that argument would be treated alone
for intrinsic contribution calculations
and resolve the fit-content formula accordingly,
rather than having special behavior for ''width/fit-content()'' resolution
when calculating intrinsic contributions.
(Issue 3731)
-
Changed the [=max-content size=] of replaced boxes
without an intrinsic size
to use their [=minimum size=] in place of ICB or 300px×150px
only when it is a <>,
see [[#intrinsic-sizes]].
(Issue 4217)
-
Switched default sizing of an object with a natural aspect ratio
to use the ICB size instead of 300px×150px.
(Issue 4218)
-
Defined [=preferred aspect ratio=] and used it in place of “intrinsic aspect ratio” where appropriate.
-
Miscellaneous minor / editorial fixes.
Major changes since the 4 March 2018 Working Draft include:
- Imported the 'box-sizing' definition from CSS UI Level 3.
- More rigorously specified handling of cyclic percentages.
(#1132,
#2384,
#2297,
#2674)
- Changed the ''*-content'' values applied to the bock axis
to not compute to the property’s initial value,
but to rather “behave as” the property’s initial value.
(#2708)
- Fixed miscellaneous trivial errors.
Major changes since the 7 February 2017 Working Draft include:
- More accurate definition of min-content and max-content sizes for replaced elements.
- Compute new keywords to the initial value, not to a potentially non-existent ''width/auto'', when applied to the block axis.
- Specify that percent sizes on replaced elements zero out their min-content contribution.
- Fix confusing/wrong definition of percentage sizes resolved against a dependent containing block.
(This may require further work.)
- Deferred the ''width/stretch'' and ''width/fit-content'' keywords to Level 4
to allow for further consideration of their behavior in indefinite containing blocks.
- Pulled in full definitions for all of the sizing properties (rather than diffing them):
'width', 'height', 'min-width', 'min-height', max-width', 'max-height', and 'box-sizing'.
Additions since CSS Level 2
In addition to substantially more detail
to the various automatic and content-based sizing algorithms,
the following new features have been added since [[CSS2]]:
- The 'box-sizing' property (originally defined in [[CSS-UI-3]], then moved here).
- The ''width/min-content'', ''width/max-content'', and ''width/fit-content()'' values of the [=sizing properties=].
- The ''min-width/auto'' initial value of the 'min-width' and 'min-height' properties (originally defined in [[CSS-FLEXBOX-1]], then moved here).
Acknowledgments
Special thanks go to
L. David Baron,
Aaron Gustafson,
Daniel Holbert,
and
Mats Palmgren
for their contributions to this module.
Privacy and Security Considerations
In order to support automatic layout,
CSS sizes boxes to fit their contents.
In conjunction with various [[DOM]] and [[CSSOM]] APIs
which can return the size of those boxes to script,
this can expose information about those contents.
However, this information is more directly and easily available
by inspecting the DOM for the contents,
rather than indirecting through the box’s size.
Containers that can't have their contents inspected
(such as cross-origin <{iframe}>s)
also do not expose sizing information to the outer page,
except insofar as [=replaced elements=] such as images
expose their natural size and/or aspect ratio.
