css-box/Overview.src.html

<!doctype html public '-//W3C//DTD HTML 4.01//EN'>

<head profile="
http://microformats.org/profile/h-card
http://microformats.org/profile/hcard
http://microformats.org/profile/rel-license
">

<!-- Note: the h-card profile is for a "microformats 2" vocabulary and
is experimental as of September 2012 -->

<meta content="text/html; charset=utf-8" http-equiv=content-type>
<title>CSS basic box model</title>

<link href="../default.css" rel="stylesheet"
  title="Default" type="text/css">
<style type="text/css">
  ol.stack p {margin-top: 0}
  img.small {max-width: 100%}
  .minidiagram {height: 6em; vertical-align: middle}
  dt {display: inline}
  dt + dt::before {content: ", "}
  /* Undo the max-width in the 2012 style for editor's drafts: */
  body {max-width: none}

  /* maybe replace this with using default.css's class=data? */
  .equiv-table {margin: 0.5em 0; border-collapse: collapse;
    border-bottom: hidden; empty-cells: show}
  .equiv-table th, .equiv-table td {padding: 0.3em 1em;
    border-bottom: thin solid #666}
  .equiv-table th {text-align: left}
  /* .equiv-table th:first-child {text-align: right} */
  .equiv-table caption {margin: 0.5em 0 0 0}
  .equiv-table td > p:first-child, .equiv-table th > p:first-child {
    margin-top: 0}
  .equiv-table tr {vertical-align: baseline}
  .equiv-table img {max-width: 100%}

  /* The TR postprocessor already inserted quotes: */
  .css::before, .property::before, .descriptor::before {content: none}
  .css::after, .property::after, .descriptor::after {content: none}

  @media screen {
    #annoying-warning:not(:checked) + * + * {position: fixed; z-index: 1;
      bottom: 2em; left: 0; right: 0; text-align: center;
      padding: 0.5em 0.5em 1em 0.5em; box-shadow: 0 2px 8px black;
      border-top: thin solid; border-bottom: thin solid;
      background: hsla(40,100%,50%,0.9); color: black}
    #annoying-warning:not(:checked) + * + * p {margin: 0}
    #annoying-warning, #annoying-warning + * {position: fixed; z-index: 2}
    #annoying-warning {font-size: 1em; bottom: 2.3em; right: 0.5em; margin: 0}
    #annoying-warning + * {font-size: 80%; bottom: 2.5em; right: 2.3em}
    #annoying-warning:checked, #annoying-warning:checked + * {display: none}
    html {margin-bottom: 15em}
  }
</style>
<link href="https://www.w3.org/StyleSheets/TR/W3C-MO.css" rel="stylesheet"
  title="Default" type="text/css">

<link rel=contents href="#contents">
<link rel=index href="#index">


<!--
<pre class=metadata>
Title: CSS basic box model
Shortname: css-box
Level: 3
Status: ED
ED: http://dev.w3.org/csswg/css-box/
Abstract: <p><abbr title="Cascading Style Sheets">CSS</abbr> describes the
 rendering of documents on various media. When textual documents (e.g.,
 HTML) are laid out on visual media (e.g., screen or print), CSS models
 their layout as a collection of rectangular boxes containing words, lines,
 paragraphs, tables, etc., each with properties such as size, color and
 font.

 <p>This module describes the basic types of boxes: block, list item,
 inline, etc.; and some of their properties, including margins, padding
 and width/height. It defines a layout called a “flow,” in which a
 series of boxes is laid out one after the other, and it defines 
 “floating” boxes. Other kinds of layout, such as tables, absolute
 positioning, ruby annotations, grid layouts, columns and page boxes,
 are described by other modules. Also, the layout of text inside a line
 (including the handling of left-to-right and right-to-left scripts) is
 defined elsewhere.

 <p>In CSS level 3, boxes may contain either horizontal or vertical text. 
 Different orientations can be mixed.
Editor: Bert Bos, W3C, mailto:bert@w3.org
Editor: Anton Prowse, Invited Expert, mailto:prowse@moonhenge.net
</pre>
-->

<div class="head">
<!--logo-->

<h1>CSS basic box model</h1>

<h2 class="no-num no-toc">[LONGSTATUS] [DATE: 26 Sep 2006]</h2>
<dl>
  <dt>This version:

    <dd><a href="[VERSION]"
    >[VERSION]</a>

  <dt>Latest version:

    <dd><a href="http://www.w3.org/TR/css-box-3"
    >[LATEST]</a>

  <dt>Previous version:

    <dd><a href="http://www.w3.org/TR/2007/WD-css3-box-20070809/"
    >[PREVIOUS]</a>

  <dt>Feedback:</dt>

    <dd><a
    href="mailto:www-style@w3.org?subject=%5Bcss3-box%5D%20feedback"
    >www-style@w3.org</a> with subject line &ldquo;[css-box-3]
    <var>&hellip; message topic &hellip;</var>&rdquo; (<a
    rel="discussion"
    href="http://lists.w3.org/Archives/Public/www-style/"
    >archives</a>)

  <dt>Editors:

    <dd class="h-card vcard"><a class="p-name fn u-url url" rel=author
    href="http://www.w3.org/People/Bos/" >Bert Bos</a>, <span
    class="p-org org" >W3C</span>, <a class="u-email email"
    href="mailto:bert@w3.org" >&lt;bert@w3.org&gt;</a>

    <dd class="h-card vcard"><span class="p-name fn" >Anton
    Prowse</span>, <span class="p-org org" >Invited Expert</span>, <a
    class="u-email email" href="mailto:prowse@moonhenge.net"
    >&lt;prowse@moonhenge.net&gt;</a>
</dl>
<!--copyright-->
<hr title="Separator for header">
</div>


<h2 class="no-num no-toc">Abstract</h2>


<h2 class="no-toc no-num">Status of this document</h2>

<!--status-->

<p>The CSS Working Group plans to ask for W3C Recommendation status
for this specification only when there are sufficiently many
implementations. See the section <a href="#exit">“CR exit criteria”
</a> for details.</p>

<div>
 <input id=annoying-warning type=checkbox title="hide warning">
 <label for=annoying-warning>(hide)</label>
 <div>
  <p>This draft is undergoing changes and many parts are not
  consistent with other modules of CSS.

  <p>Please, refer to CSS level 2 [[!CSS21]] instead for the
  definition of the basic box model.
 </div>
</div>

<p>This module should eventually replace corresponding parts
of the revised CSS level 2 specification [[!CSS21]]. But this is an
early draft and any differences to level 2 are most likely
unintentional, unless they concern new features, such as vertical text
or float displacement. <em>Please help us improve the next draft by
pointing out such differences.</em>

<h2 class="no-num no-toc">Table of contents</h2>
<!--toc-->


<h2>How to read this specification</h2>

<p>All sections are normative, unless stated otherwise.

<div class=example>
<p>Examples look like this and normally start with the word
&ldquo;Example.&rdquo; Examples are not normative.
</div>

<p class=note>Notes look like this and normally start with the word
&ldquo;Note.&rdquo; Notes are not normative.

<p class=issue>Editorial notes look like this. They will be removed before
the document becomes Candidate Recommendation.

<p>Each property is defined in part in the text and in part by a table that
groups together a number of facts about the property, including a regular
expression to restrict its syntax. See <span class=issue>[where?]</span>
for the meaning. The &ldquo;Inherited&rdquo; and &ldquo;Initial&rdquo; rows
in the table are used by the Cascading and Inheritance module [[CSS3CASCADE]]
and &ldquo;Media&rdquo; by the Media Queries specification [[MEDIAQ]].

<p>The specification may refer to the <em>used value</em> and the
<em>computed value</em> of a property. Unless stated explicitly, the
short form “value” means the computed value.


<h2>Dependencies on other modules</h2>

<p>This CSS module depends on the following other CSS modules:

<ul>
  <li><cite>CSS Writing Modes Module</cite> [[!CSS3-WRITING-MODES]]
    &ndash; switch between vertical and horizontal text, properties
    <dfn>writing-mode</dfn> and <dfn>direction</dfn>, definitions of the
    terms <dfn>block flow direction</dfn> and <dfn>inline base
    direction.</dfn>
  <li><cite>CSS Syntax Module</cite> [[!CSS3SYN]] &ndash; syntax of
    properties and values
  <li><cite>CSS Values and Units Module</cite> [[!CSS3VAL]] &ndash;
    definitions of value types <dfn><var>&lt;number&gt;</var></dfn>,
    <dfn><var>&lt;percentage&gt;</var></dfn>,
    <dfn><var>&lt;angle&gt;</var></dfn> and
    <dfn><var>&lt;length&gt;</var></dfn>; defines the terms <dfn>computed
    value</dfn> and <dfn>used value.</dfn>
  <li><cite>CSS Text Module</cite> [[!CSS3TEXT]] &ndash; inline layout and
    definition of <dfn>line box.</dfn>
  <li><cite>CSS Generated and Replaced Content module</cite> [[!CSS3GENCON]]
    &ndash; defines the terms <dfn>replaced element</dfn>
    and <dfn>intrinsic</dfn> size (and intrinsic ratio).
  <li><cite>CSS Backgrounds and Borders Module</cite> [[!CSS3BG]] &ndash;
    defines <dfn><var>&lt;bg-position&gt;</var></dfn>
  <li><cite>CSS Basic User Interface Module</cite> [[!CSS3UI]] &ndash;
    defines <dfn>box-sizing</dfn>
  <li><cite>CSS 2D Transforms</cite> [[!CSS3-2D-TRANSFORMS]] &ndash;
    defines <dfn>transform</dfn>
  <li><cite>CSS Display Module</cite> [[!CSS-DISPLAY-3]] &ndash;
    defines <dfn>display</dfn>
</ul>


<h2>Introduction &amp; definitions</h2>

<p>Some issues that affect multiple sections in this document:

    <div class=issue>
      <p>Horizontal centering (more precisely: centering in the inline
	direction). The draft contains several suggestions:

      <ol>
	<li>Setting 'margin' to ''fill''. ''Fill'' is similar to
	  ''auto'', but allowed to be negative:

	  <pre>P {margin: 1em fill}</pre>

	<li>Setting a property 'alignment' on the element to center:

	  <pre>P {alignment: center}</pre>

	<li>Setting a property 'child-align' on the parent of the
	  element to center:

	  <pre>DIV {child-align: middle}</pre>

	<li>Rely on grid templates [[CSS3LAYOUT]]. You set a template
	  on the parent or on the element itself. One or the other may
	  be easier.  E.g., to horizontally center the single child of
	  a <span>horizontal</span> DIV):

	  <pre>DIV {grid: ". @ ." }</pre>

	  <p>To horizontally center a P with a template on the P
	    itself requires that the width of the P isn't set with the
	    'width' property, but with the 'grid-columns' property (or
	    the 'grid' shorthand). In the example below the width is
	    set to 'fit-content':

	  <pre>P {grid: * fit-content *  ".  @ ."}</pre>

	  <p>To vertically center the single child of a
	    <span>vertical</span> DIV:

	  <pre>DIV {grid: "@"}
