> 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 explicitely 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(<>)
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.
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'' 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'' 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”.)
Note: Note that when the box has an intrinsic 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.
For replaced elements,
if the max-content size size would depend
on the size of the containing block
(as it does for images with an intrinsic aspect ratio but no intrinsic size,
see CSS2§10.3.2)
and therefore can't be calculated against an infinitely-sized containing block
then:
- For boxes with an intrinsic aspect ratio, but no intrinsic 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 definite non-zero 'min-width' or 'min-height',
use that size and calculate the other dimension using the aspect ratio;
if both dimensions have a definite 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 a width of ''300px''
(height of ''150px'' in vertical writing modes)
and calculate the other dimension using the aspect ratio.
- For boxes without an intrinsic aspect ratio:
-
* If the available space is definite
in the appropriate dimension,
use the stretch fit into that size in that dimension.
* Otherwise,
if the box has a definite non-zero minimum size ('min-width'/'min-height') in that dimension,
use that size.
* 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 runs 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.
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">
<aside style="height: 50%;">
</aside>
</article>
]]>
the
<aside> would be 30em tall.
For example,
an <{input}> assigned ''width: calc(50% + 50px)''
has a
min-content contribution of ''50px'',
plus any horizontal margin/border/padding.
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
The following elements can have their min-content size compressed
when their 'width'/'height' or 'max-width'/'max-height' is expressed with a percentage size.
See [[#intrinsic-contribution]].
* All replaced elements that aren't form controls.
See HTML§14.4. [[!HTML]]
* <{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}>.
Changes
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)
- 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'.
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
This specification introduces no new privacy or security considerations.