DIV:slot(@) {vertical-align: middle}</pre>

	  <p>To vertically center a P inside a vertical parent by
	    means of a template on the P itself requires that the
	    height of the P isn't set with 'height', but with
	    'grid-rows' (or the 'grid' shorthand). Below, the height
	    is set to 10em:

	  <pre>P {grid: "." *
         "@" 10em
         "." * }</pre>

	  <p>See also <a href="/Style/CSS/Tracker/actions/18"
	    >ACTION-18</a> (especially <a
	    href="http://lists.w3.org/Archives/Public/www-style/2008May/0045.html"
	    >the ideas at end of Bert's comment</a> ), which is
	    continued in <a href="/Style/CSS/Tracker/issues/53"
	    >ISSUE-53.</a>
      </ol>
    </div>

    <div class=issue id=contain-floats>
      <p>Ensuring that the bottom padding (more precisely: the foot
	padding) starts after any preceding and descendant floats.

      <p>The main use case is to make sure an element is at least as
	high as all its floating descendants. I.e., at the end of the
	element, clear the floats that are descendants of the
	element. That may or may not also clear any floats that were
	declared before the element. Some possible approaches:

      <ol>
	<li>Set 'overflow' to anything else than 'visible' (and
	  'height' to 'auto'). This requires no new property, but has
	  the side effect of influencing the scrolling mechanism. It
	  also doesn't clear any floats that occurred before the
	  element and doesn't distinguish left, right or other
	  floats. [2004-02-29 ftf]

	<li>A new property 'clear-after'.

	<li>Use the value ''shrink-wrap'' (or some other name, e.g.,
	  ''contain'') on 'height' (and 'width', in case of vertical
	  text) to make an element into a <em>flow root.</em> This
	  requires no new property, only a new value, but doesn't
	  clear any floats before the element and doesn't distinguish
	  left, right or other floats. [The idea to add the
	  functionality to 'height' is due to IanH 2004-02-29]

	<li>The same, but only allow the new keyword on the
	  'min-height' and 'min-width' properties. [The idea to add
	  the functionality to 'min-height' is due to Fantasai,
	  2012-09]

	<li>A new value ''container'' on 'display'. This doesn't allow
	  a ''list-item'' to clear its floats.
      </ol>
    </div>

    <div class=issue>
      <p>Vertical centering and alignment (more precisely: in the
	block flow direction).

      <p>The use cases are centering a single child vertically in its
	parent, centering all content of an element vertically (e.g.,
	all text on a slide) and aligning only the last child (or the
	last <var>n</var> children) against the bottom of the parent.

      <p>Possible solutions include:

      <ol>
        <li>
	  <p>No new features, just use absolute positioning and
	    transformations together:
	  <pre>
.container {
   height: 10em; /* Some sufficient height */
   position: relative }
.container > * {
   margin: 0;
   position: absolute;
   top: 50%;
   transform: translate(0, -50%) }</pre>

	  <p>(The 'top' moves the top down by half the container's
	    height, the 'transform' moves the top up by half the
	    element's own height.) This only works if we are sure the
	    container is tall enough, because it will not
	    automatically grow. It only works if there is exactly one
	    child: it cannot center a sequence of paragraphs in a DIV,
	    nor the text content of a P.

	<li>
	  <p>No new features, just use flexbox: Set 'display: flex',
	    'flex-direction: column' and 'justify-content: center' on
	    the container. This has the side effect of changing both
	    the container and the children to block boxes, and
	    inhibiting margin collapsing between the children, so it
	    isn't suitable to, e.g. vertically center a set of list
	    items in a UL, or the text content of a P.

	<li>Extending 'vertical-align' to apply to block elements:

	  <pre>DIV {vertical-align: middle}</pre>

	  <p>This centers or aligns all content, it cannot top-align
	    the first child and bottom-align the last.

	<li>Allowing 'vertical-align' on a new type of box called
	  ''container''. (The main function of ''container'' is to
	  contain its floating descendants.) This wouldn't allow a
	  ''list-item'', a ''table-caption'' or an 'inline-block'' to
	  center its content.')

	<li>Setting 'margin' to ''fill'':

	  <pre>P {margin-top: fill}</pre>

	  <p>This works to center an element in its parent, but not to
	    center the content of an element with only text.

	<li>Relying on grid templates [[CSS3LAYOUT]]. If there are
	  enough elements, that could work:

	  <pre>
&lt;STYLE>
 BODY {grid: "a . b"} /* 3 columns */
 SECTION.a {flow: a; grid: "@" "." "z"} /* 3 rows */
 SECTION.b {flow: b; grid: "@" "." "z"} /* 3 rows */
 P.note {flow: z}
&lt;/STYLE>
&lt;SECTION CLASS=a>
 &lt;H1>...&lt;/H1>
 &lt;P>...
 &lt;P CLASS=note>...
&lt;/SECTION>
&lt;SECTION CLASS=b>
 &lt;H1 ID=b>...&lt;/H1>
 &lt;P>...
 &lt;P CLASS=note>...
&lt;/SECTION>
</pre>

	  <p>And assuming 'vertical-align' applies to slots, then that
	    also vertically centers the contents of an element. (This
	    centers horizontally if the element is
	    <span>vertical,</span> because 'vertical-align' is
	    relative to the writing mode.)

	  <pre>P {grid: "@"}
P:slot(@) {vertical-align: center}</pre>

	  <p>But it is not enough to bottom-align the two paragraphs
	    with class “note” in this example:

	  <pre>
&lt;STYLE>
 BODY {grid: "a . b"}
 H1#a, H1#a ~ P {flow: a}
 H1#b, H1#b ~ P {flow: b}
 P.note {/* align to bottom?? */}
&lt;/STYLE>
&lt;H1 ID=>...&lt;/H1>
&lt;P>...
&lt;P CLASS=note>...
&lt;H1 ID=b>...&lt;/H1>
&lt;P>...
&lt;P CLASS=note>...
</pre>

	<li>
	  <p>Use centering in the inline direction after switching the
	    parent to an orthogonal block flow direction. E.g., if the
	    document is <span>horizontal</span> and we want to
	    vertically center the single child of a DIV:

	  <pre>DIV {writing-mode: vertical-rl}
DIV > * {writing-mode: horizontal; width: 100%;
  margin-top: auto; margin-bottom: auto}</pre>

	  <p>This cannot top-align the first child and bottom-align
	    the second.

	<li>
	  <p>Vertically centering a single element could also be
	    modeled as a float with an offset. A draft of
	    [[CSS-PAGE-FLOATS]] from 2013 suggests the following to
	    center a P vertically inside its parent DIV:

	  <pre>DIV {height: 15em;
  colums: 1}            /* Make the DIV act like a "page" */
P {float: top left;     /* Place the P in the corner of the DIV... */
  float-offset: 0 50%}  /* ... and add 50% offset vertically */</pre>

	  <p>Floats like this also allow to put all children at the
	    top and the last child against the bottom. But only one
	    child: trying to push multiple children down to the bottom
	    results in their order being reversed.

      </ol>
    </div>


<p class=issue>Investigate if it is possible to make a pseudo-element
to select anonymous boxes ('::paragraph'). See minutes of 10 Aug 2011.

<p class=note>Note: The model in this specification differs from the
model described in the CSS level 2 specification [[!CSS21]], because
it is generalized to apply also to vertical text. A document using
only features from level 2 renders exactly as described there, (except
possibly for features that are undefined in that specification and
have become defined since).

<p>CSS assumes that the document to lay out is modeled as a <span
class=index title="tree!!of elements|document tree|element
tree">tree</span> of <dfn title="element">elements.</dfn> Each element
has an ordered list of zero or more child elements, with an optional
string of text before the list, in-between the children and after the
list. Each child has one parent, except for the unique element that
has no parent, which is called the <dfn>root element.</dfn>

<p class=note>Note that such a tree can be described in XML or SGML,
but also in other notations and that it is the definition of that
notation, not CSS, that determines the equivalence between the
abstract tree and the concrete notation. E.g., SGML often allows white
space to be added between elements for readability, which does not
result in a string of spaces in the abstract tree.

<p>CSS describes how each element and each string of text is laid out
by transforming the document tree into a set of rectangular boxes,
whose size, position, and stacking level on the <em>canvas</em> depend
on their properties. We say that an element <dfn title="generated
box">generates</dfn> one or more boxes. There are numerous different
types of boxes. <span class=issue>[Or maybe only one? I.e., a
block-level box is just a normal box that happens to be generated by a
block-level element?]</span> A block box is like a paragraph; a line
box is like a single line of text; and inline boxes are like words
inside a line.

<div class="issue">
<p>Define the <dfn title="box tree|tree!!of boxes" >box
tree.</dfn> (Is the space
between words a kind of box as well, or a spacer item? Is the current
selection a box? Is there a defined order among sibling boxes? If so,
are bidi inline boxes ordered in reading order or in visual order?)

<p>[Define the box tree before pagination and then describe how
pagination can break one box into two?]

<!--
<ul>
<li>If the parent element is a list item, the boxes go into the
parent's block box, not the marker box.

<li>If the element is run-in, its boxes go either into a box of its
parent element, or into a box of a later sibling.

<li>The order of sibling boxes is always such that boxes that belong
to elements earlier in the document come before boxes of elements that
come later in the document.

<li>Note that 'position' can put a box into the box of an ancestor
(the one establishing the containing block) rather than a parent.

<li>Note that 'flow' puts boxes into a named flow root.
</ul>
-->
</div>

<p>When the specification says a box <var>A</var> <dfn>contains</dfn>
a box <var>B</var> it means <var>B</var> is a child of <var>A</var> in
the <em>box tree.</em> Typically, box <var>B</var> is geometrically
contained within box <var>A</var> as well, but that need not be the
case, because of, e.g., overflow or negative margins.

<p class=note>Note: The precise rules are below and in other modules,
but in summary, <span class=issue>[write something that helps convey
the idea of a flow, e.g.:]</span> a block-level box contains either other
block-level boxes (e.g., a section containing paragraphs, or a table
containing rows), or it contains line boxes (e.g., a paragraph
containing lines of text). A line box contains inline-level boxes
(e.g., a line with words in different styles). An inline-level box may
contain either text interspersed with more inline-level boxes, or it
may contain a block-level box (e.g., a small table that is rendered
inline).

<div class=figure>
  <p><img src="box-intro.png" alt="Each generated box in the rendering
  has a link to the element that generated it.">

  <p class="caption">Relation between four displayed boxes in the
  rendered document (on the right) and the three corresponding
  elements in the source document on the (left).
</div>

<div class=example>
<p>For example, a fragment of HTML such as
<pre>&lt;ul&gt;
 &lt;li&gt;The first item in the list.
 &lt;li&gt;The second item.
&lt;/ul&gt;</pre>

<p>may result in <span class=issue>[rewrite the following
sentence?]</span> one block-level box for the <code>ul</code> element,
containing two block-level boxes for the two <code>li</code> elements,
each of which has one line box (i.e., one line of text). Both line
boxes contain two inline-level boxes: one that contains the list
bullet and one that contains the text.

<p>Note how the <code>li</code> is transformed into multiple boxes, including
one that contains &ldquo;generated content,&rdquo; viz., the list bullet,
which is not present in the source document.

<p>If the document is rendered in a narrow window, it may be that the
<code>li</code> elements get transformed into even more boxes, because the
text requires multiple lines. And if the document is rendered on paper
or in multiple columns, it
may be that a page break falls in the middle of the <code>ul</code> element,
so that it is not transformed into a single block-level box, but into two
smaller ones, each on a different page or column.
</div>

<p>Each box belongs to exactly one element. It is either <span
title="generated box">generated</span> directly by the element, or it
is an <em>anonymous box,</em> which has been inserted to ensure that
every box and its parent are of mutually compatible types as defined
by the layout rules of CSS. An anonymous box is defined to belong to
whichever element generates the box's closest element-generated
ancestor box. When we need to be precise, we say that the anonymous
box is <dfn>induced,</dfn> rather than generated, by the element it
belongs to.

<p class=note>For example, an anonymous table wrapper box that is
created around a table cell because the table cell element doesn't
have a table element as parent, belongs to the parent element of the
table cell, not to the table cell itself.

<p class=note>An anonymous box is never a <em>principal</em>
box. Except for that, an anonymous box cannot be distinguished by its
property values and characteristics from a box generated by some
hypothetical document element. <span class=issue>Remove this note? Do
we actually use the concept of “principal box” anywhere?</span>

<p>Properties are set on elements [[!CSS3CASCADE]] and influence how
the element is turned into boxes. Every box has the same properties
with the same values as the element to which it belongs, except for
anonymous boxes: inheritable properties on anonymous boxes have the
same value as the element, while non-inheritable properties have the
initial value. The only property that boxes do not have is the
'display' property. <span class=issue>[Is this useful? Or is it better
to say that boxes are just rectangles with a border, a background, a
position, a bunch of other boxes inside, and a reference to the
element they belong to? They don't really have properties then and it
is only a convenience to say the “the box has a font
<var>X.</var>”</span>

<p>Boxes do not have specified values [[!CSS3CASCADE]], but they do
have computed, used and actual values.

<p class=note>Boxes are frequently referred to by their property
values. For example, a “floated box” is a box whose computed value of
'float' is not ''none'', and a “positioned box” is a box whose
computed value of 'position' is not ''static''. However, terms such as
<em>block-level box,</em> <em>block container box</em> and <em>table
box</em> describe characteristics which cannot be deduced solely from
a box's property values.

<div class=figure id=various>
  <p><img src="box.png" alt="Diagram of a typical box, showing the
  content, padding, border and margin areas">

  <p class="caption">The various areas and edges of a typical box
</div>

<p>Boxes have padding, a border and margins (see the <a
href="#various">figure</a>). Different properties determine the
thickness of each of these (which may be zero). The margins of
adjacent boxes are also subject to <em
title="collapse">collapsing</em> (i.e., the actual margin between
adjacent boxes may be less than the sum of the boxes' individual
margins).

<p>Each box has a <dfn>content area</dfn> (a.k.a. <dfn>content
box</dfn>). The rectangle that bounds this area is the <dfn>content
edge.</dfn> Around the content area is the <dfn>padding area</dfn> and
its outside bounds are called the <dfn>padding edge.</dfn> The padding
area and content area together form the <dfn>padding box.</dfn>
Outside the padding is the <dfn>border area</dfn> and the outside
boundary of that area is the <dfn>border edge.</dfn> The border area,
padding area and content area together form the <dfn>border box.</dfn>
Finally, outside the border is the <dfn>margin area</dfn> and its
outer edge is the <dfn>margin edge.</dfn>

<p>When the specification says that the padding or border is <dfn
title="absent|padding!!absent|border!!absent"
>&ldquo;absent&rdquo;</dfn> on some side of the box, that means that
its thickness is zero.

<p><em title="line box">Line boxes</em> cannot have any padding,
border or margin, and therefore their margin edge, border edge,
padding edge and content edge all coincide.

<p class=note>Note that the margin, unlike the border and padding, may have
a negative thickness. That is one way to make adjacent boxes overlap each
other.

<p class=note>Note that the edges always form rectangles, even if
there is a 'border-radius' [[CSS3BG]] or a shape [[CSS3-EXCLUSIONS]].

<p>We say that a box or element is <dfn>horizontal</dfn> if its
'writing-mode' property is ''horizontal-tb'', otherwise it is
<dfn>vertical.</dfn>

<div class=note>
<p>Note that there are theoretically eight possible orientations for
text, but CSS only defines six:

      <table class=equiv-table style="table-layout: fixed; width: 100%">
	<thead>
	  <tr>
	    <th style="width: 8em">
	    <th>'writing-mode: horizontal-tb'
	    <th>'writing-mode: vertical-rl'
	    <th>'writing-mode: vertical-lr'
	<tbody>
	  <tr>
	    <th>'direction: ltr'
	    <td>
	      <p>Text is written from left to right and paragraphs
		grow downwards <p><img class=small
		src="horizontal.png" alt="">
	    <td>
	      <p>Text is written top to bottom and paragraphs grow to
		the left <p><img class=small src="vertical.png"
		alt="">
	    <td>
	      <p>Text is written top to bottom and paragraphs grow to
		the right <p><img class=small src="vertical-lr.png"
		alt="">
	  <tr>
	    <th>'direction: rtl'
	    <td>
	      <p>Text is written from right to left and paragraphs
		grow downwards <p><img class=small
		src="horizontal-rtl.png" alt="">
	    <td>
	      <p>Text is written bottom to top and paragraphs grow to
		the left <p><img class=small src="vertical-rtl.png"
		alt="">
	    <td>
	      <p>Text is written bottom to top and paragraphs grow to
		the right <p><img class=small
		src="vertical-lr-rtl.png" alt="">
      </table>

<p>There is no “horizontal-bt.” More information about 'writing-mode'
and 'direction' can be found in [[!CSS3-WRITING-MODES]].
</div>

<p class=mtb>Calculations of the size and position of boxes are
usually very similar for horizontal and vertical boxes, except that
the horizontal and vertical directions are interchanged. To avoid many
almost identical definitions, this specification therefore often uses
abstract terms instead of top, right, bottom, left, width and height:
four terms (block-start, block-end, inline-start and inline-end) for
the four edges of a box, four terms (A edge, B edge, C edge and D
edge) for the edges of the children of a box and two terms (measure
and extent) for the width and height of a box.

<p class=note>XSL-FO [[XSL11]] uses “inline-progression dimension” for
“measure” and “block-progression dimension” for “extent.”

<p>The <dfn>block-start,</dfn> <dfn>block-end,</dfn>
<dfn>inline-start</dfn> and <dfn>inline-end</dfn> edge of a box refer
to the top, right, bottom and left edges, depending on the
'writing-mode' and 'direction' properties of that box, as follows:

    <table class=equiv-table>
      <thead>
	<tr>
	  <th>'writing-mode'
	  <th>'direction'
	  <th>“block-start”
	  <th>“inline-end”
	  <th>“block-end”
	  <th>“inline-start”
	  <th>Diagram
      <tbody>
	<tr><th rowspan=2>''horizontal-tb'' <th>''ltr'' <td>top
	  <td>right <td>bottom <td>left <td><img class=minidiagram
	  src="box-tb-ltr.svg" alt="">

	<tr><!--horizontal-tb--> <th>''rtl'' <td>top <td>left
	  <td>bottom <td>right <td><img class=minidiagram
	  src="box-tb-rtl.svg" alt="">

	<tr><th rowspan=2>''vertical-rl'' <th>''ltr'' <td>right
	  <td>bottom <td>left <td>top <td><img class=minidiagram
	  src="box-rl-ltr.svg" alt="">

	<tr><!--vertical-rl--> <th>''rtl'' <td>right <td>top
	  <td>left <td>bottom <td><img class=minidiagram
	  src="box-rl-rtl.svg" alt="">

	<tr><th rowspan=2>''vertical-lr'' <th>''ltr'' <td>left
	  <td>bottom <td>right <td>top <td><img class=minidiagram
	  src="box-lr-ltr.svg" alt="">

	<tr><!--vertical-lr--> <th>''rtl'' <td>left <td>top <td>right
          <td>bottom <td><img class=minidiagram src="box-lr-rtl.svg"
          alt="">
    </table>

<p class=note>For example, the “block-start padding” by default refers
to the 'padding-top' and the “inline-end border” is by default the
'border-right'.

<p>Similarly, the specification sometimes refers to the
<dfn>measure</dfn> and <dfn>extent</dfn> of a box, instead of width
and height, as follows:

  <table class=equiv-table>
   <tr>
    <th>'Writing-mode'
    <th>“measure”
    <th>“extent”
   <tr><td>''horizontal-tb'' <td>width <td>height
   <tr><td>''vertical-rl'' <td>height <td>width
   <tr><td>''vertical-lr'' <td>height <td>width
  </table>

<p>These correspond to the dimensions in the <em>inline base
direction</em> and the <em>block flow direction,</em> respectively.

<p>An alternative term for the measure is <dfn title="logical
width|width!!logical" >logical width</dfn> and an alternative term for
extent is <dfn title="logical height|height!!logical"
>logical height.</dfn> These terms occasionally occur in other CSS
modules.

<p class=note>The extent of a box is thus the distance between the
block-start and block-end edges, while the measure of the box is the
distance between the inline-start and inline-end edges.

<p>When boxes are laid out to form a <em class=index
>flow</em> (see below), their edges play different roles in the
alignment of the boxes within that flow. The orientation of the flow
determines which edge of a box is aligned to which edge of another
box. These roles are independent of the orientation of the box
itself. We distinguish four roles for the edges of a box, called
<dfn>A edge,</dfn> <dfn>B edge,</dfn> <dfn>C edge</dfn> and <dfn>D
edge.</dfn> They depend on the 'writing-mode' and 'direction'
properties of the box's <em class=index >containing block</em>
(defined below), and map to the four sides as follows:

    <table class=equiv-table>
      <thead>
	<tr>
	  <th>'writing-mode' of<br><em>containing block</em>
	  <th>'direction' of<br><em>containing block</em>
	  <th>“A edge”
	  <th>“B edge”
	  <th>“C edge”
	  <th>“D edge”
      <tbody>
	<tr><th rowspan=2>''horizontal-tb'' <th>''ltr''
	    <td>top <td>right <td>bottom <td>left
	<tr><!-- horizontal-tb --><th>''rtl''
	    <td>top <td>left <td>bottom <td>right
	<tr><th rowspan=2>''vertical-rl'' <th>''ltr''
	    <td>right <td>bottom <td>left <td>top
	<tr><!-- vertical-rl --><th>''rtl''
	    <td>right <td>top <td>left <td>bottom
	<tr><th rowspan=2>''vertical-lr'' <th>''rtl''
	    <td>left <td>bottom <td>right <td>top
	<tr><!-- vertical-lr --><th>''ltr''
	    <td>left <td>top <td>right <td>bottom
    </table>

<p class=note>For example, block-level boxes in a flow are laid out
such that the A edge of the first box is against the block-start edge
of the containing block and then the A edge of each subsequent box is
put against the C edge of its predecessor. For typical English text
(i.e., <em>horizontal</em> text), this means the top edge (= A edge)
of the first paragraph is at the top edge (= block-start) of the
document, the top (A edge) of the second paragraph is against the
bottom (C edge) of the first paragraph, and so on, until the bottom (C
edge) of the last paragraph becomes the bottom (block-end) of the
document.

<p>An element is called <dfn>orthogonal</dfn> if it is either a
<em>vertical</em> element with a <em>horizontal</em> <em>containing
block</em> or a <em>horizontal</em> element with a <em>vertical</em>
<em>containing block.</em> An <dfn>orthogonal flow</dfn> is a
<em>flow</em> whose <em>flow root</em> is an orthogonal element.


<h2>The viewport and the canvas</h2>

<p>User agents for continuous media generally offer users a
<dfn>viewport</dfn> (a window or other viewing area on the screen)
through which users consult a document. User agents may change the
document's layout when the viewport is resized (see the <em>initial
containing block</em>).

<p>When the viewport is smaller than the area of the <em>canvas</em>
(see below) on which the document is rendered, the user agent usually
offer a scrolling mechanism. There is at most one viewport per canvas,
but user agents may render to more than one canvas (i.e., provide
different views of the same document).

<p>For all media, the term <dfn>canvas</dfn> describes the space where
the formatting structure is rendered. The canvas is infinite for each
dimension of the space.


<h2 id=flows>Flows</h2>

<p>The <dfn>flow</dfn> (sometimes called <dfn>normal flow</dfn>) is
one of the two basic kinds of layout in CSS, together with line layout
[[CSS3LINE]]. It can be used, e.g., to layout a sequence of
paragraphs, headings, lists and floated elements in a single
column. Other CSS modules, such as tables [[CSS3TBL]], positioning
[[CSS3POS]], flex boxes [[CSS3-FLEXBOX]] and grid templates
[[CSS3LAYOUT]], build on the flow model by defining ways to split a
document into more than one flow and positioning and aligning those
flows in various ways on the canvas.

<p>A flow is constructed starting from a <span class=index title="flow
root!!box" >box</span> called the <dfn>flow root</dfn> by the <a
href="#construct-flow">rules below.</a> We say the flow is
<dfn>channeled</dfn> by the flow root.

<p class=issue>Are there more intuitive names than flow root?

<p>The <dfn title="initial flow|flow!!initial" >initial flow</dfn> is
the flow that contains the root of the box tree.

<p>Despite not being a box, the <em>initial containing block</em> is
said to be the flow root of the initial flow.

<p class=issue id=pagination-issue>How do we model pagination? If a
flow is broken over two pages or columns, do we call it a single flow
or two flows? I.e., is the page box the flow root of the flow, or is
the page box something else, more like the viewport, which influences
the layout of a flow but isn't part of it? See [[CSS3-BREAK]].

<p>Only <em title="block container box" >block container boxes</em>
(defined below) can be flow roots. (Which implies that the children of
a flow root are laid out in a <em>block formatting context.</em>)

<p>Several (combinations of) properties cause an element to generate
boxes that are flow roots. This module defines a few. Other modules
may define more.

<div class=note>
<p>For example, this module defines that any of the following make a
box into a flow root:
<ul>
  <li>The value of 'float' is not 'none'.

  <li>The used value of 'overflow' is not 'visible'.

  <!-- <li>The box is a table wrapper, a table cell, an inline block, or an
  align box. -->

  <!-- <li>The value of 'position' is 'absolute' or 'fixed' (see
  [CSS3POS]). -->

  <li>The box is <span>vertical</span> and its parent is
  <span>horizontal.</span> <span class=issue>[Add link to the relevant
  section.]</span>

  <li>The box is <span>horizontal</span> and its parent is
  <span>vertical.</span>

  <!-- <li>The value of 'transform' is not 'none'. -->

  <li>The value of 'child-align' is not 'auto'. <span class=issue>[If
  'child-align' is adopted, rather than, say, 'margin: fill']</span>
</ul>

<p>Other examples: The table layout module [[CSS3TBL]] defines that a
table cell generates a box that is a flow root; the positioning module
[[CSS3POS]] defines that an absolutely positioned element generates a
flow root; the grid template module [[CSS3LAYOUT]] defines that a
template element generate several flow roots; and the transforms
module [[CSS3-TRANSFORMS]] defines that an element with a transform
generates a flow root.
</div>

<p class=mtb id=construct-flow>The flow of a given <em>flow root</em>
is a set of boxes. A box belongs to the flow if all of the following
are true:
<ol>
  <li>The used value of 'display' is ''block'', ''list-item'',
  ''table'' or ''flex''.

  <li>The used value of 'float' is ''none''.

  <li>The used value of 'position' is ''static'' or ''relative''.

  <li>It is either a child of the flow root or a child of a box that
  belongs to the flow.
</ol>

<p class=note>Note that the flow root is itself not part of the flow
it channels and that each flow root channels at most one flow.

<p class=note>Note that the last rule above implies that a flow with
its flow root together are always a connected subset of the box
tree. In other words; together, they form a subtree of the box tree
with possibly some branches removed.

<p class=note>Note that the element tree and the box tree are not
necessarily parallel: the element a box belongs to need not be the
child of the element that generated the box's parent. E.g., run-in
elements may generate boxes that become children of boxes from sibling
elements; and the 'flow' property [[CSS3LAYOUT]] and the 'position'
property [[CSS3POS]] may cause an element to generate a box that
becomes the child of a box from a grandparent or other ancestor
element. E.g., 'DIV {flow: b}' (see [[CSS3LAYOUT]]) makes the DIV
generate boxes that become children of the box generated by slot b in
some ancestor. And 'DIV {position: absolute}' causes the DIV to
generate a box that becomes a child of the box generated by the
ancestor that established the DIV's <em>containing block.</em>

<div class=example>
<p>For example, the fragment
<pre>&lt;div class=sidebar&gt;
 &lt;p&gt;Text in a sidebar.
 &lt;p&gt;Here is quote:
 &lt;blockquote lang=ja&gt;
  &lt;p&gt;...
 &lt;/blockquote&gt;
 &lt;p&gt;Etc. etc.
&lt;/div&gt; </pre>

<p>with the style
<pre>div.sidebar { writing-mode: tb; float: left }
blockquote[lang|=ja] { writing-mode: rl; height: 10em }</pre>

<p>defines two flows:
<ol>
  <li>The <code>div</code> is a flow root, because it floats. Its flow
  consist of the 1st, 2nd and 4th <code>p</code> and the
  <code>blockquote</code>.

  <li>The <code>blockquote</code> is a <em>vertical</em> box inside a
  <em>horizontal</em> parent and it is thus a flow root. Its flow is
  formed by the 3rd <code>p</code>.
</ol>
<p>(The <code>div</code> itself belongs to a third flow, but its flow
root is not shown in the fragment.)
</div>

<p class=note>Note that a flow root is not necessarily block-level, it may
be an ''inline-block'', e.g.

<p class=note>Note that a box belongs to at most one flow. (Some boxes
do not belong to any flow, because they are part of a different kind of
layout, such as table layout.)

<p>An element that generates a flow root box is itself also called a
<span class=index title="flow root!!element">flow root.</span>

<p class=note>Note: The terminology in the CSS level 2 specification
is different. A flow root is called “an element that establishes a
<span class=index title="formatting context|new formatting
context">new formatting context.</span>”

<p class=note>A consequence of this terminology is that an
<em>element,</em> unlike a box, can be the flow root of several
flows. E.g., template elements [[CSS3LAYOUT]] generate several flow
root boxes. Depending on what properties are set on a list item and on
its marker pseudo-element, a list item can also generate zero, one or
two flow roots.

<!--
<p class=mtb>The following rules define the position of
<em>block-level</em> boxes relative to the box that is their <em>flow
root.</em> Other sections and other modules describe how other boxes
are laid out. E.g., floating boxes are described further down in this
module and absolutely positioned boxes are described in the Absolute
Positioning module [[CSS3POS]].

<p>Before applying these rules, the width, height and margins of each
box must be computed as described in the sections <a
href="#Calculating">“Calculating widths, heights and margins”</a>
and <a href="#Collapsing">“Collapsing margins.”</a>

<ul>
  <li>
    <p>Consider the first box (in document order) of a set of sibling
    boxes that all belong to the same flow. There are four cases:
    <ol>
      <li>
        <p>If none of its margins <span>collapse</span> with its
        parent's <span>block-start</span> margin and the box is not
        <span>collapsed through,</span> then the box is placed such
        that the box's margin <span>A edge</span> coincides with the
        parent's <span>block-start</span> <span>content edge</span>, the
        margin <span>D edge</span> touches the parent's
        <span>inline-start</span> <span>content edge</span> and the margin
        <span>B edge</span> touches the parent's <span>inline-end</span>
        <span>content edge.</span>

	<div class=figure>
	  <p><img src="flow1.png" alt="For example:">

	  <p class=caption>In a <em>horizontal</em> <em>containing
	  block,</em> the top edge (<em>block-start</em> edge) is used to
	  position the top edge (<em>A edge</em>) of the first
	  block-level box. Its left and right edges coincide with the
	  left and right edges of the block-level box.
	</div>

      <li>
        <p>If none of its margins <span>collapse</span> with its
        parent's <span>block-start</span> margin but the box
        is <span>collapsed through,</span> then its <span>content
        edge</span> (which is also its <span>border edge</span>
        and <span>padding edge</span>) is defined as what it would
        have been if the box had a non-zero <span>footside</span>
        border. (I.e., recompute the margins given that border and
        then apply the previous rule.)

        <p class=note>Note that the box is effectively invisible, but
        the edges have to be defined to position any descendants, such
        as floating or absolutely positioned children.

      <li>
        <p>If its <span title="A edge">A</span> margin collapses with
        its parent's <span>block-start</span> margin, then the box is placed
        such that the <span>A edge</span> of the box's border touches
        the parent's <span>block-start</span> <span>content edge,</span> the
        <span>D edge</span> of the box's margin touches the parent's
        <span>inline-start</span> <span>content edge</span> and the <span>B
        edge</span> of the box's margin touches the parent's
        <span>inline-end</span> <span>content edge.</span>

        <p class=issue>[Add illustration.]

      <li>
        <p>If two of its margins collapse with its parent's
        <span>block-start</span> margin, then its position is such that its
        <span>content edge</span> (which is also its <span>border
        edge</span>) touches its parent's <span>block-start</span>
        <span>border edge</span> and that the <span>D edge</span> of
        its margin touches its parent's <span>inline-start</span>
        <span>content edge</span> and the <span>B edge</span> of its
        margin touches the parent's <span>inline-end</span> <span>content
        edge.</span>

        <p class=note>Note that the box is effectively invisible, but
        the edges have to be defined to position any descendants.
    </ol>

  <li>
    <p>For a box that has a preceding sibling in the same flow there
    are two cases:
    <ol>
      <li>
        <p>If the box is not <span>collapsed through,</span> it is
        positioned such that the <span>D edge</span> of its margin
        touches the parent's <span>inline-start</span> <span>content
        edge,</span> the <span>B edge</span> of its margin touches the
        parent's <span>inline-end</span> <span>content edge</span> and the
        <span>A edge</span> of its border box is at a distance from
        the <span>C edge</span> of the preceding sibling's border box
        equal to the combined thickness of the margins that collapse
        at that edge.

    <li>
      <p>A box that has a preceding sibling in the same flow and that
      is <span>collapsed
      through,</span> <span class=issue>[...]</span>
  </ol>
</ul>
-->


<h2>Types of boxes</h2>

<p>The layout of boxes in the flow is in large part determined by the
interplay of the 'display' properties of an element and its parent,
and then fine-tuned with margins and padding.

<p class=issue>The value ''compact'' is missing in [[!CSS-DISPLAY-3]].

<h3>Block-level boxes, containing blocks, flows and anonymous
boxes</h3>

<p class=issue>Split this section. Put the definition of containing
block in its own section and move it to right after the <a
href="#flows" >Flows</a> section above.

<p>A <dfn>block-level</dfn> box is a box that has a <span>computed
value</span> for 'display' of ''block'', ''container'', ''list-item'',
''table'', ''table-*'' (i.e., all table boxes, see [[CSS3TBL]]),
''run-in'' (under
certain circumstances, see <a href="#run-in-boxes">“Run-in boxes”
</a>), or ''compact'' (under certain circumstances, see <a
href="#compact-boxes">“Compact boxes”</a>).

<p>An <dfn>inline-level</dfn> box is a box that has a <span>computed
value</span> for 'display' of ''inline'', ''inline-block'',
''inline-table'', ''ruby'', ''run-in'' (under certain circumstances),
or ''compact'' (under certain circumstances).

<p class=issue>[What about the other ruby values?]

<p>An <dfn>anonymous box,</dfn> informally, is a box that cannot be addressed
with CSS selectors. All its properties, except for 'display', have their
default values (either the initial value or inherited). Anonymous boxes are
created when the CSS box model requires a child box with a certain value for
'display', but the child actually has a different value. In that case an
anonymous box of the right kind is created and wraps the child (or children).
Other modules (e.g., [[CSS3TBL]], [[!CSS3TEXT]]) may also define anonymous
boxes. The anonymous boxes defined by this module are the following:
<ul>
  <!--
  <li>An ''inline-table'' element creates one box with ''inline-table'' as
    the value for 'display', which contains one anonymous box with ''table''
    as the value.
  <li>An ''inline-block'' element creates one box with ''inline-block'' as
    the value for 'display', containing one anonymous box with ''block'' as
    the value.
  <li>A <span>block-level</span> element that has a
    'writing-mode' of ''lr'' or
    ''rl'' and a parent with a 'writing-mode' of ''tb'' (or vice-versa)
    generates one or more block-level boxes with the same 'writing-mode'
    as the parent, each of which has one anonymous child box with a 'display'
    of ''block'' and the 'writing-mode' of the element itself. <span
    class=issue>[Coordinate this with CSS3-WRITING-MODES]</span>
  -->
  <li>A <span>block-level box</span> may contain either <span
    title="line box">line boxes</span> or <span>block-level</span>
    boxes, but not both. If
    necessary, any line boxes that belong to this box's element are wrapped
    in one or more (as few as possible) anonymous boxes with a 'display' of
    ''block''.
</ul>


<p class=note>Note that the anonymous boxes defined in this module are
all <span>block-level,</span> but anonymous boxes defined in other
modules may be different.

<p class=mtb>The <dfn>containing block</dfn> of a box is a rectangle that
is associated with the box and that is used in various definitions in this
specification. Apart from a size and a position, the rectangle also has
'direction' and 'writing-mode' properties. The containing block of a box
is defined as follows:
<ul>
  <li>The containing block of the <span title="root element">root
    element's</span> top-level boxes is a rectangle with the dimensions of
    the <em>viewport,</em> anchored at the <em title="canvas">canvas's</em>
    origin for continuous media and the page area for paged media. (See
    [[MEDIAQ]] and [[CSS3PAGE]] for definitions of continuous and paged
    media.) This containing block is called the <dfn>initial containing
    block.</dfn> The 'direction' and 'writing-mode' of the initial
    containing block are the same as those of the root element.

  <li>For other elements, the containing block is one of the
    following:
	    <ol>
	      <li>If the element is a ''run-in'' that is rendered
	      inline in a sibling element, then its containing block
	      is the <span>content edge</span> of the <span>principal
	      box</span> of that sibling.

	      <li>Otherwise, if the parent has a <span>principal
	      box</span> that is a <span>block container box</span>
	      (e.g., if the parent is a 'table-cell' or a 'block'),
	      then the containing block is the content edge of the
	      parent's <span>principal box.</span>

	      <li>Otherwise the containing block is the same as that
	      of the parent.
	    </ol>
</ul>


<p class=issue>Other modules may introduce other types of boxes with
other rules for how to find their containing block. E.g., the
containing block of an absolutely positioned element.

<p>In the above, a <dfn>block container box</dfn> is, informally, a
box that can contain block boxes. More precisely: any box generated by
a (pseudo-)element with a computed value for 'display' of ''block'',
''inline-block'', ''table-caption'', ''table-cell'' or ''list-item''.
<span class=note>Note that most floating and absolutely
positioned elements have a computed 'display' of ''block''. Also, a
<em>flow root</em> has a computed 'display' of ''block''.</span>
<span class=issue>Or insert the definition of block container box from
CSS 2.1 here?</span>

<p class=issue>Also define <dfn>principal box</dfn> somewhere.

<p class=note>Note that the above is modified by the Absolute Positioning
module [[CSS3POS]]: in particular, if a box's 'position' property is neither
''static'' nor ''relative'', its containing block is established
differently.

<p>If an element <span class=issue>[or a viewport?]</span> has
scrollbars (see 'overflow'), then any space taken up by the scrollbars
should be excluded from (subtracted from the dimensions of) any
containing block formed by that element.


<!--
<h3 id=compact-boxes>Compact boxes</h3>

<p class=issue>Define here or in extended box module?

<p>A compact box is a box that is either put in the margin of the next
box or becomes a block of its own, depending on whether it is small
enough to fit in the margin or not. The typical use case is for lists
where most labels are small enough to fit in the margin, except for a
few.

<div class=example>
<p>An example is the DL list in HTML. Its COMPACT attribute indicates
to the formatter that the labels of the list are good candidates for
display as compact boxes:

<pre>
&lt;h3>Farm animals&lt;/h3>
&lt;dl compact>
 &lt;dt>cat
 &lt;dd>Lorem ipsum dolor sit amet, consectetaur adipisicing elit&hellip;
 &lt;dt>dog
 &lt;dd>Ut enim ad minim veniam, quis nostrud exercitation&hellip;
 &lt;dt>hippopotamus
 &lt;dd>Duis aute irure dolor in reprehenderit in voluptate velit&hellip;
 &lt;dt>fly
 &lt;dd>Excepteur sint occaecat cupidatat non proident, sunt in&hellip;
&lt;/dl>
</pre>

<p>With a style rule like

<pre>dl[compact] dt {display: compact}</pre>

<p>this might be rendered as in the figure below.

<div class=figure>
  <p><img src="compact" alt="[sample rendering]" style="max-width: 24em">
  <p class=caption>Three of the four labels are narrow enough to fit
  in the left margin. The one that is too wide is converted into a
  block.
</div>
</div>

<p>Whether a compact box <var>C</var> is displayed as a block or in
the margin is determined as follows. Let <var>N</var> be the next
sibling element in document order in the same flow as <var>C</var>, if
any. Let <var>W</var> be the hypothetical distance between the
<em>inline-start</em> margin edge and <em>inline-end</em> margin edge of
<var>C</var> if the 'display' property of <var>C</var> were set to
''block'' and any ''auto'' on its <em>measure</em> were
replaced by ''fit-content''.

<ul>
<li>If there is no such <var>N</var>, then <var>C</var> is displayed
as a block.

<li>If <var>N</var> has a 'display' of ''list-item'', then
<var>C</var> is displayed as a block.

<li>If <var>N</var> is not <em>block-level</em>, then <var>C</var> is
displayed as a block.

<li>If the <em>inline-start</em> margin of <var>N</var> is less than
<var>W</var>, then <var>C</var> is displayed as a block.

<li>Otherwise, <var>C</var> is displayed in the margin.
</ul>

<p>If <var>C</var> is displayed as a block, it is a
<em>block-level</em> element and it is sized and positioned exactly as
if its 'display' had been ''block''.

<p>Otherwise, <var>C</var> is placed such that its <em>inline-start</em>
margin edge aligns with the <em>inline-start</em> margin edge of its
<em>containing block</em> and its <em>headside</em> border edge aligns
with the <em>headside</em> border edge of <var>N</var>. It is in this
case an <em>inline-level</em> element.

<p class=issue>Do we do anything to avoid that floats overlap with
<var>C</var>? Do we do anything if <var>C</var> is taller than
<var>N</var>? E.g., adjust the 'min-height' of <var>N</var>?

<div class=example>
<p>Simple example...
</div>

<div class=example>
<p>This example shows a compact box that has a different <em>writing
mode</em> than its containing block:

<pre>
dl {writing-mode: tb; direction: ltr}
dd {margin-left: 3em}
dt {display: compact; writing-mode: rl}
...
&lt;dl>
 &lt;dt>cat
 &lt;dd>Lorem ipsum dolor sit amet, consectetaur adipisicing elit&hellip;
&lt;/dl>
</pre>

<p>The margin that is considered is the left margin of the DD, because
the containing block (established by the DL) is
top-to-bottom/left-to-right. That margin is thus compared to the width
of the DT and it is large enough, which leads to a rendering similar
to the figure below.

<div class=figure>
  <p><img src="compact-vert" alt="[Sample rendering]" style="max-width: 24em">

  <p class=caption>The word &ldquo;cat&rdquo; written sideways fits to
  the left of the definition.
</div>
</div>
-->


<h3>Mixing the box model with other formatting models</h3>

<p>There may be documents that combine different layout models, such
as documents that combine HTML (typically rendered with the CSS box
model) and <span class=index>SVG</span> (rendered with its own
graphics model). If an element that is rendered according to the CSS
box model has a child that is to be rendered with a different model,
that child needs to have a 'display' property with a value that
indicates that the child is not in the box model.

<p>Such a child is treated as a <em>replaced element</em> for the
purposes of determining its size, position, margins, padding and
border.

<p class=issue>Should we allow a more complex model, where such a
child may negotiate with the CSS environment to have several boxes and
several baselines, so that it can take part in line breaking and page
breaking?

<p>This specification defines no value(s) for the 'display' property
that indicate that an element is formatted according to a different
model than the box model, but separate specifications may do so.


<h2>The padding properties</h2>

<table class="propdef">
  <tr><th>Name: <td><dfn>padding</dfn>
  <tr><th>Value: <td>[ <var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var> | auto ]{1,4}
  <tr><th>Initial: <td>(see individual properties)
  <tr><th>Applies to: <td>all elements
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>width* of containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>see individual properties
  <tr><th>Canonical order: <td>N/A
  <tr><td colspan="2" class="footnote">*) if the <em>containing
    block</em> is <em>horizontal,</em> otherwise the height
</table>

<table class="propdef">
  <tr><th>Name: <td><dfn>padding-top</dfn> , <dfn>padding-right</dfn>,
    <dfn>padding-bottom</dfn>, <dfn>padding-left</dfn>
  <tr><th>Value: <td>[ <var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var> | auto ]
  <tr><th>Initial: <td>0
  <tr><th>Applies to: <td>all elements
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>width* of containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>&lt;length&gt;
  <tr><th>Canonical order: <td>N/A
  <tr><td colspan="2" class="footnote">*) if the <em>containing
    block</em> is <span><em>horizontal,</em></span> otherwise the height
</table>

<p>Sets the thickness of the <em>padding area.</em> The value may not
be negative.

<p class=issue>Allow negative padding?

<p class=issue>Define 'auto' or remove it. (Probably define it: it
seems useful for stretching the padding, like 'margin: auto'
strectches the margin.)

<p>'Padding' is a shorthand for the other four properties. If 'padding' has
four values, they are for top, right, bottom and left in that order. If left
is omitted, it is the same as right. If bottom is omitted it is the same as
top, if right is omitted it is the same as top.

<p class=note>Note that percentages on 'padding-top' and 'padding-bottom'
are relative to the <em>width</em> of the containing block, not the height
(at least in a horizontal flow; in a vertical flow they are relative to the
height).

<p class=note>Note that percentages are not required for CSS level 2.

<div class=example>
<p>For example, the following two ways to set the padding of <code>h1</code>
are equivalent:
<pre>h1 { padding: 0.5em }
h1 { padding-top: 0.5em;
     padding-right: 0.5em;
     padding-bottom: 0.5em;
     padding-left: 0.5em }</pre>
</div>

<div class=issue>
<p>Values may not be negative, thus the third line is ignored, but
what about the fourth?

<pre>
p { font-size: 10pt;
    padding-left: 2em;
    padding: -11pt;
    padding-left: calc(1em - 11pt)
}
</pre>
</div>


<h2>The margin properties</h2>

<p>Margins in CSS serve to add both horizontal and vertical space
between boxes.

<table class="propdef">
  <tr><th>Name: <td><dfn>margin-top</dfn>, <dfn>margin-right</dfn>,
    <dfn>margin-bottom</dfn>, <dfn>margin-left</dfn>
  <tr><th>Value: <td><var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var> | fill | auto
  <tr><th>Initial: <td>0
  <tr><th>Applies to: <td>see text
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>width* of containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>the percentage as specified or the
    absolute length or ''auto''
  <tr><th>Canonical order: <td>N/A
  <tr><td colspan="2" class="footnote">*) if the <em>containing
    block</em> is <em>horizontal,</em> otherwise the height
</table>

<table class=propdef>
  <tr><th>Name: <td><dfn>margin</dfn>
  <tr><th>Value: <td>[ <var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var> | fill | auto]{1,4}
  <tr><th>Initial: <td>(see individual properties)
  <tr><th>Applies to: <td>see text
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>width* of containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>see individual properties
  <tr><th>Canonical order: <td>N/A
  <tr><td colspan="2" class="footnote">*) if the <em>containing
    block</em> is <em>horizontal,</em> otherwise the height
</table>

<p>These properties set the thickness of the <em>margin area</em>. The
value may be negative.

<p>'Margin' is a shorthand for the other four. If 'margin' has four
values, they set top, right, bottom and left in that order. If left is
omitted, it is the same as right. If bottom is omitted, it is the same
as top. If right is omitted it is the same as top.

<div class=example>
<p>For example, the following two ways of setting the margins of
<code>p</code> are equivalent:
<pre>p { margin: 1em 2em }
p { margin-top: 1em;
    margin-right: 2em;
    margin-bottom: 1em;
    margin-left: 2em }</pre>
</div>

<p>The values are as follows:

<dl>
<dt><var>&lt;length&gt;</var> <dd>Sets the margin to the given
length. Note that the actual distance to the next element may be
different, due to <span title="collapse" >margin collapsing.</span>

<dt><var>&lt;percentage&gt;</var> <dd>Sets the margin to the given
percentage of the <span>extent</span> of the <span>containing
block.</span> If that dimension depends on the value of this
percentage, then the percentage is taken relative to ''100vw'' or
''100vh'' instead, depending on whether the containing block is
<span>horizontal,</span> respectively <span>vertical.</span>

<dt><dfn>fill</dfn> <dd>Makes the margin depend on the available
space, as defined in <a href="#Calculating">“Calculating widths,
heights and margins”</a> and in <span class=issue>[the section that
defines how block-level boxes are laid out in a flow]</span>

<dt>auto <dd>On the <em>A edge</em> and <em>C edge</em>, the used
value of ''auto'' is 0. On the <em>B edge</em> and <em>D edge</em>,
the used value depends on the available space, as defined in <a
href="#Calculating">“Calculating widths, heights and margins.”</a>
</dl>

<p class=note>Note that inside flexboxes [[CSS3-FLEXBOX]], the meaning
of ''auto'' is different, because there it also has an effect on the
<em>A edge</em> and <em>C edge.</em>

<p class=issue>Another option is to combine a length/percentage with
''fill'', to set a desired margin in case there is no space to
distribute, e.g. ''1.2em + fill'' or ''fill(1.2em)''. Is that ever
needed?

<p class=issue>'Fill' could also be a unit, like '%' or 'fr', so that
some fills can get more space than others. Is that useful?

<p class=issue>Andrew Fedoniouk proposed the '%%' unit. '50%%' is 50%
of the remaining space. This allows fills to sum up to more or less
than 100%. More than 100% is probably not useful, it guarantees
overflow. But less than 100% might be.

<p class=issue>The keywords 'min-content', 'max-content' and
'available' could also be useful, at least for the inline-start and inline-end
margin of a box. Then you can make a box that takes up no space by
setting 'width: available; margin-right: calc(0 - available)'

<p>The properties apply to all boxes except certain table-* boxes (see
[[CSS3TBL]]) and certain inline-level boxes (see [[!CSS3TEXT]]).

<!--

<p>To find the size of such a collapsed margin, find the nearest
enclosing containing block in the same flow that has a fixed height,
call that height <var>H1</var>. Compute the height of the content in
that containing block (while treating 'fill(<var>P</var>)' as if it
was simply <var>P</var>) and call that height <var>H2</var>. Count the
number <var>N</var> of stretchable margins. If <var>H2</var> &lt;
<var>H1</var>, then increase all the stretchable margins by
(<var>H1</var> - <var>H2</var>)/<var>N</var>. If there is no such
enclosing block, 'fill(<var>P</var>)' simply means <var>P</var>.

<p>In a multi-column element, each column box is a separate containing
block for the purpose of stretching the margins.

-->


<p class=note>Note that in a <span>horizontal flow,</span> percentages on
'margin-top' and 'margin-bottom' are relative to the <em>width</em> of the
containing block, not the height (and in vertical flow, 'margin-left' and
'margin-right' are relative to the height, not the width).


<h2>The width and height properties</h2>

<table class=propdef>
  <tr><th>Name: <td><dfn>width</dfn>
  <tr><th>Value: <td>[<var>&lt;length></var> | <var>&lt;percentage></var>] &amp;&amp;
    [border-box | content-box]? | available | min-content |
    max-content | fit-content | auto
  <tr><th>Initial: <td>auto 
  <tr><th>Applies to: <td>all elements but non-replaced inline
    elements, table rows, and row groups
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>refer to width of containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>the specified keyword; or the specified
    percentage (with ''border-box'' or ''content-box'' if present); or
    the absolute length (with ''border-box'' or ''content-box'' if
    present); or ''auto'' if the property does not apply; (also see
    prose under &lt;percentage>)
  <tr><th>Canonical order: <td>the length or percentage before the
    keyword, if both are present
</table>

<table class=propdef>
  <tr><th>Name: <td><dfn>height</dfn>
  <tr><th>Value: <td>[<var>&lt;length></var> | <var>&lt;percentage></var>] &amp;&amp;
    [border-box | content-box]? | available | min-content |
    max-content | fit-content | complex | auto
  <tr><th>Initial: <td>auto 
  <tr><th>Applies to: <td>all elements but non-replaced inline
    elements, table columns, and column groups
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>see prose
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>the specified keywords, the specified
    percentage (see prose under &lt;percentage>) or the absolute
    length; ''auto'' if the property does not apply
  <tr><th>Canonical order: <td>the length or percentage before the
    keyword, if both are present
</table>

<!-- Nov 2007, ftf: add four keywords and Jason's example of image + caption -->

<p>These properties specify the width and height of the <em>content
area</em> or <em>border area</em> (depending on
'box-sizing') of certain boxes.

<p>Values have the following meanings:

<dl>
  <dt><var>&lt;length></var> <dd>Specifies the size using a length
  unit. Negative values are illegal. If the keyword ''border-box'' is
  present, the length sets the size of the border box; if
  ''content-box'' is present, it sets the size of the content box; if
  neither is present, the 'box-sizing' property determines which size
  is set.

  <dt><var>&lt;percentage></var> <dd>Specifies a percentage width or
  height. The percentage is calculated with respect to the width (in
  the case of 'width') or height (for 'height') of the generated box's
  <span>containing block.</span> Negative percentages are illegal. If
  the containing block's width, resp. height depends on this element,
  <span class=issue>then the percentage is relative to '100vw', resp. 
  '100vh'.</span> If the keyword ''border-box'' is present, the
  percentage sets the size of the border box; if ''content-box'' is
  present, it sets the size of the content box; if neither is present,
  the 'box-sizing' property determines which size is set.

  <dt>available <dd>Equal to the <em>containing block</em> width or
  height minus the current element's margin, border, and padding. 
  <span class=issue>If the required width, resp. height of the
  containing block is unknown (depends on this element), then
  ''available'' is equal to '100vw', resp. '100vh'.</span>

  <dt>max-content <dd>The <em>max-content</em> width or
  height.

  <dt>min-content <dd>The <em>min-content</em> width or height.

  <dt>fit-content <dd>Equal to max(''min-content'',
  min(''max-content'', ''available'')).

  <dt>auto <dd>The width or height depends on the values of other
  properties. See <a href="#Calculating">Calculating widths, heights
  and margins</a> below.

  <dt>complex <dd>(Only on 'height'.) The same as ''auto'', except
  that elements with a <em>complex aspect ratio</em> are considered to
  have an <em>intrinsic ratio.</em> More precisely: for the purposes
  of the section on <a href="#Calculating">“Calculating widths,
  heights and margins,”</a> the element is treated as if its height
  was ''auto'' and it had an <em>intrinsic ratio.</em>
</dl>

<p class=issue>Another possible value is
<var>&lt;non-negative-number&gt;</var>, which would mean
''min-content'' times that number.

<p class=issue>The width property of ''@viewport''
[[CSS-DEVICE-ADAPT]] is a shorthand for min-width and max-width and
can have either one or two values. Anything we can do to alleviate
risk of the confusion?

<p class=note>Note that ''available'', ''max-content'',
''min-content'', ''fit-content'', ''border-box'', ''content-box'' and
''complex'' do not exist in level 2.

<p>The keyword values (in contrast to length and percentage values)
are not influenced by the 'box-sizing' property, they always set the
size of the content box.

<p>''Available'', ''max-content'', ''min-content'' and ''fit-content''
only have effect in the inline progression direction: they are
equivalent to ''auto'' when set on the 'height' of <em>horizontal</em>
elements or on the 'width' of <em>vertical</em> elements.

<p class=note>Note that 'width: fit-content' is the same as 'width:
auto' for floats and tables, and 'width: available' is the same as
'width: auto' for blocks in the normal flow.

<div class=example>
<p>For example, the following rule fixes the content width of
paragraphs at 100 px:

<pre>p { width: 100px }</pre>
</div>

<div class=example>
<p>This example shows the use of the keyword values. Assume these
style rules:
<pre>
div {width: 20em}
p.available {width: available}
p.min-content {width: min-content}
p.max-content {width: max-content}
p.fit-content {width: fit-content}
p.float {float: left; width: auto}
p.auto {width: auto}
* {outline: thin solid red}
</pre>
<p>Then a document like this might be rendered as in the figure below:
<pre>
<b>&lt;div></b>
  <b>&lt;p class=available></b>available: as wide as parent.
  <b>&lt;p class=min-content></b>min-content: as narrow as possible.
  <b>&lt;p class=max-content></b>max-content: As wide as needed, even
    if that means wider than the parent.
  <b>&lt;p class=fit-content></b>fit-content: As wide as needed.
  <b>&lt;p class=fit-content></b>fit-content: As wide as needed, but
    no wider than the parent.
  <b>&lt;p class=float></b>auto: depends on flow (=float).
  <b>&lt;p class=auto></b>auto: depends on flow (=normal).
<b>&lt;/div></b>
</pre>
</div>

<div class=figure>
  <p><img src="width-keywords" alt="Image: paragraphs of different
  widths">

  <p class=caption>Rendering of the example:
  ''min-content'' and ''max-content'' depend only on the content;
  ''available'' depends only on the containing block; ''fit-content''
  depends on both; and ''auto'' acts either like ''available'' or like
  ''fit-content'', depending on the type of box.
</div>

<div class=example>
<p>This example sets the width of the border box of an element to 50%.
  It includes a fallback (48%) for UA that do not support the
  ''border-box'' keyword, such as level 2 UAs:
<pre>
div.side {
    width: 48%;
    width: 50% border-box }
</pre>
<p>It is equivalent to
<pre>
div.side {
    width: 50%;
    box-sizing: border-box }
</pre>
<p>except that the latter doesn't have a fallback for level 2 UAs
  (which don't support the 'box-sizing' property).
</div>


<h2 id=min-max>The min-width, max-width, min-height and
max-height properties</h2>

<table class=propdef>
  <tr><th>Name: <td><dfn>min-width</dfn>, <dfn>min-height</dfn>
  <tr><th>Value: <td>[ [<var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var>] &amp;&amp; [border-box | content-box]? ] |
    available | min-content | max-content | fit-content
  <tr><th>Initial: <td>0
  <tr><th>Applies to: <td>all elements but non-replaced
    inline elements, table rows, and row groups
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>refer to width, resp. height of
    containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>the percentage as specified (with
    ''border-box'' or ''content-box'', if present), the keyword as
    specified, or the absolute length (with ''border-box'' or
    ''content-box'', if present)
  <tr><th>Canonical order: <td>the length or percentage before the
    keyword, if both are present
</table>

<table class=propdef>
  <tr><th>Name: <td><dfn>max-width</dfn>, <dfn>max-height</dfn>
  <tr><th>Value: <td>[ [<var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var>] &amp;&amp; [border-box | content-box]? ] |
    available | min-content | max-content | fit-content | none
  <tr><th>Initial: <td>none
  <tr><th>Applies to: <td>all elements but non-replaced inline
    elements, table rows, and row groups
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>yes
  <tr><th>Percentages: <td>refer to width, resp. height of
    containing block
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>the percentage as specified (with
    ''border-box'' or ''content-box'', if present); the keyword as
    specified; the absolute length (with ''border-box'' or
    ''content-box'', if present); or none
  <tr><th>Canonical order: <td>the length or percentage before the
    keyword, if both are present
</table>

<p>These properties allow authors to constrain content widths and
heights to a certain range. Values have the following meanings:</p>

<dl>
  <dt><var>&lt;length&gt;</var> <dd>Specifies a fixed minimum or
  maximum for 'width' or 'height'. Negative values are illegal.

  <dt><var>&lt;percentage&gt;</var> <dd>Specifies a minimum or maximum
  for 'width' or 'height' as a percentage of the corresponding
  dimension of the <em>containing block.</em> Negative percentages are
  illegal. If the containing block's dimension is negative, the used
  value is zero. If that containing block's dimension depends on this
  element's dimension, then the resulting layout is undefined. <span
  class=issue>Or: use the initial value?</span>

  <dt>max-content <dd>The <em>max-content</em> width or height.

  <dt>min-content <dd>The <em>min-content</em> width or height.

  <dt>available <dd>The containing block width or height minus margin,
  border, and padding.

  <dt>fit-content <dd>For 'max-width'/'max-height', same as
  ''max-content''. For 'min-width'/'min-height', same as
  ''min-content''.

  <dt>none <dd>No limit on the width or height of the box.
</dl>

<p>The keyword values (in contrast to length and percentage values)
are not influenced by the 'box-sizing' property, they always set the
size of the content box.

<p>''Available'', ''max-content'', ''min-content'' and ''fit-content''
only have effect in the inline progression direction: they are
equivalent to 0 when set on the 'min-height' of <em>horizontal</em>
elements or on the 'min-width' of <em>vertical</em> elements; they are
equivalent to ''none'' when set on the 'max-height' of
<em>horizontal</em> elements or on the 'max-width' of
<em>vertical</em> elements.


<h2 id=intrinsic>Definition of min-content/max-content</h2>

<p>The size of a box often depends on the intrinsic width or height of
its content. This section defines two characteristics of a box: the
<em>max-content</em> size and the <em>min-content</em> size. They
refer to the <em>measure.</em>

<p>For <span>horizontal</span> boxes, the max-content width is,
roughly, the size the content would have if no “soft” line breaks were
inserted, i.e., if each paragaph is one long line; the min-content
width is, roughly, the narrowest the box can get by breaking all lines
at all possible break points. Another way of thinking about them is
that they are, respectively, the width that minimizes the height; and
the narrowest the content can get without unintended overflow.

<div class=figure>
  <p><img src="width-intrinsic" alt="">

  <p class=caption>For example, in a simple paragraph with just text
  the max-content width is the width of the line if all words are laid
  out on one line; and the min-content width is the width of the
  longest word (or the longest syllable, if hyphenation is turned on).
</div>

<p>The <dfn>min-content</dfn> width of a <em>horizontal,</em>
non-replaced element <var>E</var> is defined as the smallest length
<var>M</var> &ge; 0 such that

<blockquote>
<p>OVERFLOW(<var>E</var>,<var>M</var>) &le;
OVERFLOW(<var>E</var>,<var>w</var>) for all <var>w</var> &ge; 0
</blockquote>

<p>where the function OVERFLOW(<var>E</var>,<var>w</var>) is defined
as follows. Set the 'display' of <var>E</var> to ''block'', 'float' to
''none'', 'position' to ''static'', 'overflow' to ''visible'',
'min-width' to ''0'', 'max-width' to ''none'', 'height' to ''auto'',
'min-height' to ''0'', 'max-height' to ''none'' and 'width' to
<var>w</var>. Then measure the total width <var>W</var> of
<var>E</var> including all overflow, considering <var>E</var> and all
its descendants in the same flow and all floats of which <var>E</var>
is the <span>containing block.</span> Then

<blockquote>
<p>OVERFLOW(<var>E</var>,<var>w</var>) = <var>W</var> - <var>w</var>
</blockquote>

<p>The <dfn>max-content</dfn> width of a <em>horizontal,</em>
non-replaced element <var>E</var> is defined as the smallest length
<var>M</var> &ge; 0 such that

<blockquote>
<p>HEIGHT(<var>E</var>,<var>M</var>) &le;
HEIGHT(<var>E</var>,<var>w</var>) for all <var>w</var> &ge; 0
</blockquote>

<p>where HEIGHT(<var>E</var>,<var>w</var>) is defined as follows. Set
the 'display' of <var>E</var> to ''block'', 'float' to ''none'',
'position' to ''static'', 'overflow' to ''visible'', 'min-width' to
''0'', 'max-width' to ''none'', 'height' to ''auto'', 'min-height' to
''0'', 'max-height' to ''none'', 'width' to <var>w</var> and lay out
<var>E</var> as a flow root. Then HEIGHT(<var>E</var>,<var>w</var>) is
the height as defined below in <a href="#root-height">“Auto heights
for flow roots.”</a>

<p>The corresponding definitions for vertical elements are analogous,
with width and height swapped.

<p class=note>OVERFLOW is not necessarily monotonic in <var>w</var>
and a binary search for min-content and max-content may thus fail.

<p class=issue>Say something about acceptable near-optimal results?

<p class=note>Note that the ''min-content'' width of a block may be
larger than the ''min-content'' of all its children, because it may be
impossible to break a line between two children.

<p class=note>The intrinsic sizes of <em>replaced elements</em> are
defined in [[!CSS3-IMAGES]].


<h2><span class=index>Aspect ratios</span> of replaced elements</h2>

<p>For the purposes of the width and height calculations below, CSS
distinguishes four kinds of <em title="replaced element"
class=index>replaced elements</em>:

<dl>
<dt>Type 1: replaced elements with both <em class=index >intrinsic
width</em> and <em class=index >intrinsic height.</em> <dd>These are
replaced elements that are meant to be displayed with a certain fixed
factor (the <em class=index >intrinsic ratio</em>) between their width
and height and also have a default size. Different formats may have
different ways of specifying the size, e.g., a width and a ratio, or a
raster and a resolution in dots per inch. Raster images fall in this
category.

<dt>Type 2: replaced elements with only an <em class=index >intrinsic
ratio</em> <dd>These are replaced elements that are meant to be
displayed with a certain fixed factor between their width and height,
but without a default size. <span class=index>SVG</span> images often
fall in the this category.

<dt>Type 3: replaced elements with a <dfn>complex aspect ratio</dfn>
<dd>These are replaced elements that do not have a <em>fixed</em>
ratio between their width and height, but that do have a functional
relation between them in the sense that to every width corresponds a
certain height and vice-versa. HTML documents are examples of this:
the width can be chosen freely, but at every width there is a definite
intrinsic height.

<dt>Type 4: replaced elements without an intrinsic ratio <dd>These are
replaced elements that have no relation between their width and
height. Certain <span class=index>SVG</span> images are examples of
this.
</dl>

<p>For <span class=index>raster images</span> without reliable
resolution information, a size of 1 px unit per image source pixel
must be assumed. These images thus are of type 1.

<div class=example>
<p>E.g., according to the section on <a href="#inline-replaced">inline
replaced elements</a> below, if the replaced element is an HTML
document and the height is specified as ''auto'', e.g.:
<pre>
... &lt;object data="example.html"
      style="width: 30em; height: auto">&lt;/object>...
</pre>
<p>then the used height will be 150px, which is unlikely to be the
real height of the example.html document. But if the height is
specified as ''complex'', e.g.:
<pre>
... &lt;object data="example.html"
      style="width: 30em; height: complex">&lt;/object>...
</pre>
<p>then the height will be the height the example.html document
normally has when displayed on its own with the given width. This
enables almost seamless integration of external text in a document,
without a scrollbar or other scrolling mechanism. (The external text
is still displayed with its own style sheet.)
</div>

<div class=example>
<p>An external mathematical formula in MathML is an example of
replaced content with an intrinsic width and height. Assume the file
m.mml contains a formula, then the HTML fragment

<pre>
... derive &lt;img src="m.mml"
alt="that the sum of p(i) for i greater than 0 equals N">
for the case...
</pre>

<p>renders the formula at its intrinsic size.

<p>(Note, however, that it is often better to specify the formula
directly in the HTML file, rather than as an external reference. That
way it shares the style of the surrounding text and can be broken over
two lines if it is too wide.)
</div>


<h2>Block-level formatting</h2>

<p>In a <dfn>block formatting context,</dfn> block-level boxes are
laid out in the manner of a series of paragraphs.

<p>The boxes of a <span>flow</span> are laid out one after the other
in the direction of the 'writing-mode' property of the <span>flow
root</span> and in the same order as in the source document. Their
position is given by how much their margins overlap (see <a
href="#collapsing-margins">“Collapsing margins”</a>) and by the fact
that their side margin edges coincide with the edges of their
containing block. More precisely: Each box's <span title="D
edge">D</span> and <span>B edge</span> coincide with respectively the
<span>inline-start</span> and <span>inline-end</span> edges of its <span>containing
block.</span>

<p class="issue">When is a block formatting context established?

<p class=issue>TODO: Need to deal with anonymous block boxes.

<div class=example>
<p>An example of the last point above is this document fragment:

<pre>&lt;p&gt;Somebody whose name I have
forgotten, said, long ago: &lt;q&gt;a box is
a box,&lt;/q&gt; and he probably meant it.&lt;/p&gt;</pre>

<p>with these style rules:
<pre>p { display: block }
q { display: block; margin: 1em }</pre>

<p>The <code>p</code> element has both line boxes and a child box for the
<code>q</code> element, which is a block-level element. The line boxes before
the <code>q</code> are wrapped in an anonymous block-level box and so are the
line boxes after the <code>q</code>. The resulting tree of boxes might be as
follows (refer to the <a href="#When">figure</a>):
<ul>
  <li>block-level box [p]
    <ul>
      <li>block-level box [anonymous]
        <ul>
          <li>line box: &ldquo;Somebody&hellip;&rdquo;
          <li>line box: &ldquo;forgotten&hellip;&rdquo;
        </ul>
      
      <li>block-level box [q]
        <ul>
          <li>line box: &ldquo;a box&hellip;&rdquo;
        </ul>
      
      <li>block-level box [anonymous]
        <ul>
          <li>line box: &ldquo;and he&hellip;&rdquo;
        </ul>
      
    </ul>
</ul>

<div class=figure id=When>
  <p><img alt="The P element has two line boxes before the q and one
  after. The first two are wrapped in an anonymous box, the last one
  is wrapped in another anonymous box." src="anonymous.png">

  <p class="caption">When the fragment is rendered, the text before
  the q is wrapped in an anonymous block and the text after the q in
  another.
</div>
</div><!--example-->


<h3 id=collapsing-margins>Collapsing margins</h3>

<p>Certain adjoining margins, as defined in this section, combine to
form a single margin. Those margins are said to <dfn>collapse.</dfn>
Margins are <dfn>adjoining</dfn> if there are no nonempty content,
<span title="padding area">padding</span> or <span title="border
area">border areas</span> or <em>clearance</em> to separate them.

<div class=example>
<p>For example, in the following fragment with the given style rules:
<pre>p { display: block; margin-bottom: 2em 0 1em 0 }
div { display: block; margin: 2.5em 0 }
...
&lt;p&gt;First paragraph&lt;/p&gt;
&lt;div&gt;
  &lt;p&gt;Second paragraph&lt;/p&gt;
&lt;/div&gt;</pre>

<p>the bottom margin of the first <code>p</code> (=1em), the top margin of
the <code>div</code> (=2.5em) and the top margin of the second <code>p</code>
(=2em) collapse. The result is a single margin of 2.5em (the maximum of the
three) between the bottom of the first <code>p</code> and the top of the
second.
</div>

<div class=figure>
  <p><img src="collapse1.png" alt="Three margins collapse: 1em + 2.5em + 2em">
  <p class=caption>Schematic representation of the previous example.
</div>

<div class=example>
<p>In the following fragment,
<pre>p { display: block; margin: 2em 0 1em 0 }
div { display: block; margin: 2.5em 0;
      border: thin solid }
...
&lt;p&gt;First paragraph&lt;/p&gt;
&lt;div&gt;
  &lt;p&gt;Second paragraph&lt;/p&gt;
&lt;/div&gt;</pre>

<p>the bottom margin of the first <code>p</code> and the top margin of
the <code>div</code> collapse, but the top margin of the second
<code>p</code> does not collapse with them, because it is not
<em>adjoining;</em> the border of the <code>div</code> separates them.
</div>

<div class=figure>
  <p><img src="collapse2.png" alt="Only two margins collapse: 1em + 2.5em">
  <p class=caption>Schematic representation of the previous example.
</div>

<p>If a set of adjoining margins collapses, then the width of the resulting
margin is <var>M</var> - <var>N</var>, where <var>M</var> is the maximum of
the adjoining margins that are positive, or zero if there are none; and
<var>N</var> is the minimum of the adjoining margins that are negative, or
zero if there are none. But if any of the margins is
<span>''fill''</span>, then the resulting margin is also ''fill''.

<p>We call an element or box <dfn>collapsed through</dfn> if two of
its margins collapse with each other.

<div class=example>
<p>The most common use of collapsing through elements is that empty
paragraphs don't cause extra white space:

<pre>&lt;p>First paragraph
&lt;p>Second paragraph
&lt;p>
&lt;p>Last paragraph</pre>

<p>There is equal space between the first and the second paragraphs as
between the second and the last.
</div>

<p>The following two sets of rules determine which margins collapse.

<ul>
  <li>Only margins of <em>block-level</em> boxes can collapse.

  <li>Margins of a floated box do not collapse with any other margins.

  <li>Margins of a <em>flow root</em> do not collapse with its
  children's margins.

  <li>Margins of an absolutely positioned box (see [[CSS3POS]]) do not
  collapse with any other margins.

  <!--
  <li>Margins of an ''inline-block'' box do not collapse (not even
  with its in-flow children). <span class=issue>Assuming the first
  rule above (“only block-level”) is correct, this rule seems
  redundant, because an inline block is not block-level.</span>
  -->

  <li>Margins of the root element's box do not collapse with any other
  margins. <!-- Note: the root element is not a flow root, because we
  defined the initial containing block to its flow root -->

  <li>If a box is <em>collapsed through</em> and it has
  <em>clearance</em> applied to one of its two collapsed margins, then
  those two margins do not collapse with certain of the parent's
  margins, as follows: If clearance is applied to, respectively, the
  top, right, bottom or left margin, then the two margins do not
  collapse with the parent's bottom, left, top or right margin,
  respectively.

  <!-- The CSS 2.1 rule for all-horizontal text -->
  <li>If the top margin of a box with non-zero computed
  'min-height' and 'auto' computed 'height' collapses with the
  bottom margin of its last in-flow child, then the child's bottom
  margin does not collapse with the parent's bottom margin.

  <!-- The following can happen in vertical-rl text -->
  <li>If the right margin of a box with non-zero computed
  'min-width' and 'auto' computed 'width' collapses with the
  left margin of its last in-flow child, then the child's left
  margin does not collapse with the parent's left margin.

  <!-- The following can happen in vertical-lr text -->
  <li>If the left margin of a box with non-zero computed
  'min-width' and 'auto' computed 'width' collapses with the
  right margin of its last in-flow child, then the child's right
  margin does not collapse with the parent's right margin.
</ul>

<p>Except when forbidden by the list above, the following margins
collapse:

<ul>
  <!-- transitive -->
  <li>
    <p>If a margin P collapses with a margin Q and margin Q with a
    margin R, then P, Q and R collapse together. (“Collapsing is
    transitive”)

  <!-- parent-child / block-start -->
  <li>
    <p>A margin of a box collapses with the <em>block-start</em> margin of
    its parent box if those two margins are <em>adjoining.</em>

  <!-- parent-child / block-end -->
  <li>
    <p>A margin of a box collapses with the <em>block-end</em> margin of
    its parent box if those two margins are <em>adjoining.</em>

  <!-- sibling -->
  <li>
    <p>The <em title="C edge">C</em> margin of a box collapses with
    the <em title="A edge">A</em> margin of a sibling box if the two
    margins are <em>adjoining.</em>

  <!-- self -->
  <li>
    <p>The <em title="A edge">A</em> and <em title="C edge">C</em>
    margins of a box collapse with each other if the two margins are
    <em>adjoining.</em> (The box is <em>“collapsed through.”</em>)
</ul>

<p>If a box X is <em>collapsed through</em> then the position of its
<em title="A edge">A</em> border edge is defined as follows.

<ul>
  <li>If X's margins are collapsed with its parent's <em>block-start</em>
  margin, the A border edge of X is defined to be the same as the
  parent's block-start border edge.

  <li>Otherwise, either the parent is not taking part in the margin
  collapsing, or only the parent's <em>block-end</em> margin is involved.
  The position of X's A border edge is defined to be the same as it
  would have been if X had a nonzero <em title="C edge">C</em> border.
</ul>

<p class=note>Note that box X itself is invisible and its position has
no effect on the positions of the other elements with whose margins it
is being collapsed; the border edge position is only required for
laying out descendants of X.

<div class=example>
<p>In a horizontal flow, the bottom margin of an in-flow
<span>block-level</span> element is adjoining to the top margin
of its next in-flow block-level sibling, unless that sibling has
clearance:

<pre>
&lt;p style="margin-bottom: 2em">The bottom margin of this
box&hellip;&lt;/p>

&lt;p style="margin-top: 3em">&hellip; collapses with the top margin
of this box, to yield max(2em, 3em) = 3em margin.&lt;/p>
</pre>

<p>The top margin of an in-flow block-level element is adjoining to
its first in-flow block-level child's top margin if the element has no
top border, no top padding, and the child has no clearance:

<pre>
&lt;div style="margin-top: 2em; padding: 0; border: 0">
  &lt;p style="margin-top: 3em">
    The top margin of the DIV and the P
    collapse, to yield max(2em, 3em) = 3em margin.
  &lt;/p>
&lt;/div>
</pre>

<p>The bottom margin of an in-flow block-level element with a 'height'
of ''auto'' and 'min-height' less than the element's used height and
'max-height' greater than the element's used height is adjoining to
its last in-flow block-level child's bottom margin if the element has
no bottom padding or border:

<pre>
&lt;div style="margin-bottom: 2em; padding: 0; border: 0;
    height: auto; min-height: 0; max-height: 100em">
  &lt;p style="margin-bottom: 3em">
    The bottom margin of the DIV and the P collapse, to yield max(2em,
    3em) = 3em margin.
  &lt;/p>
&lt;/div>
</pre>

<p>An element's own margins are adjoining if the 'min-height' property is
zero, and it has neither vertical borders nor vertical padding, and it has a
'height' of either 0 or ''auto'', and it does not contain a line box, and all
of its in-flow children's margins (if any) are adjoining:

<pre>
&lt;div style="margin-top: 2em; margin-bottom: 3em">
  &lt;p style="position: absolute">
    The DIV is empty and its top and bottom margins collapse.
  &lt;/p>
&lt;/div>
</pre>

<p>When an element's own margins collapse, and that element has had
clearance applied to it, its top margin collapses with the adjoining
margins of subsequent siblings but that resulting margin does not
collapse with the bottom margin of the parent block:

<pre>
&lt;div style="margin-bottom: 2em">
  &lt;p style="float: left">
    The margins of the next two Ps collapse
  &lt;p style="clear: left; margin-top: 4em; margin-bottom: 3em">
    <!-- empty -->
  &lt;/p>
  &lt;p style="margin-top: 1em; margin-bottom: 1em">
    <!-- empty -->
  &lt;/p>
&lt;/div>
</pre>

<p>The top and bottom margins of the two empty Ps collapse all
together. But they can't collapse with the bottom of the DIV, because
one of the two empty P's has clearance.

<p class=issue>Check this. This is probably the only possible
interpretation of the rules, but it is certainly not obvious that the
clearance of one element may stop later elements from
collapsing&hellip;
</div>

<p>Collapsing is based on the used value of 'padding', 'margin', and 'border'
(i.e., after resolving any percentages). The collapsed margin is calculated
over the used value of the various margins.


<h2>Inline-level formatting</h2>

<p>In an inline formatting context, inline-level boxes are laid out in
the manner of a run of words and sentences. Inline-level formatting,
and the behavior of inline-level boxes, is specified in the text
specification [[!CSS3TEXT]].


<h2 id=Calculating>Calculating widths, heights and margins</h2>

<p>The following two algorithms define the <em>used value</em> of
'width' and 'height' respectively and also the used values of the
'margin' properties and of 'top', 'right' 'bottom' and 'left'.

<p class=note>Note that they do not affect the computed values of
'width' and 'height'. Also note that in some cases the used width has
to be known in order to calculate the used height, or vice versa,

<p>For 'width':

<ol>
  <li>The tentative used width is calculated following the rules in
  the subsections below. If 'transform' is not ''none'', it is assumed
  to be 'rotate(0)' (i.e., the identity transform) for the purposes of
  this calcutlation.

  <li>If the tentative used width is greater than 'max-width', the same
  rules are applied again, but this time using the computed value of
  'max-width' as the computed value for 'width'.

  <li>If the resulting width is smaller than 'min-width', the same rules
  are applied again, but this time using the computed value of
  'min-width' as the computed value for 'width'.
</ol>

<p>For 'height':

<ol>
  <li>The tentative used height is calculated following the rules in
  the sections below. If 'transform' is not ''none'', it is assumed to
  be 'rotate(0)' (i.e., the identity transform) for the purposes of
  this calcutlation.

  <li>If the tentative used height is greater than 'max-height', the
  same rules are applied again, but this time using the computed value
  of 'max-height' as the computed value for 'height'.

  <li>If the resulting height is smaller than 'min-height', the same
  rules are applied again, but this time using the computed value of
  'min-height' as the computed value for 'height'.
</ol>

<p>If 'transform' is not ''none'', the used width or height is further
modified as follows:

<ul>
  <li>If the element is <em>horizontal</em> and 'height' is ''auto'',
  then the used height is the height of the content box after the
  transformation is applied.

  <li>If the element is <em>vertical</em> and 'width' is ''auto'',
  then the used width is the width of the content box after the
  transformation is applied.
</ul>

<p class=note>Note that translations [[!CSS3-2D-TRANSFORMS]] do not
affect the width or height and also do not affect the placement of
boxes in the normal flow (see <a href="#basic">“Basic flow layout”
</a>).

<p>However, for <em>replaced elements</em> with an <em>intrinsic
ratio</em> and both 'width' and 'height' specified as ''auto'', the
algorithm is as follows:

<p>Select from the table the resolved height and width values for the
appropriate constraint violation. Take the <var>max-width</var> and
<var>max-height</var> as max(min, max) so that <var>min</var> &#8804;
<var>max</var> holds true. In this table <var>w</var> and <var>h</var>
stand for the results of the width and height computations ignoring
the 'min-width', 'min-height', 'max-width' and 'max-height'
properties. Normally these are the intrinsic width and height, but
they may not be in the case of replaced elements with intrinsic
ratios.

<table class=equiv-table>
<thead>
  <tr><th>Constraint violation <th>Resolved width <th>Resolved height
<tbody>
  <tr><td>none
      <td><var>w</var>
      <td><var>h</var>
  <tr><td><var>w&nbsp;>&nbsp;max-width</var>
      <td><var>max-width</var>

      <td><var>max(max-width&nbsp;*&nbsp;h/w, min-height)</var>
  <tr><td><var>w&nbsp;&lt;&nbsp;min-width</var>
      <td><var>min-width</var>
      <td><var>min(min-width&nbsp;*&nbsp;h/w, max-height)</var>

  <tr><td><var>h&nbsp;>&nbsp;max-height</var>
      <td><var>max(max-height&nbsp;*&nbsp;w/h, min-width)</var>
      <td><var>max-height</var>
  <tr><td><var>h&nbsp;&lt;&nbsp;min-height</var>

      <td><var>min(min-height&nbsp;*&nbsp;w/h, max-width)</var>
      <td><var>min-height</var>
  <tr><td>(<var>w&nbsp;>&nbsp;max-width</var>) and (<var>h&nbsp;>&nbsp;max-height</var>), where (<var>max-width/w&nbsp;&#8804;&nbsp;max-height/h</var>)

      <td><var>max-width</var>
      <td><var>max(min-height, max-width&nbsp;*&nbsp;h/w)</var>
  <tr><td>(<var>w&nbsp;>&nbsp;max-width</var>) and (<var>h&nbsp;>&nbsp;max-height</var>), where (<var>max-width/w&nbsp;>&nbsp;max-height/h</var>)

      <td><var>max(min-width, max-height&nbsp;*&nbsp;w/h)</var>
      <td><var>max-height</var>
  <tr><td>(<var>w&nbsp;&lt;&nbsp;min-width</var>) and (<var>h&nbsp;&lt;&nbsp;min-height</var>), where (<var>min-width/w&nbsp;&#8804;&nbsp;min-height/h</var>)

      <td><var>min(max-width, min-height&nbsp;*&nbsp;w/h)</var>
      <td><var>min-height</var>
  <tr><td>(<var>w&nbsp;&lt;&nbsp;min-width</var>) and (<var>h&nbsp;&lt;&nbsp;min-height</var>), where (<var>min-width/w&nbsp;>&nbsp;min-height/h</var>)

      <td><var>min-width</var>
      <td><var>min(max-height, min-width&nbsp;*&nbsp;h/w)</var>
  <tr><td>(<var>w&nbsp;&lt;&nbsp;min-width</var>) and (<var>h&nbsp;>&nbsp;max-height</var>)

      <td><var>min-width</var>
      <td><var>max-height</var>
  <tr><td>(<var>w&nbsp;>&nbsp;max-width</var>) and (<var>h&nbsp;&lt;&nbsp;min-height</var>)

      <td><var>max-width</var>
      <td><var>min-height</var>
</tbody>
</table>

<p>Then apply the appropriate rules in the subsections below, as if
'width' and 'height' were computed as these values.

<p>The following subsections apply if the element's <em>containing
block</em> is <em>horizontal.</em> If it is <em>vertical,</em> the
same rules apply, but with every occurrence of “left” replaced by
“top,” “right” by “bottom,” “top” by “right,” “bottom” by “left”,
“height” by “width” and “width” by “height.”

<!-- '100vw' decided at ftf Sep 10, 2007. '100vh' is my sugggestion
[BB] --> <p>For the purposes of evaluating percentages in the
following subsections, if the width of the containing block is
unknown, then assume the width is '100vw'. Likewise, if the height of
the containing block is unknown, then assume it is '100vh'.


<h3 id=inline-non-replaced>Inline, non-replaced
elements</h3>

<p>The 'width' and 'height' properties do not apply. For each of
'left', 'right', 'top', 'bottom', 'margin-left', 'margin-right',
'margin-top' and 'margin-bottom', the used value is calculated from
the computed value by evaluating percentages and replacing ''auto''
and ''fill'' by 0.

<p class=note>Note that this section applies equally when
the <em>containing block</em> is <em>horizontal</em> as when it
is <em>vertical.</em>


<h3 id=inline-replaced>Inline or floating, replaced
elements</h3>

<p>The used values of 'margin-left', 'margin-right', 'margin-top' and
'margin-bottom' derive from the computed value, except that a computed
value of ''auto'' becomes a used value of '0'.

<p>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'.

<p>If 'height' and 'width' both have computed values of ''auto'' and
the element also has an intrinsic height, then that intrinsic height
is the used value of 'height'.

<p>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 has an
intrinsic ratio; then the used value of 'width' is:

  <blockquote><p>(used height) * (intrinsic ratio)</blockquote>

<p>If 'height' and 'width' both have computed values of ''auto'' and
the element has no intrinsic height, but does have an intrinsic width
and intrinsic ratio; or if 'height' has a computed value of ''auto'',
'width' has some other computed value, and the element has an
intrinsic ratio; then the used value
of 'height' is:

  <blockquote><p>(used width) / (intrinsic ratio)</blockquote>

<p>If 'height' and 'width' both have computed values of ''auto'' and
the element has an intrinsic ratio but no intrinsic height or width
and the containing block's width doesn't itself depend on the replaced
element's width, then the used value of 'width' is calculated from the
<a href="#width-constraints">constraint equation</a> used for
block-level, non-replaced elements in normal flow. The used value for
'height' is: (used width) / (intrinsic ratio).

<p>If 'width' has a computed value of 'auto', and the element has an
intrinsic width but no intrinsic ratio, then that intrinsic width is
the used value of 'width'.

<p>If 'height' has a computed value of 'auto', and the element has an
intrinsic height but no intrinsic ratio, then that intrinsic width is
the used value of 'width'.

<p>If 'width' has a computed value of ''auto'', but none of the
conditions above are met, then the used value of 'width' becomes
300px. 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.

<p>If 'height' has a computed value of ''auto'' and none of the rules
above define its used value, then the used value of 'height' must be
set to the height of the largest rectangle that has a 2:1 ratio, has a
height not greater than 150px, and has a width not greater than the
device width.

  <p class=issue>Theoretically, a device may be wider than than 300px
  but not tall enough for 150px. In that case the resulting replaced
  element will be too tall. But this is the formulation in CSS 2.1 and
  it seems not worth improving such an edge case.

<p>Percentage intrinsic widths are first evaluated with respect to the
containing block's width, if that width doesn't itself depend on the
replaced element's width. If it does, then a percentage intrinsic
width on that element can't be resolved and the element is assumed to
have no intrinsic width.

  <p class=note>Note that this section applies equally when the
  <em>containing block</em> is <em>horizontal</em> as when it is
  <em>vertical.</em>


<h3 id=blockwidth>Block-level, non-replaced elements
in normal flow
when 'overflow' computes to ''visible''</h3>

<p>This section also applies to <span>block-level</span> non-replaced
elements in normal flow when 'overflow' does not compute to
''visible'' but has been propagated to the viewport.

<p>The used values of the <span>block-start</span> padding, <span>block-end</span>
padding, <span>block-start</span> margin and <span>block-end</span> margin are
calculated from their computed values, with any ''auto'' values
replaced by 0.

<div class=note>

  <p>The complexity of this section comes from the fact that ''auto''
  values on 'width' and 'height' are resolved differently for
  <em>horizontal</em> and for <em>vertical</em> elements, and
  differently for parallel flows then for <span>orthogonal
  flows</span> (i.e., when the <em>containing block</em> is horizontal
  and the element itself vertical, or vice-versa). In paginated
  contexts, the element may further be split into boxes of unequal
  sizes.

  <p>There are three principles. The first is: If the element's size in
  the direction of the <em title="containing block">containing
  block's</em> <em>measure</em> (i.e., between the <em>B
  edge</em> and the <em>D edge</em>) is ''auto'', then that size is
  the same as the containing block (minus the element's own margins,
  padding and borders, if applicable).

  <p>The second principle applies to orthogonal flows only, and only
  if they are not in a paginated environment: If an element is
  orthogonal and its measure (i.e., the distance between its
  <em>A edge</em> and <em>C edge</em>) is ''auto'', then it is treated
  as a <a
  href="http://www.w3.org/TR/css3-multicol/#multi-column-element"
  >multi-column element</a> [[!CSS3COL]] and 'column-width', if not
  already set, is set to a value derived from the containing block's
  size and the <span>initial containing block</span>

  <p>The last principle applies to orthogonal flows in a paginated
  environment, e.g., in paged media or inside a multi-column element:
  Just like in a non-paginated environment, if an element is
  orthogonal and its measure is ''auto'', then it is treated
  as a <a
  href="http://www.w3.org/TR/css3-multicol/#multi-column-element"
  >multi-column element</a> [[!CSS3COL]] and 'column-width', if not
  already set, is set to a certain value. But, in addition, if that
  means that the first column would be so wide as stick out of the
  page or column (the <a
  href="http://www.w3.org/TR/css3-break/Overview.html#fragmentainer"
  >“fragmentainer,”</a> see [[CSS3-BREAK]]), then that first column is
  made narrower until it fits. But not narrower than
  ''min-content''. (If at that size it still doesn't fit, it may
  instead be moved to the next page/column or, if that is not
  possible, overflow.)

</div>


<!--
  <p>In a paginated environment, in particular inside a page or a
  column with a fixed height, it may be that such a vertical element
  with ''auto'' height would be too tall and would stick out below the
  page or column. In that case, it is laid out with a smaller line
  length, such that it doesn't stick out. (But not smaller than
  ''min-content'')

  <p>Whether in a paginated environment or not, such a vertical
  element, including its margin, padding and border, may be too wide
  for its containing block. In that case it is paginated. The
  different fragments that result from that may have a different line
  lengths in that case, e.g., in the case of the following figure. The
  fragments each have the top and bottom margin, padding and border of
  the element (although in a paginated environment, some of those
  margins disappear).

  <div class=figure>
  <p><img src="paginated-ortho" alt="Two pages of a book">

  <p class=caption>A horizontal text (represented by letters A, B, C…)
  containing a section with vertical text (represented by digits 1, 2,
  3…). The document is paginated and the vertical text ends up split
  over two pages. Note that the fragment of vertical text on the first
  page has a longer line length (<em>measure</em>) than the
  fragment on the second page.
  </div>

  <p>If the containing block is vertical, the situation is analogous,
  but with width and height changing roles:

  <p>The height of the element itself is either as specified, or, if
  it is ''auto'', calculated from the containing block's height by
  subtracting the element's own margins, padding and border. (Which of
  those are subtracted is determined by 'box-sizing'.)

  <p>If the element is vertical, i.e., the same as its containing
  block, this height is then used as the line length (<em>measure</em>) for laying out the element. And if the element is
  horizontal, i.e., orthogonal to the containing block, its width is
  used as line length, or, if that width is ''auto'', ''max-content is
  used instead.

  <p>If such a horizontal element with ''auto'' width would stick out
  of the side of a page or a fixed-length column when set with
  ''max-content'', it is instead laid out to a smaller width (but not
  narrower than ''min-content'').

  <p>If a horizontal element, including its margin, padding and
  border, is too tall for its containing block, it is paginated.
-->


<p>If the computed value of the <span>extent</span> is
not ''auto'', then the used value is calculated by evaluating the
computed value. Otherwise, the <span>extent</span> is
the distance between two edges that are defined as follows:

<ul>
<li>For the first edge: If the element is the <span>root
element</span> or if it has a non-zero <span>block-start</span> padding or a
non-zero <span>block-start</span>
border, then the first edge is the <span>headside</span> <em>margin
edge</em> of the first <span>line box</span> or <span>block-level
box</span> (whichever comes first); otherwise the first edge is the
<span>headside</span> <em>border edge</em> of the first <span>line
box</span> or <span>block-level box</span> (whichever comes first)
that doesn't have its margins <span>collapsed through.</span>

<li>For the second edge: If the element is the <span>root
element</span> or if it has a non-zero <span>block-end</span> padding or a
non-zero <span>block-end</span>
border, then the second edge is the <span>footside</span> <em>margin
edge</em> of the last <span>line box</span> or <span>block-level
box</span> (whichever comes last); otherwise the second edge is the
<span>footside</span> <em>border edge</em> of the last <span>line
box</span> or <span>block-level box</span> (whichever comes last) that
doesn't have its margins <span>collapsed through.</span>
</ul>

<p class=note>The above reflects the fact that the margins of the
element may collapse with the margins of its first and last children
(unless the element has a border or padding). In that case the
children's margins fall outside the block flow dimension.

<p>The position of the edges is calculated without applying relative
positioning, if any, to the children. And only children in the normal
flow are taken into account, i.e., floating boxes and absolutely
positioned boxes are ignored.

<div class=example>
<p>For example, the DIV in this fragment has a bottom border but no
padding or border at the top. The height is thus calculated from the
<em>border</em> edge of the first child (img1) to the <em>margin</em>
edge of the last child (img2). The result is 8em.

<pre>
div {border-bottom: 0.2em dashed}
img {height: 3em; display: block; margin: 1em}
...
&lt;div>
  &lt;img src="img1" alt=...>
  &lt;img src="img2" alt=...>
&lt;/div>
</pre>

  <div class=figure>
    <p><img src="height.png" alt="The top margin of the first IMG does
    not contribute to the height of the DIV.">

    <p class=caption>The height is measured from the top border edge
    of the first IMG to the bottom margin edge of the last.
  </div>
</div>

<p>With respect to the <span>measure,</span> one of the
following constraints must hold among the used values of the given
properties.

<ul id=width-constraints>
  <li>If the element has the same orientation as its containing block
  (i.e., both are <em>horizontal</em> or both are <em>vertical</em>):

  <blockquote>
  <p>inline-start margin + inline-start border + inline-start padding + measure +
  inline-end padding + inline-end border + inline-end margin = measure of
  containing block
  </blockquote>

  <li>Otherwise the constraint is relative to the height or width of
  the <em>initial containing block,</em> depending on whether the
  element is <span>horizontal</span> or <span>vertical,</span>
  respectively:

  <blockquote>
  <p>inline-start margin + inline-start border + inline-start padding + measure +
  inline-end padding + inline-end border + inline-end margin = width or height of
  <em>initial containing block</em>
  </blockquote>
</ul>

<p>The used values of the above properties, except for any values that
are ''auto'', are calculated from the computed values, evaluating
percentages. If this makes the measure negative, then set
its used value to 0. Ditto for inline-start padding and inline-end
padding. <span class=note>Note that such negative values can only
happen when the specified value includes 'calc()'.</span> Then apply
one of the following cases:

<ol>
  <li id=case1>
  <p>If none of the values is ''auto'', then there are three
  sub-cases:

  <ol>
    <li>If the current element's 'alignment' is ''center'', then the
    used values of inline-start margin and inline-end margin are set so that they
    are the same and the constraint is satisfied.

    <li>If 'alignment' corresponds to the <em>inline-end</em> edge, then the
    used value of the inline-end margin is set to the value that satisfies
    the constraint.

    <li>If 'alignment' has any other value, then the used value of the
    inline-start margin is set to the value that satisfies the constraint.
  </ol>

  <li>If the <span>measure</span> is ''auto'', then set the
  used value of all other properties in the constraint that are
  ''auto'' to 0 and set the used value of the measure so
  that the constraint is satisfied. If that makes the used value
  negative, then set it to 0 instead and apply <a href="#case1">case 1
  above.</a>

  <li>If both the <span>inline-start</span> and <span>inline-end</span> margins are
  ''auto'', and 'alignment' is 'center', then solve the constraint
  under the extra condition that the inline-start and inline-end margin are equal.

  <li>If both the <span>inline-start</span> and <span>inline-end</span> margins are
  ''auto'', and 'alignment' is not 'center', then solve the constraint
  under the extra condition that the inline-start and inline-end margins are equal.
  But if that makes them negative, then set both to 0 and
  apply <a href="#case1">case 1 above.</a>

  <li>If only the <span>inline-start</span> margin is ''auto'' and
  'alignment' corresponds to the <span>inline-end</span> edge, then set the
  inline-start margin to the value that satisfies the constraint.

  <li>If only the <span>inline-start</span> margin is ''auto'' and
  'alignment' does not correspond to the <span>inline-end</span> edge, then
  set the inline-start margin to the value that satisfies the constraint. But
  if that makes it negative, then set it to 0 instead and
  apply <a href="#case1">case 1 above.</a>

  <li>If only the <span>inline-end</span> margin is ''auto'' and 'alignment'
  corresponds to the <span>inline-start</span> edge, then set the inline-end margin
  to the value that satisfies the constraint.

  <li>If only the <span>inline-end</span> margin is ''auto'' and 'alignment'
  does not correspond to the <span>inline-start</span> edge, then set
  the <span>inline-end</span> margin to the value that satisfies the
  constraint. But if that makes it negative, then set it to 0 instead
  and apply <a href="#case1">case 1 above.</a>
</ol>

  <p class=note>Note that the best way to center a block is
  'margin-left: auto; margin-right: auto; alignment: center'. Setting
  the margins to ''auto'', instead of leaving them at 0, provides a
  fallback for UAs that do not support 'alignment' (which is a level 3
  feature).

  <p class=note>Note also that only 'alignment: center' guarantees
  proper centering. Setting the margins to ''auto'' only centers
  blocks if they are narrower than their containing block, because
  only one of the two margins is allowed to become negative.

<div class=example>
  <p>The following examples illustrate different ways of aligning a
  fixed-width block in its parent. Assume English text, default values
  for 'writing-mode' and 'direction', a P of fixed with (e.g., 'width:
  30em'), and the following HTML mark-up:

<pre>
&lt;div>
  &lt;p>A paragraph here.
&lt;/div>
</pre>

  <p>The following aligns the right border edge of the P with the
  right content edge of the DIV:

  <pre>p {alignment: right}</pre>

  <p>The following centers the P:

  <pre>p {alignment: center}</pre>

  <p>Adding ''auto'' margins provides a fallback for UAs that do not
  support 'alignment'. (The fallback has the desired effect as long as
  the DIV is wider than the P.)

  <pre>p {margin-left: auto; margin-right: auto; alignment: center}</pre>

  <p>“Conflicting” combinations of ''auto'' margins and 'alignment'
  are well-defined, but not very useful. They cause 'alignment' to be
  all but ignored. The following right-aligns the P (unless it is too
  wide for the DIV):

  <pre>p {margin-left: auto; alignment: left}</pre>

  <p>Similarly, the following left-aligns the P in the DIV:

  <pre>p {margin-right: auto; alignment: right}</pre>

  <p>Fixed or percentage margins can be combined with alignment. The
  following puts the right border edge of the P at 2em inside the
  right content edge of the DIV:

  <pre>p {margin-right: 2em; alignment: right}</pre>

  <p>The following does the same. The value of 'margin-left' is
  ignored in a right-aligned block:

  <pre>p {margin-right: 2em; margin-left: 4em; alignment: right}</pre>
</div>


<h3>Other block-level, non-replaced elements in normal flow</h3>

<p>This section applies to <span>block-level,</span> non-replaced
elements when 'overflow' does not compute to ''visible'' (except if
the 'overflow' property's value has been propagated to the viewport).

<p>The used values of <span>block-start</span> padding, <span>block-end</span>
padding, <span>block-start</span> margin and <span>block-end</span> margin are
calculated from the computed values, with any ''auto'' values replaced
by 0.

<p>If the <span>block flow dimension</span> is ''auto'', the used value
is defined by <a href="#root-height">“''Auto'' heights for flow
roots.”</a> Otherwise, the used value is evaluated from the computed
value.

<p>Apply the rules for <span>inline-start</span> margin, <span>inline-start</span>
padding, <span>measure,</span> <span>inline-end</span> padding and
<span>inline-end</span> margin as given above in <a href="#blockwidth">
“Block-level, non-replaced elements in normal flow when 'overflow'
computes to ''visible''.”</a>


<h3>'Inline-block' or floating, non-replaced
elements</h3>

<p class=issue>Not yet generalized with block-start, block-end, etc.

<p>The used values of 'margin-left', 'margin-right', 'margin-top' and
'margin-bottom' are derived from their computed values, except that a
computed value of ''auto'' gives a used value of 0.

<p>If the computed value of 'width' is ''auto'', the used value is the
same as for ''fit-content''. Otherwise the computed value is evaluated
to give the used value.

<p>If the computed value of 'height' is ''auto'', the used value is
defined by <a href="#root-height">“''Auto'' heights for flow roots.”
</a> If it contains a percentage and the height of the containing
block is not known (depends on this element), then the used value is
also defined by <a href="#root-height">“''Auto'' heights for flow
roots.”</a> Otherwise it is calculated by evaluating the computed
value.

<p>For inline-block boxes, the margin box is used when calculating the
height of the line box. <span class=issue>Does this belong
here?</span>


<h3 id=abs-non-replaced-width>Absolutely positioned, non-replaced
elements</h3>

<p>For the purposes of this section and the next, the term <dfn>static
position</dfn> (of an element) refers, roughly, to the position an
element would have had in the normal flow. More precisely:

<ul>
  <li>The static position for 'left' is the distance from the left
  edge of the containing block to the left margin edge of a
  hypothetical box that would have been the first box of the element
  if its 'position' property had been ''static'' and 'float' had been
  'none'. The value is negative if the box's margin is to the left
  of the containing block's edge.

  <li>The static position for 'right' is the distance from the right
  edge of the containing block to the right margin edge of the same
  hypothetical box as above. The value is positive if the box's margin
  is to the left of the containing block's edge.

  <li>The static position for 'top' is the distance from the top edge
  of the containing block to the top margin edge of the same
  hypothetical box as above. The value is negative if the box's margin
  is above the containing block's edge.

  <li>The static position for 'bottom' is the distance from the bottom
  edge of the containing block to the bottom margin edge of the same
  hypothetical box as above. The value is positive if the box's margin
  is above the containing block's edge.
</ul>

<p>But rather than actually calculating the dimensions of that
hypothetical box, user agents are free to make a guess at its probable
position.

<p>For the purposes of calculating the static position, the containing
block of fixed positioned elements is the initial containing block
instead of the viewport, and all scrollable boxes should be assumed to
be scrolled to their origin.

<p>This constraint must hold among the used values:

  <blockquote>
  <p>'left' + 'margin-left' + 'border-left-width' + 'padding-left' +
  'width' + 'padding-right' + 'border-right-width' + 'margin-right' +
  'right' = width of containing block
  </blockquote>

<p>If all three of 'left', 'width', and 'right' are ''auto'': First
set any ''auto'' values for 'margin-left' and 'margin-right' to 0. Then,
if the 'direction' property of the containing block is ''ltr'' set
'left' to the <em>static position</em> and apply rule number three
below; otherwise, set 'right' to the <em>static position</em> and
apply rule number one below.

<p>If none of the three is ''auto'': If both 'margin-left' and
'margin-right' are ''auto'', solve the equation under the extra
constraint that the two margins get equal values, unless this would
make them negative, in which case when direction of the containing
block is ''ltr'' (''rtl''), set 'margin-left' ('margin-right') to zero
and solve for 'margin-right' ('margin-left'). <span class=issue>Should
we remove the phrase starting with “unless”?</span> If one of
'margin-left' or 'margin-right' is ''auto'', solve the equation for that
value. If the values are over-constrained, ignore the value for 'left'
(in case the 'direction' property of the containing block is ''rtl'')
or 'right' (in case 'direction' is ''ltr'') and solve for that value.

<p>Otherwise, set ''auto'' values for 'margin-left' and 'margin-right'
to 0, and pick the one of the following six rules that applies.

<ol>
  <li>'left' and 'width' are ''auto'' and 'right' is not ''auto'',
  then the width is as for ''fit-content''. Then solve for 'left'.

  <li>'left' and 'right' are ''auto'' and 'width' is not ''auto'', then
  if the 'direction' property of the containing block is ''ltr'' set
  'left' to the <em>static position</em>, otherwise set 'right' to
  the <em>static position</em>. Then solve for 'left' (if 'direction'
  is ''rtl'') or 'right' (if 'direction' is ''ltr'').

  <li>'width' and 'right' are ''auto'' and 'left' is not ''auto'',
  then the width is ''fit-content''. Then solve for 'right'.

  <li>'left' is ''auto'', 'width' and 'right' are not ''auto'', then
  solve for 'left'.

  <li>'width' is ''auto'', 'left' and 'right' are not ''auto'', then
  solve for 'width'.

  <li>'right' is ''auto'', 'left' and 'width' are not ''auto'', then
  solve for 'right'.
</ol>

<p>This constraint must also hold among the used values:

  <blockquote>      
  <p>'top' + 'margin-top' + 'border-top-width' + 'padding-top' +
  'height' + 'padding-bottom' + 'border-bottom-width' +
  'margin-bottom' + 'bottom' = height of containing block
  </blockquote>

<p>If all three of 'top', 'height', and 'bottom' are ''auto'', set
'top' to the static position and apply rule number three below.

<p>If none of the three are ''auto'': If both 'margin-top' and
'margin-bottom' are ''auto'', solve the equation under the extra
constraint that the two margins get equal values. If one of
'margin-top' or 'margin-bottom' is ''auto'', solve the equation for
that value. If the values are over-constrained, ignore the value for
'bottom' and solve for that value.

<p>Otherwise, pick the one of the following six rules that applies.

<ol>
  <li>'top' and 'height' are ''auto'' and 'bottom' is not ''auto'':
  The used value of 'bottom' is its computed value. The used height is
  defined by <a href="#root-height">“''Auto'' heights for flow roots.”
  </a> The used values of 'margin-top' and 'margin-bottom' are their
  computed values, except that any ''auto'' gives a used value of 0. 
  Finally, the constraint gives the used value of 'top'.

  <li>'top' and 'bottom' are ''auto'' and 'height' is not ''auto'':
  The used value of 'top' is its <em>static position.</em> The used
  values of 'margin-top' and 'margin-bottom' are their computed
  values, except that any ''auto'' gives a used value of 0. Finally,
  the constraint gives the used value for 'bottom'.

  <li>'height' and 'bottom' are ''auto'' and 'top' is not ''auto'':
  The used height is defined by <a href="#root-height">“''Auto''
  heights for flow roots.”</a> The used values of 'margin-top' and
  'margin-bottom' are their computed values, except that any ''auto''
  gives a used value of 0. Finally, the constraint gives the used
  value of 'bottom'.

  <li>'top' is ''auto'', 'height' and 'bottom' are not ''auto'': The
  used values of 'margin-top' and 'margin-bottom' are their computed
  values, except that any ''auto'' gives a used value of 0. The
  constraint gives the used value for 'top'.

  <li>'height' is ''auto'', 'top' and 'bottom' are not ''auto'': The
  used values of 'margin-top' and 'margin-bottom' are their computed
  values, except that any ''auto'' gives a used value of 0. The
  constraint gives the used value for 'height'.

  <li>'bottom' is ''auto'', 'top' and 'height' are not ''auto'': The
  used values of 'margin-top' and 'margin-bottom' are their computed
  values, except that any ''auto'' gives a used value of 0. The
  constraint gives the used value for 'bottom'.
</ol>


<h3 id=abs-replaced>Absolutely positioned, replaced
elements</h3>

<p>This situation is similar to the previous one, except that the
element may have an intrinsic size or ratio. The sequence of
substitutions is now:

<ol>
  <li>The used value of 'width' and 'height' is determined as
  for <a href="#inline-replaced">inline replaced elements</a>.

  <li>For each of 'top', 'right', 'bottom', 'left', 'margin-top',
  'margin-right', 'margin-bottom' and 'margin-left', if the computed
  value is not ''auto'', the used value is equal to the computed
  value.

  <li>If both 'left' and 'right' have the value ''auto'', then if
  'direction' of the containing block is ''ltr'', the used value of
  'left' is its <em>static position;</em> else if 'direction' is
  ''rtl'', the used value of 'right' is its <em>static position.</em>

  <li>If both 'top' and 'bottom' have the value ''auto'', then the
  used value of 'top' is its <em>static position.</em>

  <li>If 'left' or 'right' (or both) are ''auto'', and 'margin-left'
  is ''auto'', then the used value of 'margin-left' is 0.

  <li>If 'left' or 'right' (or both) are ''auto'', and 'margin-right'
  is ''auto'', then the used value of 'margin-right' is 0.

  <li>If neither 'left' nor 'right' are ''auto'' and both
  'margin-left' and 'margin-right' are ''auto'', then the used values
  satisfy the extra constraint that 'margin-right' and 'margin-left'
  are equal, unless this would make them negative, in which case when
  the direction of the containing block is ''ltr'' (''rtl''), the used
  value of 'margin-left' ('margin-right') is
  0. <span class=issue>Remove the part starting with “unless”? It
  looks better to center the image.</span>
</ol>

<p>The remaining used values, if any, follows from these two
constraints:

  <blockquote>
  <p>'left' + 'margin-left' + 'border-left-width' + 'padding-left' +
  'width' + 'padding-right' + 'border-right-width' + 'margin-right' +
  'right' = width of containing block

  <p>'top' + 'margin-top' + 'border-top-width' + 'padding-top' +
  'height' + 'padding-bottom' + 'border-bottom-width' +
  'margin-bottom' + 'bottom' = height of containing block
  </blockquote>

<p>If the first equation is over-constrained, ignore the value for
either 'left' (in case the 'direction' property of the containing
block is ''rtl'') or 'right' (in case 'direction' is ''ltr'') and solve
for that value.

<p>If the second equation is over-constrained, ignore the value for
'bottom' and solve for that value.


<h3>Block-level, replaced elements in normal flow</h3>

<p>Apply the rules for <a href="#inline-replaced">inline replaced
elements</a>, but ignore the resulting values for 'margin-left' and
'margin-right'. To compute the used value of those, apply the rules
for <a href="#blockwidth">block-level, non-replaced elements</a> using
the used values just found for 'width', 'border' and 'padding' as if
they were the computed values.


<h3>Floating, non-replaced elements</h3>

<p>The used values of the margins are derived from the computed
values, except that the used values of any margins computed as
''auto'' are '0'.

<p>The used value of 'width' is derived from the computed value,
except that if 'width' is computed as ''auto'', the used value is the
same as for ''fit-content''.

<p>If the computed value of 'height' is ''auto'', the used value is
given by <a href="#root-height">“''Auto'' heights for flow roots.”
</a> If the computed value includes a percentage and the height of the
containing block is not known (depends on this element), then the used
value is computed as if the computed value were ''auto''. Otherwise
the computed value is evaluated to give the used value.


<h3 id=root-height>Auto heights for flow roots</h3>

<p>In certain cases (see the preceding sections), the height of an
element is computed as follows:

<p>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.

<p>If it has <span>block-level</span> 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.

<p>Absolutely positioned children are ignored, and relatively
positioned boxes are considered without their offset. Note that the
child box may be an <em>anonymous block box.</em>

<p>In addition, if the element has any floating descendants whose
bottom margin edge is below the bottom, then the height is increased
to include those edges. Only floats that are children of the element
itself or of descendants in the normal flow are taken into account,
e.g., floats inside absolutely positioned descendants or other floats
are not.


<h2>The float property</h2>

<table class=propdef>
  <tr><th>Name: <td><dfn>float</dfn>
  <tr><th>Value: <td>left | right | top | bottom | start | end | none |
    <var>&lt;page-floats&gt;</var>
  <tr><th>Initial: <td>none 
  <tr><th>Applies to: <td>all, but see text
  <tr><th>Inherited: <td>no 
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A 
  <tr><th>Media: <td>visual 
  <tr><th>Computed value: <td>as specified
  <tr><th>Canonical order: <td>order of grammar
</table>

<!--Adding ''start'' and ''end'' was decided at 2009-12-02
telcon. Precise definitions not yet decided: does it depend on
'direction' of the element itself or its parent?-->

<p>This property specifies whether a box should float to the left,
right, or not at all. It only applies if the element has a
'display' other than ''none'' and a 'position' of ''static'' or
''relative''.

<p class=note>The 'float' property in turn influences the computed
value of 'display'. See <a href="#display">“The display property.”</a>

<p>The values of this property have the following meanings:

<dl>
  <dt>top <dd>Same as ''left''

  <dt>left <dd>If 'writing-mode' is ''tb'', the element generates
  a box that is floated to the left and content flows on the right
  side of the box (subject to the 'clear' property). If
  'writing-mode' has a different value, the element generates a
  box that is floated to the top and content flows on the bottom side
  of the box (subject to the 'clear' property).

  <dt>bottom <dd>same as ''right''

  <dt>right</dt> <dd>Similar to ''left'', except the box is floated to
  the right (if 'writing-mode' is ''tb'') or to the bottom
  (otherwise), and content flows on the left or top side of the
  box.

  <dt>start <dd>If the containing block's 'direction' is ''ltr'', then
  the same as ''left''; otherwise the same as ''right''.

  <dt>end <dd>If the containing block's 'direction' is ''rtl'', then
  the same as ''right''; otherwise the same as ''left''.

  <dt>none</dt> <dd>The box is not floated.

  <dt><var>&lt;page-floats&gt;</var> <dd>See Generated Content for
  Paged Media [[CSS3GCPM]]. <span class=issue>Check that the names
  page-top, page-bottom, next-top, or otherwise do not clash with top
  and bottom</span>
</dl>

<p>User agents may treat float as ''none'' on the root element.


<h3>Introduction to floats</h3>

<p>(This section is not normative.)

<p>A float is a box that is shifted to the left or right on the
current line. The most interesting characteristic of a float (or
“floating” box) is that content may flow along its side (or be
prohibited from doing so by the 'clear' property). Content flows down
the right side of a left-floated box and down the left side of a
right-floated box. The following is a (non-normative) introduction to
float positioning and content flow; the exact rules governing float
positioning are given in the next section.

<p>A floated box is shifted to the left or right until its margin edge
touches the containing block edge or the margin edge of another float. 
If there is a line box, the top of the floated box is aligned with the
top of the current line box.

<p>If there isn't enough horizontal room for the float, it is shifted
downward until either it fits or there are no more floats present.

<p>Since a float is not in the flow, non-positioned block boxes
created before and after the float box flow vertically as if the float
didn't exist. However, <em>line boxes</em> created next to the float
are shortened to make room for the margin box of the float. If a
shortened line box is too small to contain any further content, then
it is shifted downward until either it fits or there are no more
floats present. Any content in the current line before a floated box
is re-flowed in the first available line on the other side of the
float. In other words, if inline boxes are placed on the line before a
left float is encountered that fits in the remaining line box space,
the left float is placed on that line, aligned with the top of the
line box, and then the inline boxes already on the line are moved
accordingly to the right of the float (the right being the other side
of the left float) and vice versa for rtl and right floats.

<div class=example>
<p>In the following document fragment, the containing block is too
narrow to contain the content next to the float, so the content gets
moved to below the floats where it is aligned in the line box
according to the text-align property.

<pre>
p { width: 10em; border: solid aqua; }
span { float: left; width: 5em; height: 5em; border: solid blue; }

...

&lt;p&gt;
  &lt;span&gt; &lt;/span&gt;
  Supercalifragilisticexpialidocious
&lt;/p&gt;
</pre>

<p>This fragment might look like this:

<div class=figure>
  <p><img src="supercal.png" alt="Image illustrating the effect of an
  unbreakable piece of content being reflowed to just after a float
  which left insufficient room next to it for the content to fit.">

  <p class=caption>The text is too long to fit in a shortened line box
  next to the float (dark blue box) and so it is pushed down until it
  is passed the float.
</div>
</div>

<p>Several floats may be adjacent, and this model also applies to
adjacent floats in the same line.

<div class=example>
<p>The following rule floats all IMG boxes with
<code>class="icon"</code> to the left (and sets the left margin to
'0'):

<pre>
img.icon { 
  float: left;
  margin-left: 0;
}
</pre>
</div>

<div class=example>
<p>Consider the following HTML source and style sheet:

<pre>
&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"&gt;
&lt;HTML&gt;
  &lt;HEAD&gt;
    &lt;TITLE&gt;Float example&lt;/TITLE&gt;
    &lt;STYLE type="text/css"&gt;
      IMG { float: left }
      BODY, P, IMG { margin: 2em }
    &lt;/STYLE&gt;
  &lt;/HEAD&gt;
  &lt;BODY&gt;
    &lt;P&gt;&lt;IMG src=img.png alt="This image will illustrate floats"&gt;
       Some sample text that has no other...
  &lt;/BODY&gt;
&lt;/HTML&gt;
</pre>

<p>The IMG box is floated to the left. The content that follows is
formatted to the right of the float, starting on the same line as the
float. The line boxes to the right of the float are shortened due to
the float's presence, but resume their “normal” width (that of the
containing block established by the P element) after the float. This
document might be formatted as:

<div class=figure>
  <p><img src="floateg.png"
     alt="Image illustrating how floating boxes interact with margins.">

  <p class=caption>An image showing the various margins of the BODY, P
  and IMG element. Not that the top margin of the floating IMG does
  not collapse with the top margins of the P and BODY elements.
</div>

<p>Formatting would have been exactly the same if the document had
been:

<pre>
&lt;BODY&gt;
  &lt;P&gt;Some sample text 
  &lt;IMG src=img.png alt="This image will illustrate floats"&gt;
           that has no other...
&lt;/BODY&gt;
</pre>

<p>because the content to the left of the float is displaced by
the float and re-flowed down its right side.
</div>

<p>As stated in <a href="#collapsing-margins">“Collapsing margins,”
</a> the margins of floating boxes never <em>collapse</em> with
margins of adjacent boxes. Thus, in the previous example, vertical
margins do not collapse between the P box and the floated IMG box.

<p>The contents of floats are stacked as if floats generated new
stacking contexts, except that any elements that actually create new
stacking contexts take part in the float's parent's stacking context. 
A float can overlap other boxes in the normal flow (e.g., when a
normal flow box next to a float has negative margins). When this
happens, floats are rendered in front of non-positioned in-flow
blocks, but behind in-flow inlines.

<div class=example>
<p>Here is another illustration, showing what happens when a float
overlaps borders of elements in the normal flow.

<div class=figure>
  <p><img src="float2p.png" alt="Image showing a floating image
  that overlaps the borders of two paragraphs: the borders are
  interrupted by the image.">

  <p class=caption>A floating image obscures borders of block boxes it
  overlaps.
</div>
</div>

<p>The following example illustrates the use of the 'clear' property
to prevent content from flowing next to a float.

<div class=example>
<p>Assuming a rule such as this:

<pre>
p { clear: left }
</pre>

<p>formatting might look like this:

<div class=figure>
  <p><img src="floatclear.png" alt="Image showing a floating
  image and the effect of 'clear: left' on the two paragraphs.">

  <p class=caption>Both paragraphs have set 'clear: left', which
  causes the second paragraph to be “pushed down” to a position
  below the float &ndash; <em>clearance</em> is added above its top margin
  to accomplish this (see the 'clear' property).
</div>
</div>


<h3>Rules for positioning floats</h3>

<p>Here are the precise rules that govern the positions of floats with
a <em>horizontal</em> containing block. References to other elements
in these rules refer only to other elements in the same <em>flow</em>
as the float's parent.

<ol>
<li>The left <span>margin edge</span> of a left-floating box may not
be to the left of the left edge of its <span>containing block</span>. 
An analogous rule holds for right-floating elements.

<!-- The A margin edge of box that floats to the A may not be to A of
the A edge of its containing block -->

<li>If the current box is left-floating, and there are any
left-floating boxes generated by elements earlier in the source
document, then for each such earlier box, either the left <span>margin
edge</span> of the current box must be to the right of the right
<span>margin edge</span> of the earlier box, or its top must be lower
than the bottom of the earlier box. Analogous rules hold for
right-floating boxes.

<li>The right <span>margin edge</span> of a left-floating box may not
be to the right of the left <span>margin edge</span> of any
right-floating box that is to the right of it. Analogous rules hold
for right-floating elements.

<li>A floating box's top <span>margin edge</span> may not be higher
than the top of its <span>containing block</span>. When the float
occurs between two collapsing margins, the float is positioned as if
it had an otherwise empty <span title="anonymous box">anonymous block
parent</span> taking part in the flow. The position of such a parent
is defined by <span title="collapsed through">the rules</span> in the
section on margin collapsing.

<li>The top <span>margin edge</span> of a floating box may not be
higher than the margin top of any <span>block-level</span> or
<span>floated</span> box generated by an element earlier in the source
document.

<li>The top <span>margin edge</span> of an element's floating box may
not be higher than the top of any <span>line-box</span> containing a
box generated by an element earlier in the source document.

<li>A left-floating box that has another left-floating box to its left
may not have its right margin edge to the right of its containing
block's right edge. (Loosely: a left float may not stick out at the
right edge, unless it is already as far to the left as possible.) An
analogous rule holds for right-floating elements.

<li>A floating box must be placed as high as possible.

<li>A left-floating box must be put as far to the left as possible, a
right-floating box as far to the right as possible. A higher position
is preferred over one that is further to the left/right.
</ol>

<div class=example>
<p>This HTML fragment results in the b floating to the right.

<pre>&lt;P>a&lt;SPAN style="float: right">b&lt;/SPAN>&lt;/P></pre>

<p>If the P element's width is enough, the a and the b will be side by
side. It might look like this:

<div class=figure>
<p><img src="float-right.png"
alt="An a at the left side of a box and a b at the right side">
</div>
</div>


<p>The rules for a float with a containing block with
'writing-mode: rl' are exactly the same after replacing left with
top, right with bottom, top with right, bottom with left and adjusting
the text accordingly. Here they are:

<p class=issue>[Still some words like lower and higher to replace...]

<ol>
<li>The top <span>margin edge</span> of a top-floating box may not be
above the top edge of its <span>containing block</span>. An analogous
rule holds for bottom-floating elements.

<li>If the current box is top-floating, and there are any top-floating
boxes generated by elements earlier in the source document, then for
each such earlier box, either the top <span>margin edge</span> of the
current box must be below the bottom <span>margin edge</span> of the
earlier box, or its right must be to the left of the left margin edge
of the earlier box. Analogous rules hold for bottom-floating boxes.

<li>The bottom <span>margin edge</span> of a top-floating box may not
be below the top <span>margin edge</span> of any
bottom-floating box that is below it. Analogous rules hold
for bottom-floating elements.

<li>A floating box's right <span>margin edge</span> may not be to the
right of the right edge of its <span>containing block</span>. When the
float occurs between two collapsing margins, the float is positioned
as if it had an otherwise empty <span title="anonymous box">anonymous
block parent</span> taking part in the flow. The position of such a
parent is defined by <span title="collapsed through">the rules</span>
in the section on margin collapsing.

<li>The right <span>margin edge</span> of a floating box may not be to
the right of the right margin edge of any <span>block-level</span> or
<span>floated</span> box generated by an element earlier in the source
document.

<li>The right <span>margin edge</span> of an element's floating box
may not be to the right of the right edge of any <span>line-box</span>
containing a box generated by an element earlier in the source
document.

<li>A top-floating box that has another top-floating box above it
may not have its bottom margin edge below its containing
block's bottom edge. (Loosely: a top float may not stick out at the
bottom edge, unless it is already as far to the top as possible.) An
analogous rule holds for bottom-floating elements.

<li>A floating box must be placed as far to the right as possible.

<li>A top-floating box must be put as far to the top as possible, a
bottom-floating box as far to the bottom as possible. A position
further to the right is preferred over one that is further to the
top/bottom.
</ol>

<p>The rules for a float with a containing block with
'writing-mode: lr' are exactly the same after replacing left with
top, right with bottom, top with left and bottom with right. They are
given here for completeness:

<p class=issue>[...]


<p class=note>Note that a box with a value of 'float' other than ''none''
is a <em>flow root.</em>

<p>The border box of a table, a <span>block-level</span> replaced
element, or an element in the normal flow that is a <em>flow root</em>
(such as an element with 'overflow' other than ''visible'') must not
overlap any floats in the same flow as the element itself. If
necessary, implementations should clear the said element by placing it
below any preceding floats, but may place it adjacent to such floats
if there is sufficient space, <span class=issue>by increasing one
margin and decreasing the opposite margin. (“Sufficient space” means
that the opposite margin does not become negative.)</span>


<h2>The clear property</h2>

<table class=propdef>
  <tr><th>Name: <td><dfn>clear</dfn>
  <tr><th>Value: <td>none | left | right | both
  <tr><th>Initial: <td>none 
  <tr><th>Applies to: <td><span>block-level</span> elements 
  <tr><th>Inherited: <td>no 
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A 
  <tr><th>Media: <td>visual 
  <tr><th>Computed value: <td>as specified
  <tr><th>Canonical order: <td>N/A
</table>

<p class=issue>[To do: copy from CSS2 [[!CSS21]] and generalize to
vertical text, define <dfn>clearance.</dfn>]


<h2>The clear-after property</h2>

<table class="propdef">
  <tbody>
    <tr>
      <td>Name:
      <td><dfn>clear-after</dfn>
    
    <tr valign="baseline">
      <td>Value:
      <td>none | left | right | top | bottom | inside | outside | start | end
        | both | descendants
    
    <tr valign="baseline">
      <td>Initial:
      <td>none
    
    <tr valign="baseline">
      <td>Applies to:
      <td>block-level elements
    
    <tr valign="baseline">
      <td>Inherited:
      <td>no
    
    <tr>
      <td>Animatable:
      <td>no

    <tr valign="baseline">
      <td>Percentages:
      <td>N/A
    
    <tr valign="baseline">
      <td>Media:
      <td>visual
    
    <tr>
      <td>Computed value:
      <td>specified value

    <tr>
      <th>Canonical order:
      <td>N/A
  </tbody>
</table>

<p>It is sometimes useful to make sure that the bottom border of a
block-level element goes below floating elements. The 'clear-after'
property increases the element's padding as needed. More precisely: If
the element has a <span>block-end</span> padding or <span>block-end</span>
border, and there are any floats on the indicated side(s) in the
current <em>flow</em> up to and including the end of this element,
then find the one whose <em title="C edge">C</em> <em>margin edge</em>
is furthest away from the <em>block-start</em> <em>content edge</em> of the
<em>containing block.</em> If that C margin edge is further from the
containing block's block-start than the element's block-end content edge is, then
increase the element's block-end padding by the difference.

<div class="figure">
  <p><img src="clear-after.png" alt=" ">

  <p class="caption">The effect of 'clear-after: left' on a paragraph
  next to a floating image: the bottom padding of the paragraph is
  stretched, so that the original padding and the border go below the
  float.
</div>

<p class=note>Note: Since a floating element is a <em>flow root,</em>
setting 'clear-after' on such an element only
takes into account any descendant floats in the flow established by the
element itself.

<div class=example>
<p>These four images illustrate the effect of 'clear-after' on
elements with and without padding or border. They show two documents,
both have two paragraphs and the top paragraph contains a floating
image. In the document on the left, the first paragraph does not have
any bottom padding or border. In the document on the right it
does. The top row shows the layout without any 'clear-after', the
bottom row shows the effect of setting 'clear-after: left' on the
first paragraph.

<table class=xequiv-table>
 <thead>
  <tr>
   <th>'clear-after'
   <th>Without padding or border
   <th>With padding and border
 <tbody>
  <tr>
   <th>
    ''none''
   <td>
    <div class=figure>
    <p><img src="clear-after1.png" alt=""><p class=caption>The text of
    the second paragraph wraps around the floating image that started
    in the first paragraph.
    </div>
   <td>
    <div class=figure>
    <p><img src="clear-after2.png" alt=""><p class=caption>The
    floating image that starts in the first paragraph overlaps the
    bottom border of that paragraph. The text of second paragraph
    wraps around the image as well.
    </div>
  <tr>
   <th>
    ''left''
   <td>
    <div class=figure>
    <p><img src="clear-after1.png" alt=""><p class=caption>As the
    first paragraph has no padding that can be stretched or border
    that can be moved, the 'clear-after' has no effect on it and the
    layout is exactly the same as in the first image.
    </div>
   <td>
    <div class=figure>
    <p><img src="clear-after3.png" alt=""><p class=caption>The effect
    of 'clear-after' on the first paragraph is to increase the bottom
    padding so that the bottom border is now below the floating
    image. The second paragraph thus starts lower as well and doesn't
    have to wrap around the image.
    </div>
</table>
</div>

<p>The value of the property determines which kinds of floats are taken into
account:
<dl>
  <dt><dfn title="none!!value of 'clear-after'">none</dfn>
    <dd>No effect.
  <dt>left, top
    <dd>Only left and top floating elements are considered.
  <dt>right, bottom
    <dd>Only right and bottom floating elements are considered,
  <dt>inside
    <dd>If the bottom of the element occurs on a right-hand page, only left
      floating elements are considered. On a left-hand page, only right
      floating elements. On media that are not paged, 'inside' means the same
      as 'left'.
  <dt>outside
    <dd>Analogous
  <dt>start
    <dd>If the 'direction' of the element is
      'ltr', same as 'left', otherwise same as 'right'.
  <dt>end
    <dd>If the 'direction' of the element is
      'ltr', same as 'right', otherwise same as 'left'.
  <dt><dfn title="both!!value of 'clear-after'">both</dfn>
    <dd>Both left/top and right/bottom floats are considered.
  <dt>descendants
    <dd>All floats in the element's flow that are descendants of the
    element are considered, but not any other floats.
</dl>

<p class=issue>Use only two values: height-includes-floats and
height-does-not-include floats? [DavidB 2004-02-29]

<div class=issue>
<p>Instead of a new property 'clear-after', another idea is to add one or
more values to 'clear'. If 'clear' is turned into a set, instead of a single
value, one could add the value 'after' (clears both left and right floats) or
several values like 'left-after' and 'right-after':

<table class="propdef-extra">
  <tbody>
    <tr>
      <td>Name:
      <td>clear
    
    <tr valign="baseline">
      <td>Value:
      <td>none | [ left | right | top | bottom | inside | outside | start |
        end | both | after]+
    
    <tr valign="baseline">
      <td>Initial:
      <td>none
    
    <tr valign="baseline">
      <td>Applies to:
      <td>block-level elements
    
    <tr valign="baseline">
      <td>Inherited:
      <td>no
    
    <tr>
      <td>Animatable:
      <td>no
    
    <tr valign="baseline">
      <td>Percentages:
      <td>N/A
    
    <tr valign="baseline">
      <td>Media:
      <td>visual
    
    <tr>
      <td>Computed value:
      <td>specified value

    <tr>
      <th>Canonical order:
      <td>order of keywords as in grammar
  </tbody>
</table>

<p>The following rule would ensure that a SECTION starts below all preceding
floats and doesn't end until after all floats it contains:
<pre>section {clear: left right after}</pre>
</div>

<p class=issue>Daniel Beardsmore <a
href="http://lists.w3.org/Archives/Public/www-style/2007Feb/0120.html">
proposed</a> a property 'underhang-limit: &lt;count of full lines>' to
protect against the case that the last line of a paragraph (or the
last few lines) is shown under a float. In that case it looks better
to indent that line like the other lines of the paragraph. The default
is '1', i.e., no protection.


<h2>Overflow</h2>

<!-- As per 2009-08-12 telcon, define more precisely what causes
overflow and what doesn't. E.g., exclude shadows and anti-aliasing
from causing overflow, but relatively and absolutely positioned
descendants do cause overflow. -->

<p>When some content of an element is placed outside the element's
content box, the element is said to overflow. This module allows
overflow to be clipped, other modules may add other treatments, e.g.,
scale it down or to scroll it (“marquee,” see [[CSS3-MARQUEE]]).

<h3 id=overflow>The overflow, overflow-x and overflow-y properties</h3>

<p class=issue>In the preceding sections, several things (such as flow
roots) depend on the value of 'overflow'. We probably need to rewrite
them in terms of “overflow-x and/or -y” or similar.

<table class=propdef>
  <tr><th>Name: <td><dfn>overflow-x</dfn>, <dfn>overflow-y</dfn>,
  <tr><th>Value: <td>visible | hidden | scroll | auto | no-display | no-content
  <tr><th>Initial: <td>visible
  <tr><th>Applies to: <td>non-replaced <em>block-level</em> elements
    and non-replaced ''inline-block'' elements
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A
  <tr><th>Media: <td>visual
  <tr><th>Computed value:<td>as specified, except 'visible', see text
  <tr><th>Canonical order: <td>N/A
</table>

<table class=propdef>
  <tr><th>Name: <td><dfn>overflow</dfn>
  <tr><th>Value: <td>[ visible | hidden | scroll | auto | no-display |
    no-content ]{1,2}
  <tr><th>Initial: <td>see individual properties
  <tr><th>Applies to: <td>non-replaced <em>block-level</em> elements
    and non-replaced ''inline-block'' elements
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A
  <tr><th>Media: <td>visual
  <tr><th>Computed value:<td>as specified, except 'visible', see text
  <tr><th>Canonical order: <td>N/A
</table>

<p>These properties specify whether content is clipped when it
overflows the element's <em>content area.</em> It affects the clipping
of all of the element's content except any descendant elements (and
their respective content and descendants) whose containing block is
the viewport or an ancestor of the element. 'Overflow-x' determines
clipping at the left and right edges, 'overflow-y' at the top and
bottom edges.

<p>'Overflow' is a shorthand. If it has one keyword, it sets both
'overflow-x' and 'overflow-y' to that keyword; if it has two, it sets
'overflow-x' to the first and 'overflow-y' to the second. Keywords
have the following meanings:

<dl>
  <dt>visible

    <dd>This value indicates that content is not clipped, i.e., it may
    be rendered outside the content box.

  <dt>hidden

    <dd>This value indicates that the content is clipped and that no
    <em>scrolling mechanism</em> should be provided to view the
    content outside the clipping region.

  <dt>scroll

    <dd>This value indicates that the content is clipped and that if
    the user agent uses a <em>scrolling mechanism</em> that is visible
    on the screen (such as a scroll bar or a panner), that mechanism
    should be displayed for a box whether or not any of its content is
    clipped. This avoids any problem with scrollbars appearing and
    disappearing in a dynamic environment. When this value is
    specified and the target medium is ''print'', overflowing content
    may be printed.

  <dt>auto

    <dd>The behavior of the ''auto'' value is UA-dependent, but should
    cause a <em>scrolling mechanism</em> to be provided for
    overflowing boxes.

  <dt><dfn>no-display</dfn>

    <dd class=issue>When the content doesn't fit in the content box,
    the whole box is removed, as if 'display: none' were specified. 
    [This idea is due to Till Halbach &lt;tillh@opera.com&gt;, July
    21, 2005]

  <dt><dfn>no-content</dfn>

    <dd class=issue>When the content doesn't fit in the content box,
    the whole content is hidden, as if 'visibility: hidden' were
    specified. [This idea is due to Till Halbach
    &lt;tillh@opera.com&gt;, July 21, 2005]
</dl>

<p>Even if 'overflow' is set to ''visible'', content may be clipped to
a UA's document window by the native operating environment.

<p>UAs must apply the 'overflow' property set on the root element to
the viewport. HTML UAs must instead apply the 'overflow' property from
the BODY element to the viewport, if the value on the HTML element is
''visible''. The ''visible'' value when used for the viewport must be
interpreted as ''auto''. The element from which the value is
propagated must have a used value for 'overflow' of ''visible''.

<p class=issue>The para above is from CSS 2.1. Need to check if the
introduction of overflow-x/y changes anything.

<p>In the case of a scrollbar being placed on an edge of the element's
box, it should be inserted between the inner border edge and the outer
padding edge. The space taken up by the scrollbars affects the
computation of the dimensions in the rendering model.

<p>A UA may use multiple scrolling mechanisms at the same time. E.g.,
if content overflows both to the right and to the bottom, it may use a
marquee effect for the overflow to the right and a scrollbar for the
overflow to the bottom.

<p class=note>Note that a box with 'overflow' other than ''visible''
is a <em>flow root.</em>

<div class=example>
<p>Consider the following example of a block quotation
(&lt;blockquote>) that is too big for its containing block
(established by a &lt;div>). Here is the source:

<pre>
&lt;div>
&lt;blockquote>
&lt;p>I didn't like the play, but then I saw
it under adverse conditions - the curtain was up.&lt;/p>
&lt;cite>- Groucho Marx&lt;/cite>
&lt;/blockquote>
&lt;/div>
</pre>

<p>Here is the style sheet controlling the sizes and style of the
generated boxes:

<pre>
div { width : 100px; height: 100px;
      border: thin solid red;
      }

blockquote   { width : 125px; height : 100px;
      margin-top: 50px; margin-left: 50px; 
      border: thin dashed black
      }

cite { display: block;
       text-align : right; 
       border: none
       }
</pre>

<p>The initial value of 'overflow' is ''visible'', so the
&lt;blockquote> would be formatted without clipping, something like
this:

<div class=figure>
  <p><img src="overflow1" alt="[image: Rendered overflow]">
  <p class=caption>Possible rendering with 'overflow: visible'
</div>

<p>Setting 'overflow' to ''hidden'' for the &lt;div>, on the other
hand, causes the &lt;blockquote> to be clipped by the containing
block:

<div class=figure>
  <p><img src="overflow2" alt="[image: Rendered overflow]">
  <p class=caption>Possible rendering with 'overflow: hidden'
</div>

<p>A value of ''scroll'' would tell UAs that support a visible
scrolling mechanism to display one so that users could access the
clipped content.
</div>

<div class=example>
<p>Consider this case where an absolutely positioned element is mixed
with an overflow parent. Style sheet:

<pre>
container { position: relative; border: solid; }
scroller { overflow: scroll; height: 5em; margin: 5em; }
satellite { position: absolute; top: 0; }
body { height: 10em; }
</pre>

<p>Document fragment: 

<pre>
&lt;container>
 &lt;scroller>
  &lt;satellite/>
  &lt;body/>
 &lt;/scroller>
&lt;/container>
</pre>

<p>In this example, the “scroller” element will not scroll the
“satellite” element, because the latter's containing block is
outside the element whose overflow is being clipped and scrolled.
</div>

<p id=collapse-scroll>The combination of collapsing margins,
'max-height' and ''overflow: auto'' can lead to subtle differences in
implementations, unless special care is taken. A UA should assume that
an element can be rendered <em>without</em> a scrolling mechanism
first, perform all the collapsing of margins, and check that the
content height is indeed less than the 'max-height'. If it is not, the
process is repeated under the assumption that a scrolling mechanism
<em>is</em> needed.

<div class="example">
<p>In the following document fragment, the outer DIV has ''height:
auto'', but ''max-height: 5em''. The inner DIV has large margins and
would normally just fit:

<pre>
...
    #d1 { overflow: auto; max-height: 5em }
    #d2 { margin: 2em; line-height: 1 }
...
&lt;div id=d1&gt;
  &lt;div id=d2&gt;
    This DIV has big margins.
  &lt;/DIV&gt;
&lt;/DIV&gt;
</pre>

<p>If we assume that d1 needs scroll bars, then the height of d1,
including the single line of text and twice 2em of margins, adds
up to 5em plus a scrollbar. Since that is greater than 5em, the
maximum allowed height, it seems we made the right assumption and d1
indeed needs scrollbars.

<p>However, we should have started by assuming that no scrollbars are
needed. In that case the content height of d1 is exactly the maximum
height of 5em, proving that the assumption was correct and d1 indeed
should not have scrollbars.
</div>

<p>The computed values of 'overflow-x' and 'overflow-y' are the same
as their specified values, except that some combinations with
'visible' are not possible: if one is specified as 'visible' and the
other is 'scroll' or 'auto', then 'visible' is set to 'auto'. <span
class=issue>The computed value of 'overflow' is equal to the
computed value of 'overflow-x' if 'overflow-y' is the same; otherwise
it is the pair of computed values of 'overflow-x' and
'overflow-y'.</span>

<p>The <dfn>scrolling mechanism</dfn> depends on the UA. The most
common mechanism is a scrollbar, but panners, hand cursors, page
flickers, etc. are also possible. A value of 'scroll' would tell UAs
that support a visible scrolling mechanism to display one so that
users can access the clipped content. The 'overflow-style' property
lets an author specify one or more preferred scrolling mechanism.

<p class=note>Note that 'overflow-x' and 'overflow-y' did not exist in
CSS2.

<p class=note>Note that 'text-overflow' (see
[[!CSS3TEXT]]) can be used to give a visual indication where text has been
clipped.


<h2>The visibility property</h2>

<table class=propdef>
  <tr><th>Name: <td><dfn>visibility</dfn>
  <tr><th>Value: <td>visible | hidden | collapse
  <tr><th>Initial: <td> visible
  <tr><th>Applies to: <td>all elements
  <tr><th>Inherited: <td>yes
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>as specified
  <tr><th>Canonical order: <td>N/A
</table>

<p>This property specifies whether the boxes generated by an element
are rendered. Invisible boxes still affect layout (set the 'display'
property to ''none'' to suppress box generation altogether). Values
have the following meanings:

<dl>
  <dt>visible <dd>The generated box is visible.

  <dt>hidden <dd>The generated box is invisible (fully transparent,
  nothing is drawn), but still affects layout. Furthermore,
  descendants of the element will be visible if they have 'visibility:
  visible'.

  <dt>collapse <dd>See the Tables module [[CSS3TBL]]. If used on
  elements other than rows, row groups, columns, or column groups,
  ''collapse'' has the same meaning as ''hidden''.
</dl>


<h2>The alignment property</h2>

<table class=propdef>
  <tr><th>Name: <td><dfn>alignment</dfn>
  <tr><th>Value: <td>top | right | bottom | left | center
  <tr><th>Initial: <td>see text
  <tr><th>Applies to: <td><span>block-level</span> elements
  <tr><th>Inherited: <td>no
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>specified value
  <tr><th>Canonical order: <td>N/A
</table>

<p class=issue>For consistency with 'text-align', maybe this should be
called 'block-align'.

<p>This property influences how a block in the normal flow is aligned
in its parent in the inline progression direction. It affects the used
values of 'margin-left' and 'margin-right' (for <em>horizontal</em>
blocks) or 'margin-top' and 'margin-bottom' (for <em>vertical</em>
blocks), as defined in <a href="#Calculating">&ldquo;Calculating
widths, heights and margins.&rdquo;</a>

<p>The initial value depends on both 'writing-mode' and 'direction', as
follows:

<table class=equiv-table>
<tr><th>    <th>tb    <th>rl     <th>lr
<tr><th>ltr <td>left  <td>top    <td>top
<tr><th>rtl <td>right <td>bottom <td>bottom
</table>

<p class=note>Note that this property doesn't exist in level 2.

<div class=example>
<p>The 'alignment' property in combination with the ''fit-content''
value of 'width' can be used to make borders that enclose just the
content of a heading, without the need for an additional element:

<pre>
h2 {
  margin-top: 1em;
  margin-bottom: 1em;
  border: solid;
  padding: 0.5em;
  alignment: center;
  width: fit-content}
</pre>

<pre>
<b>&lt;p></b>Lorem ipsum dolor sit amet...
<b>&lt;h2></b>A section heading<b>&lt;/h2></b>
<b>&lt;p></b>Lorem ipsum dolor sit amet...
<b>&lt;h2></b>Another section heading<b>&lt;/h2></b>
<b>&lt;p></b>Lorem ipsum dolor sit amet...
</pre>

<p>See the figure below for a possible rendering.
</div>

<div class=figure>
  <img src="alignment" alt="Image: centered headings with border tightly
  around the text">

  <p class=caption>A possible rendering of the example.
</div>


<h2>The child-align property</h2>

<p class=issue>Other names: block-align (but note that it influences
the children of the block, not the block itself), block-vertical-align
(but note that it really means horizontal if the block's
'writing-mode' is ''lr'' or ''rl''), and align-content (current name
in [[CSS3-ALIGN]]).

<table class=propdef>
  <tr><th>Name: <td><dfn>child-align</dfn>
  <tr><th>Value: <td>top | middle | bottom | left | right | auto
  <tr><th>Initial: <td>auto
  <tr><th>Applies to: <td>block-level elements, table cells and inline blocks
  <tr><th>Inherited: <td>yes
  <tr><th>Animatable: <td>no
  <tr><th>Percentages: <td>N/A
  <tr><th>Media: <td>visual
  <tr><th>Computed value: <td>the initial value or as specified
  <tr><th>Canonical order: <td>N/A
</table>

<p>This property describes how block-level content of a block is
aligned vertically, or more precisely: in the block progression
direction. Values have the following meanings:

<dl>
  <dt>top, bottom, left, right <dd>Child blocks are aligned in the
  current block depending on the 'child-align' and 'writing-mode'
  as follows:

  <table class=equiv-table>
  <tr><th>   <th>top   <th>bottom <th>left   <th>right
  <tr><th>tb <td>top   <td>bottom <td>top    <td>top
  <tr><th>rl <td>right <td>right  <td>left   <td>right
  <tr><th>lr <td>left  <td>left   <td>left   <td>right
  </table>

  <dt>middle <dd>Child blocks are centered in the block progression
  direction.

  <dt>auto <dd>Child blocks are aligned according to
  'writing-mode': at the top if ''tb'', at the right if ''rl''
  and at the left if ''lr''.
</dl>

<p>An element with 'child-align' values other than ''auto'' is
a <em>flow root.</em> Content of such a block is formatted as follows:

<ol>
  <li>Content is laid out as a regular sequence of blocks.

  <li class=issue>To be discussed: If the smallest rectangle that
  encloses all margin boxes of the children (excluding absolutely
  positioned children and counting relatively positioned children as
  if they had zero offset) is bigger in the block progression
  direction than the content box of the current element, then the
  content is placed in that content box as if 'child-align' were
  ''top''.

  <li>The content is shifted such that the rectangle that
  encloses all margin boxes of the children (excluding absolutely
  positioned children and counting relatively positioned children as
  if they had zero offset) touches an edge of the content box. Which
  edge of the rectangle and which edge of the content box is
  determined by the table above. But if 'child-align' is 'middle', the
  rectangle is instead centered in the content box.
</ol>

<div class=note>
  <p>Note that the effect of 'child-align' can also be achieved with
  template layout [[CSS3LAYOUT]]. E.g.,

  <pre>div {child-align: bottom}</pre>

  <p>is the same as

  <pre>div {grid: "a"};
div::slot(a) {vertical-align: bottom}</pre>

  <p>except that the latter forces the DIV to be a block, while the
  former leaves the 'display' value of the DIV unchanged (but has no
  effect unless the DIV is block-level).
</div>

<p>When this property applies and is not ''auto'', then
'vertical-align' does not apply. E.g., the placement of the content of
a table cell is determined by 'vertical-align' only if 'child-align'
is ''auto'', otherwise 'child-align' determines the placement.

<p class=issue>Or, alternatively, 'child-align' doesn't apply to
elements that 'vertical-align' applies to, i.e., only to ''block'',
''list-item'', ''inline-block'' and ''run-in'' (under circumstances).

<p>In paged media and in multi-column layout, page breaks and column
breaks are calculated first, then the content is vertically aligned
according to the property within each portion of the parent block.


<h2>Stacking contexts</h2>

<p>This section defines the painting order in more detail than
described in the rest of the specification.

<h3>Definitions</h3>

<dl>
  <dt>Tree Order <dd>Preorder depth-first traversal of the
  <em>rendering</em> tree, in logical (not visual) order for
  bidirectional content, after taking into account properties that
  move boxes around such as the 'run-in' value of 'display'.

  <dt>Element <dd>In this description, “element” refers to actual
  elements, pseudo-elements, and anonymous boxes. Pseudo-elements and
  anonymous boxes are treated as descendants in the appropriate
  places. For example, an outside list marker comes before an
  adjoining '::before' box in the line box, which comes before the
  content of the box, and so forth.
</dl>

<h3>Painting order</h3>

    <p>The bottom of the stack is the furthest from the user, the top
    of the stack is the nearest to the user:

    <div class=figure>
      <p><img src="stack.png" alt="All layers are between the canvas
      and the user">

      <p class=caption>Schematic diagram of a stacking context with
      four layers.
    </div>

<!--
<pre>
	     |	   |	     |	  |
	     |		|    |	  |	&#8678; &#9787;
	     |		|	  |	user
z-index:  canvas  -1	0    1	  2
</pre>
-->

    <p>The stacking context background and most negative positioned
    stacking contexts are at the bottom of the stack, while the most
    positive positioned stacking contexts are at the top of the stack.

    <p>The canvas is transparent if contained within another, and
    given a UA-defined color if it is not. It is infinite in extent
    and contains the root element. Initially, the viewport is anchored
    with its top left corner at the canvas origin.

    <p>The stacking order for an element generating a stacking context
    (see the 'z-index' property) is:

    <ol class=stack>
      <li>
	<p>If the element is a root element:
	<ol>
	  <li>background color of element over the entire canvas.

	  <li>background image of element, over the entire canvas,
	  anchored at the origin that would be used if it was painted
	  for the root element.
	</ol>

      <li>
	<p>If the element is a block, list-item, or other block
	equivalent:
	<ol>
	  <li>background color of element unless it is the root
	  element.

	  <li>background image of element unless it is the root
	  element.

	  <li>border of element.
	</ol>

	<p>Otherwise, if the element is a block level table:
	<ol>
	  <li>table backgrounds (color then image) unless it is the
	  root element.
	  <li>column group backgrounds (color then image).
	  <li>column backgrounds (color then image).
	  <li>row group backgrounds (color then image).
	  <li>row backgrounds (color then image).
	  <li>cell backgrounds (color then image).
	  <li>all table borders (in tree order for separated borders).
	</ol>

      <li>
	<p>Stacking contexts formed by positioned descendants with
	negative z-indices (excluding 0) in z-index order (most
	negative first) then tree order.

      <li>
	<p>For all its in-flow, non-positioned,
	<span>block-level</span> descendants in tree order: If the
	element is a block,
	list-item, or other block equivalent:
	<ol>
	  <li>background color of element.
	  <li>background image of element.
	  <li>border of element.
	</ol>

	<p>Otherwise, the element is a table:
	<ol>
	  <li>table backgrounds (color then image).
	  <li>column group backgrounds (color then image).
	  <li>column backgrounds (color then image).
	  <li>row group backgrounds (color then image).
	  <li>row backgrounds (color then image).
	  <li>cell backgrounds (color then image).
	  <li>all table borders (in tree order for separated borders).
	</ol>

      <li>
	<p>All non-positioned floating descendants, in tree order. For
	each one of these, treat the element as if it created a new
	stacking context, but any positioned descendants and
	descendants which actually create a new stacking context
	should be considered part of the parent stacking context, not
	this new one.

      <li>
	<p>If the element is an inline element that generates a
	stacking context, then:
	<ol>
	  <li>
	    <p>For each line box that the element is in:
	    <ol>
	      <li>Jump to <a href="#each-box">7.2.1</a> for the
	      box(es) of the element in that line box (in tree order).
	    </ol>
	</ol>

      <li>
	<p>Otherwise: first for the element, then for all its in-flow,
	non-positioned, <span>block-level</span> descendants in tree
	order:
	<ol>
	  <li>
	    <p>If the element is a <span>block-level</span> replaced
	    element, then: the replaced content, atomically.

	  <li>
	    <p>Otherwise, for each line box of that element:
	    <ol>
	      <li id=each-box>
		<p>For each box that is a child of that element, in
		that line box, in tree order:
		<ol>
		  <li>
		    <p>background color of element.
		  <li>
		    <p>background image of element.
		  <li>
		    <p>border of element.
		  <li>
		    <p>For inline elements:
		    <ol>
		      <li>
			<p>For all the element's in-flow,
			non-positioned, inline-level children that are
			in this line box, and all runs of text inside
			the element that is on this line box, in tree
			order:
			<ol>
			  <li>
			    <p>If this is a run of text, then:
			    <ol>
			      <li>any underlining affecting the text
			      of the element, in tree order of the
			      elements applying the underlining (such
			      that the deepest element's underlining,
			      if any, is painted topmost and the root
			      element's underlining, if any, is drawn
			      bottommost).

			      <li>any overlining affecting the text of
			      the element, in tree order of the
			      elements applying the overlining (such
			      that the deepest element's overlining,
			      if any, is painted topmost and the root
			      element's overlining, if any, is drawn
			      bottommost).

			      <li>the text.

			      <li>any line-through affecting the text
			      of the element, in tree order of the
			      elements applying the line-through (such
			      that the deepest element's line-through,
			      if any, is painted topmost and the root
			      element's line-through, if any, is drawn
			      bottommost).
			    </ol>

			  <li>
			    <p>Otherwise, jump to <a
			    href="#each-box">7.2.1</a> for that
			    element.
			</ol>
		    </ol>

		    <p>For inline-block and inline-table elements:
		    <ol>
		      <li>For each one of these, treat the element as
		      if it created a new stacking context, but any
		      positioned descendants and descendants which
		      actually create a new stacking context should be
		      considered part of the parent stacking context,
		      not this new one.
		    </ol>

		    <p>For inline-level replaced elements:
		    <ol>
		      <li>the replaced content, atomically.
		    </ol>
		</ol>

		<p class=note>Some of the boxes may have been
		generated by line splitting or the Unicode
		bidirectional algorithm.

	      <li>
		<p>Optionally, the outline of the element (see <a
		href="#outlines">10 below</a>).
	    </ol>

	  <li>
	    <p>Optionally, if the element is <span>block-level,</span>
	    the outline
	    of the element (see <a href="#outlines">10 below</a>).
	</ol>

      <li>
	<p>All positioned descendants with 'z-index: auto' or
	'z-index: 0', in tree order. For those with 'z-index: auto',
	treat the element as if it created a new stacking context, but
	any positioned descendants and descendants which actually
	create a new stacking context should be considered part of the
	parent stacking context, not this new one. For those with
	'z-index: 0', treat the stacking context generated atomically.

      <li>
	<p>Stacking contexts formed by positioned descendants with
	z-indices greater than or equal to 1 in z-index order
	(smallest first) then tree order.

      <li id=outlines>
	<p>Finally, implementations that do not draw outlines in steps
	above must draw outlines from this stacking context at this
	stage. (It is recommended to draw outlines in this step and
	not in the steps above.)
    </ol>

    <h3>Notes</h3>

    <p>The background of the root element is only painted once, over
    the whole canvas.

    <p>While the backgrounds of bidirectional inlines are painted in
    tree order, they are positioned in visual order. Since the
    positioning of inline backgrounds is unspecified in CSS&nbsp;2.1,
    the exact result of these two requirements is UA-defined. CSS3 may
    define this in more detail. <span class=issue>[Replace 2.1 by 3. 
    Check if inline backgrounds are still undefined, otherwise say
    result is UA-dependent.]</span>


<h2>The 'float-displace' and 'indent-edge-reset' properties [alternative 1]</h2>

<p>The 'float-displace' property defines different ways in which text
can wrap around a float.

<p class=issue>Could this property be merged with 'wrap-flow' in
[[CSS3-EXCLUSIONS]]?

<h3>The 'float-displace' property</h3>

<table class="propdef">
  <tbody>
    <tr>
      <td><em>Name:</em>
      <td><dfn>float-displace</dfn>
    
    <tr>
      <td><em>Value:</em>
      <td>line | indent | block | block-within-page
    
    <tr>
      <td><em>Initial:</em>
      <td>line
    
    <tr>
      <td><em>Applies to:</em>
      <td>all block-level elements
    
    <tr>
      <td><em>Inherited:</em>
      <td>yes
    
    <tr>
      <td>Animatable:
      <td>no
    
    <tr>
      <td><em>Percentages:</em>
      <td>N/A
    
    <tr>
      <td><em>Media:</em>
      <td>visual
    
    <tr>
      <td><em>Computed value:</em>
      <td>Same as specified value
    
    <tr>
      <th>Canonical order:
      <td>N/A
  </tbody>
</table>

<p>This property determines the line wrapping policy in the presence of
floats. Values have the following meanings:
<dl>
  <dt>line
    <dd>Line boxes should be shortened and moved so as to avoid floats. The
      margin, border, padding and background of the element are not affected
      by floats. (This is the behavior as described in CSS2.) <span
      class=issue>[add description or image?]</span>
  <dt>indent
    <dd>The distance between the margin edge of the floats and the start of
      the line box is set to the distance between the active <em>reference
      indent edge</em> (see the 'indent-edge-reset' property) and the content
      edge of the block box. This ensures that relative indents are preserved
      in the presence of floats.

      <div class="figure">
      <p><img src="float-displace-indent.png"
      alt="Example of lines wrapping around a float individually.">
      <p class="caption">Example of 'float-displace: indent'. Note that the
      “bar” paragraph has the same indent (green arrow) next to the float as
      below it .
      </div>
    
  <dt><dfn title="block!!value of 'float-displace'">block</dfn>
    <dd><p>The containing block's width as used by the horizontal formatting
      model is reduced by the width of the floats intruding upon its content
      area (not taking into account floating descendants or floating elements
      that appear later in the document tree). The block is then flowed in
      this reduced containing block width.
      <p>If the effective containing block width is, by the algorithm given
      above, reduced to a value smaller than the sum of the margin-left,
      border-width-left, padding-left, width, padding-right,
      border-width-right, and margin-right values (treating any 'auto' values
      as zero) then the margin-top of the block is increased until the
      effective containing block width is no longer so constrained or until
      all floats have been cleared, whichever occurs first.

      <div class="figure">
      <p><img src="float-displace-block.png"
      alt="Example of blocks being made narrower because of floats">
      <p class="caption">Example of 'float-displace: block'
      </div>
    
  <dt>block-within-page
    <dd>As for the ''block'' value, but the determination of intrusions that
      adjust the width of the block is done separately on each page on which
      the block appears. Thus, the block may be narrowed on the first page
      due to one or more intrusions, but may expand (or contract) its width
      on subsequent pages with different intrusions. The computed value of
      the 'width' property for this case is...?
</dl>

<div class="example">
<p>A set of rules for HTML might look like this:
<pre>OL, UL, LI {float-displace: indent}
TABLE {float-displace: block}</pre>

<p>Lines in a list will get extra indentation when they are next to a float,
so you can still see that they are part of the list, and tables will be made
narrower as a whole.
</div>

<h3>The 'indent-edge-reset' property</h3>

<table class="propdef">
  <tbody>
    <tr>
      <td><em>Name:</em>
      <td><dfn>indent-edge-reset</dfn>
    
    <tr>
      <td><em>Value:</em>
      <td>none | margin-edge | border-edge | padding-edge | content-edge
    
    <tr>
      <td><em>Initial:</em>
      <td>none
    
    <tr>
      <td><em>Applies to:</em>
      <td>all elements with a block-level inner formatting context.
    
    <tr>
      <td><em>Inherited:</em>
      <td>no
    
    <tr>
      <td>Animatable:
      <td>yes
    
    <tr>
      <td><em>Percentages:</em>
      <td>n/a
    
    <tr>
      <td><em>Media:</em>
      <td>visual
    
    <tr>
      <td><em>Computed value:</em>
      <td>specified value

    <tr>
      <th>Canonical order:
      <td>N/A
  </tbody>
</table>

<p>This property determines which edge to use as the <dfn>reference indent
edge</dfn> when calculating the amount of indent to preserve when the value
of 'float-displace' is set to ''indent''.
<dl>
  <dt><dfn title="none!!value of 'indent-edge-reset'">none</dfn>
    <dd>This block does not introduce a new reference edge.
  <dt>margin-edge
  <dt>border-edge
  <dt>padding-edge
  <dt>content-edge
    <dd>A new reference indent edge is introduced by this block. Which edge
      is used as the reference indent edge is determined by which value is
      given.
</dl>

<p>The reference indent edge is the nearest ancestor in the same formatting
context which has a non-none value for 'indent-edge-reset'. If no ancestor in the formatting
context has a value specified for this property, then the content edge of the
root of the formatting context is used.


<h2 class=no-num>The ‘float-displace’ property [alternative 2]</h2>

<p class=issue>Alternative definition, that (1) avoids the need for
'indent-edge-reset' and (2) changes not just the line boxes, but also
the content edge, so that list markers stay close to the content:

<table class="propdef">
  <tbody>
    <tr>
      <td><em>Name:</em>
      <td><dfn>float-displace</dfn>
    <tr>
      <td><em>Value:</em>
      <td>line | indent | block | block-within-page
    <tr>
      <td><em>Initial:</em>
      <td>line
    <tr>
      <td><em>Applies to:</em>
      <td>all block-level elements
    <tr>
      <td><em>Inherited:</em>
      <td>yes
    <tr>
      <td>Animatable:
      <td>no
    <tr>
      <td><em>Percentages:</em>
      <td>N/A
    <tr>
      <td><em>Media:</em>
      <td>visual
    <tr>
      <td><em>Computed value:</em>
      <td>Same as specified value
    <tr>
      <th>Canonical order:
      <td>N/A
  </tbody>
</table>

<dl>
    <dt>line

      <dd><p>Line boxes are shortened so they don't overlap floats. 
      See <a href="#contour">below</a> for the details. The element's
      margin, border or padding are not influenced by the presence of
      floats. (This is the only behavior in CSS level 2.)

    <dt>indent

      <dd><p>Line boxes are first shortened as for ''line''. If the
      distance between the inline-start edge of the content box and the inline-start
      edge of the line box is then not zero, then that distance is
      further increased by the element's <em>relative indent</em>
      (defined below). Ditto for the inline-end edge. The element's margin,
      border or padding are not influenced by the presence of floats.

    <dt>block

      <dd><p>The margins of the element are increased (and the width thus
      reduced) by the amount necessary so that the border box of the
      element doesn't overlap any floats in the same flow that are
      created by elements earlier in the document; and then the
      margins are increased even more by the amount of the
      <em>relative indent</em> on the relevant side of the element. If
      that causes the element to have more overflow than it would have
      had with a value of ''line'', the element is moved down instead
      (by adding clearance) just enough that it doesn't have more
      overflow, or that its top border edge is just below the bottom
      margin edge of all floats.

      <p>Line boxes inside the element are shortened and/or moved as
      needed the same way as for ''line''.

      <p>Note that floats that are descendants of the element do not
      influence the element's margins, but they may influence the line
      boxes.

    <dt>block-within-page

      <dd><p>Like block, except that the parts of the element on different
      pages are treated as separate blocks for the purpose of this
      property and are only indented as necessary to avoid floats on
      the same page.
</dl>

<p class=note>Note that centered text ('text-align' is ''center'') is
centered relative to the content edges, not relative to the edges of
the line box.

<p class=note>Note also that ''block'' and ''block-within-page''
influence the position of the element's list marker (if any), because
list markers are positioned relative to the content edge. Indeed, this
may be the main reason for using 'float-displace': to move the list
markers from one side of the float (or on top of the float) to the
other side.

<p>A <span>line box</span> normally stretches from an
element's <span>content edge</span> to the opposite content edge,
unless it overflows (see [[!CSS3TEXT]]), but if the element's
'float-displace' is ''line'' or ''indent'' it may fall short of either
or both content edges. The following defines how line boxes are
shortened in the case of ''line'':

<p>For all elements <var>E</var>, and all floats <var>F</var> whose
parent is in the same <span>flow</span> as <var>E</var>, and all <span
title="line box">line boxes</span> <var>L</var> of <var>E</var>: if
<var>L</var> contains any inline boxes that are generated by elements
that come after <var>F</var> in the document, then <var>L</var> must
may not overlap the <em>exclusion zone</em> of <var>F</var>.

<p class=note>Note that a line box next to a float cannot overflow: if
an inline box is too wide for a shortened line box, the line box is
left empty and the inline box is put in the next line box in which it
fits, or the next one that is not shortened by floats. <span
class=issue>[Is this indeed correctly defined in
[[!CSS3TEXT]]?]</span>

<p class=note>Implementation note: Note that the height of a line box
depends on its content. It may be, e.g., that a line box next to a
float has enough room horizontally for three words, but adding the
third word would increase the height of the line box and make it
overlap the next float further down. In that case the third word
cannot be added to that line box and must be put in the next line box
(or even further down).

<p class=mtb>The <dfn>relative indent</dfn> on side <var>S</var> of an
element <var>E</var> is defined recursively as follows:

<ul>
      <li>If <var>E</var> has no parent, or the parent is not in the same
      flow, or the parent's 'float-displace' has a different value
      than <var>E's</var>, then the value is 0.

      <li>Otherwise, the value is the relative indent on side <var>S</var>
      of the parent, plus the computed values of the parent's margin,
      padding and border-width on side <var>S</var>.
</ul>

<p>How <em title="line box">line boxes</em> are constructed is
explained in the CSS Text Module [[!CSS3TEXT]]. The presence of a
float modifies that construction in two ways: the length of the line
box can become shorter (i.e., shorter than the distance between the
element's content edges) and, unlike a normal line box, such a shorter
line box may be empty. The following describes these effects in
detail.

<p>We consider construction of line boxes in <span>horizontal</span>
elements first. (Vertical elements are analogous and are defined
below.) Let <var>L</var> be a line box


<h2 class=no-num>The ‘float-displace’ property [alternative 3]</h2>

<p class=issue>Yet another alternative. This one adds a fixed indent
rather than one that depends on the context:

<table class="propdef">
  <tbody>
    <tr>
      <td><em>Name:</em>
      <td><dfn>float-displace</dfn>
    <tr>
      <td><em>Value:</em>
      <td>auto | &lt;length> &amp;&amp; [ block | block-within-page ]?
    <tr>
      <td><em>Initial:</em>
      <td>line
    <tr>
      <td><em>Applies to:</em>
      <td>all block-level elements
    <tr>
      <td><em>Inherited:</em>
      <td>no
    <tr>
      <td>Animatable:
      <td>no
    <tr>
      <td><em>Percentages:</em>
      <td>N/A
    <tr>
      <td><em>Media:</em>
      <td>visual
    <tr>
      <td><em>Computed value:</em>
      <td>Same as specified value
    <tr>
      <th>Canonical order:
      <td>N/A
  </tbody>
</table>

<dl>
    <dt>auto

      <dd><p>Line boxes are shortened and/or moved so they don't overlap
      floats. (This is the only behavior in CSS level 2.)

    <dt>&lt;length>

      <dd><p>Line boxes are shortened and/or moved as for ''auto'', except
      that the amount they are shortened by, if possible, is equal to
      the amount necessary to not overlap any float plus the given
      &lt;length>.

    <dt>block

      <dd><p>If the keyword ''block'' is present in addition to a
      &lt;length>, the margins of the element are increased (and the
      width thus reduced) by the amount necessary so that the border
      box of the element doesn't overlap any floats in the same flow
      that are created by elements earlier in the document; and then
      the margins are increased even more by the given &lt;length>. If
      that causes the element to have more overflow than it would have
      had with a value of ''auto'', the element is moved down instead
      (by adding clearance) just enough that it doesn't have more
      overflow, or that its top border edge is just below the bottom
      margin edge of all earlier floats in the same flow.

      <p>Line boxes inside the element are shortened and/or moved as
      needed the same was as for ''auto''.

      <p class=note>Note that floats that are descendants of the
      element do not influence the element's margins, but they may
      influence the line boxes.

    <dt>block-within-page

      <dd><p>Like block, except that the parts of the element on
      different pages are treated as separate blocks for the purpose
      of this property and are only indented as necessary to avoid
      floats on the same page.
</dl>

<p class=note>Note that all values, except ''auto'', also cause
centered lines to no longer be centered if they are next to a float.

<p class=note>Note also that ''block'' and ''block-within-page''
influence the position of the element's list marker (if any), because
list markers are positioned relative to the content edge. Indeed, this
may be the main reasons for using 'float-displace': to move the list
markers from one side of the float (or on top of the float) to the
other side.

<div class=example>
<p>Example: Assume that the floating image is tall than the paragraph
it is part of.

<pre>img {float: left}
ul {float-displace: 2em block}
li {margin-left: 2em}</pre>

<p>with document fragment

<pre>
&lt;p>
  &lt;img src=... alt=... style="float: left">
  Paragraph before the list.

&lt;ul>
  &lt;li>First item
  &lt;li>Second item
&lt;/ul>
</pre>

<p>Without the image, the rendering might look like this:

<pre>
Paragraph before the list.

  * First item
  * Second item
</pre>

<p>With the image, but without the rule for 'float-displace', the
output might look like this:

<pre>
+----+Paragraph before the list.
|\  /|
| */ |First item
| *\ |Second item
|/  \|
+----+
</pre>

<p>With the 'float-displace' rule, the UL is indented extra to
avoid the image, plus 2em more:

<pre>
+----+Paragraph before the list.
|\  /|
| \/ |  * First item
| /\ |  * Second item
|/  \|
+----+
</pre>
</div>


<h2>Conformance</h2>
<!--conformance-->


<h2>Acknowledgments</h2>

<p class=issue>To do…

<!--
<p>[acknowledgments. David Baron, Ian Hickson]

<p>David Baron discovered that the assumption about whether a scrolling
mechanism is needed can influence whether it is indeed needed or not. See the
<a href="#collapse-scroll">explanation</a> under <a href="#overflow">"The
overflow property"</a>.

<p>Many people on the www-style@w3.org mailing list provided valuable
reviews, corrections and proposals. Among them, Bj&ouml;rn H&ouml;hrmann deserves
special mention.

<p>[Comments:
<ul>
  <li><a
    href="http://lists.w3.org/Archives/Public/www-style/2001Jul/0167.html">Bj&ouml;rn
    H&ouml;hrmann</a>
  <li><a
    href="http://lists.w3.org/Archives/Public/www-style/2001Jul/0169.html">Jeffrey
    Yasskin</a>
  <li><a
    href="http://lists.w3.org/Archives/Public/www-style/2001Sep/0041.html">Valerie
    G. Sharp</a>
</ul>

<p>]
-->

<h2 class="no-num">References</h2>

<h3 class=no-num>Normative references</h3>
<!--normative-->

<h3 class=no-num>Informative references</h3>
<!--informative-->


<h2 class="no-num" id=index>Index</h2>
<!--index-->


<h2 class="no-num">Property index</h2>
<!--properties-->


<!-- Keep this comment at the end of the file
Local variables:
mode: html
sgml-minimize-attributes:t
End:
-->