block-layout.bs

    <!-- TODO: cross-references aren't automatically generated by
    Bikeshed. Is there a better way than to add <a> around every
    <span> and <em>?  -->

    <!-- TODO: bibliography still doesn't show the dated specs. -->

<pre class=metadata>
Title: CSS Basic Box Model Level 3
Shortname: css3-box
Level: none
Status: ED
Work Status: rewriting
Previous version: https://www.w3.org/TR/2018/WD-css3-box-20180731/
TR: https://www.w3.org/TR/css3-box/
ED: https://drafts.csswg.org/css-box-3/
Group: csswg
Editor: Bert Bos, W3C, mailto:bert@w3.org, w3cid 3343
Editor: Anton Prowse, Invited Expert, mailto:prowse@moonhenge.net, w3cid 48426
Markup Shorthands: markdown no, markup yes
Abstract:
 <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 &ldquo;flow,&rdquo; in which a
 series of boxes is laid out one after the other, and it defines 
 &ldquo;floating&rdquo; 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&nbsp;3, boxes may contain either horizontal or vertical text. 
 Different orientations can be mixed.

Status Text:
 <![CDATA[<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&nbsp;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&nbsp;2 specification [[!CSS21]]. But this is an early
 draft and any differences to level&nbsp;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>
 ]]>
</pre>
<pre class=link-defaults>
spec:css-display-3; type:value; for:display; text:block
spec:css-display-3; type:value; for:display; text:list-item
spec:css-display-3; type:value; for:display; text:table
</pre>

<style>
  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: */

  /* 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: 2;
      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: 3}
    #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>

<!--=================================================================-->

<!--
<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 <a>used value</a> and the
<a>computed value</a> of a property. Unless stated explicitly, the
short form &ldquo;value&rdquo; means the computed value.
-->

<!--=================================================================-->

<h2 id=dependencies>Dependencies on other modules</h2>

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

<p class=issue>To do&hellip;

<!--=================================================================-->

<h2 id=intro>Introduction &amp; definitions</h2>

<div class=issue id=center-text>
<p>How to center the text of a block element horizontally (more
precisely: in the inline direction) even if (part of) the block is
next to a float?
</div>

<div class=issue id=center-block>
<p>How to center a block horizontally in its CB if the block is wider
than the CB? (I.e., when 'margin: auto' doesn't work and the document
structure doesn't allow transforms or flexbox.)
</div>

<div class=issue id=distribute>
<p>How to center or distribute blocks vertically when flexbox doesn't
apply (e.g., because the blocks aren't siblings)?
</div>

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

<p class=note>Note: The model in this specification differs from the
model described in the CSS level&nbsp;2 specification [[!CSS21]], because
it is generalized to apply also to vertical text. A document using
only features from level&nbsp;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 boxes, whose size,
position, and stacking level on the <a>canvas</a> depend on their
properties. We say that an element <dfn title="generated
box">generates</dfn> one or more boxes.

<div class=issue id=box-tree>
<p>Define the box tree <!-- Is it a tree (possibly with cross-links)?
A graph? Purely geometrical? Or are boxes not linked to each other,
but only to elements or viewports? When we say box A contains box B,
does that mean B is geometrically within A, or just that B's
generating element is a descendant of A's generating element? Is there
only one kind of box or are there several (line box, block box, margin
box&hellip;)? E.g., if we talk about an &ldquo;inline box&rdquo;, is that a kind of box,
or only a shorthand for &ldquo;a box generated by an inline element&rdquo;? Are
letters (glyphs) boxes? Are words? Is the space between words a box or
a margin? Or does that depend on the white-space property? Is there an
order defined for boxes? E.g., can we talk about the &ldquo;first&rdquo; or the
&ldquo;next&rdquo; box? About the &ldquo;first box of a fragmentainer&rdquo;? The &ldquo;first box
of an element&rdquo;? Does bidi-reordering, flexbox reordering, run-in
reordering or absolute positioning change that order? -->
</div>

<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 <a
title="generated box">generated</a> directly by the element, or it
is an <a>anonymous box,</a> 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 title="induce">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 &ldquo;principal box&rdquo; anywhere?</span>

<div class=issue>
<p>Do boxes have properties? Or do they just have margins, borders,
padding, a size and some content (which may be text in a certain font
and a certain color, but without the box itself having a font or a
color property)?
</div>

<!--
<p class=note>Boxes are frequently referred to by their property
values. For example, a &ldquo;floated box&rdquo; is a box whose computed value of
'float' is not ''none'', and a &ldquo;positioned box&rdquo; is a box whose
computed value of 'position' is not ''static''. However, terms such as
<a>block-level box,</a> <a>block container box</a> and <a>table
box</a> 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> (see [[!CSS3-WRITING-MODES]]).
      
<!--
<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' or 'writing-mode: sideways-rl'
	    <th>'writing-mode: vertical-lr' or 'writing-mode: sideways-lr'
	<tbody>
	  <tr>
	    <th>'direction:&nbsp;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:&nbsp;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 &ldquo;horizontal-bt.&rdquo;
</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 &ldquo;inline-progression dimension&rdquo; for
&ldquo;measure&rdquo; and &ldquo;block-progression dimension&rdquo; for &ldquo;extent.&rdquo;

<div class=note>
<p>The following terms are defined in [[!CSS3-WRITING-MODES]]. For
convenience, here is a short summary.
    
<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>&ldquo;block-start&rdquo;
	  <th>&ldquo;inline-end&rdquo;
	  <th>&ldquo;block-end&rdquo;
	  <th>&ldquo;inline-start&rdquo;
	  <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'', ''sideways-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'', ''sideways-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>For example, the &ldquo;block-start padding&rdquo; by default refers
to the 'padding-top' and the &ldquo;inline-end border&rdquo; 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>&ldquo;measure&rdquo;
    <th>&ldquo;extent&rdquo;
   <tr><td>''horizontal-tb'' <td>width <td>height
   <tr><td>''vertical-rl'' <td>height <td>width
   <tr><td>''sideways-rl'' <td>height <td>width
   <tr><td>''vertical-lr'' <td>height <td>width
   <tr><td>''sideways-lr'' <td>height <td>width
  </table>

<p>These correspond to the dimensions in the <a>inline base
direction</a> and the <a>block flow direction,</a> 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>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.
</div>

<p>When boxes are laid out to form a <a class=index >flow</a> (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 lt="A|A edge">A
edge</dfn>, <dfn lt="B|B edge">B edge</dfn>, <dfn lt="C|C edge">C
edge</dfn> and <dfn lt="D|D edge">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><a>containing block</a>
	  <th>'direction' of<br><a>containing block</a>
	  <th>&ldquo;A edge&rdquo;
	  <th>&ldquo;B edge&rdquo;
	  <th>&ldquo;C edge&rdquo;
	  <th>&ldquo;D edge&rdquo;
      <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'', ''sideways-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'', ''sideways-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>

<div class=figure>
<p><img src="abcd-edges" alt="Image: A box with edges labeled
clockwise from top as A, B, C and D.">

<p class=caption>The edges of a box whose containing block is
horizontal.
</div>

<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., <a>horizontal</a> 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
<a>vertical</a> element with a <a>horizontal</a> <a>containing
block</a> or a <a>horizontal</a> element with a <a>vertical</a>
<a>containing block.</a> An <dfn>orthogonal flow</dfn> is a
<a>flow</a> whose <a>flow root</a> is an orthogonal element.

<!--=================================================================-->

<h2 id=viewport>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 <a>initial
containing block</a>).

<p>When the viewport is smaller than the area of the <a>canvas</a>
(see below) on which the document is rendered, the user agent usually
offers 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=cb>Containing blocks</h2>

<p>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 <a title="root element">root
    element's</a> top-level boxes is a rectangle with the dimensions of
    the <a>viewport</a>, anchored at the <a>canvas's</a>
    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 <a>content edge</a> of the <a>principal
	      box</a> of that sibling.

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

	      <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
<a>flow root</a> has a computed 'display' of ''block''.</span>
<span class=issue>Or insert the definition of block container box from
CSS&nbsp;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.

<!--=================================================================-->

<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
[[CSS-TEMPLATE-3]], 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 <a>initial containing block</a> 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 <a>block container boxes</a> (defined below) can be flow
roots. (Which implies that the children of a flow root are laid out in
a <a>block formatting context.</a>)

<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 <a>vertical</a> and its parent is
  <a>horizontal.</a> <span class=issue>[Add link to the relevant
  section.]</span>

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

  <!-- <li>The value of 'transform' is not 'none'. -->
</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 [[CSS-TEMPLATE-3]] 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 <a>flow root</a>
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>The used value of 'flow-into' [[CSS3-REGIONS]] <span
  class=issue>a.k.a. 'flow' [[CSS-TEMPLATE-3]]</span> is ''none''.

  <li>It is not a <a>flex item</a> [[!CSS3-FLEXBOX]].

  <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 [[CSS-TEMPLATE-3]] 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 [[CSS-TEMPLATE-3]]) 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 <a>containing block.</a>

<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: horizontal-tb; float: left }
blockquote[lang|=ja] { writing-mode: vertical-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 an <a>orthogonal</a> element
  (in this case a <a>vertical</a> box inside a <a>horizontal</a>
  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&nbsp;2 specification
is different. A flow root is called &ldquo;an element that establishes a
<span class=index title="formatting context|new formatting
context">new formatting context.</span>&rdquo;

<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 [[CSS-TEMPLATE-3]] 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.

<!--=================================================================-->

<h2 id=boxes>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.

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

<h3 id=block-level-cb-flows>Block-level boxes, containing blocks
and anonymous boxes</h3>

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

<p>An <dfn>inline-level</dfn> box is a box that has a <a>computed
value</a> 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).

<p>This module defines one kind of anonymous box:

<p>A <a>block-level box</a> may contain either <a>line boxes</a> or
<a>block-level</a> 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''.

<p>Other modules (e.g., [[CSS3TBL]], [[!CSS3TEXT]]) may also define
anonymous boxes.

<div class=example>
<p>An example of anonymous boxes 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-->

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

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

<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 class=issue>Add definition.

<!--

<p>Whether a compact box <var>X</var> is displayed as a block or in
the margin is determined as follows. Let <var>Y</var> be the next
sibling element in document order in the same flow as <var>X</var>, if
any. Let <var>W</var> be the hypothetical distance between the <a
title="D edge" >D</a> and <a title="B edge" >B</a> margin edges of
<var>X</var> if the 'display' property of <var>X</var> were set to
''block'' and any ''auto'' on its measure were replaced by
''fit-content''.

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

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

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

<li>If the <a title="D edge" >D</a> margin of Y is less than
<var>W</var>, then <var>X</var> is displayed as a block.

<li>Otherwise, <var>X</var> is displayed in that margin.
</ul>

<p class=issue>Also look at the padding of <var>Y</p>? I.e., check if
the sum of the padding, border and margin is wide enough?

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

<p>Otherwise, <var>X</var> is placed such that its
<a title="D edge">D</a> margin edge aligns with the <a>inline-start</a> margin edge of
its <a>containing block</a> and its <a title="A edge" >A</a> border
edge aligns with the <a title="A edge" >A</a> border edge of
<var>Y</var>. It is in this case an <a>inline-level</a> element.

<p class=issue>Do we do anything to avoid that floats overlap with
<var>X</var>? Do we do anything if <var>X</var> is taller than
<var>Y</var>? E.g., adjust the 'min-height' of <var>Y</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: horizontal-tb; direction: ltr}
dd {margin-left: 3em}
dt {display: compact; writing-mode: vertical-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 id=mixing>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).

<p class=issue>Do we need one or more 'display' values to signal that
an element is not to be formatted with CSS?

<p>An element that is not rendered according to the CSS box model 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?

<!--=================================================================-->

<h2 id=block-level>Block-level formatting</h2>

<p>The boxes that belong to a fow are laid out according to the rules
of <dfn>block-level formatting</dfn>:
  
<p class=issue>Define how boxes in a flow are positioned. (Basically,
each <a>C edge</a> against the <a>A edge</a> of the next
box and their <a>B edge</a> and <a>D edge</a> against,
respectively the <a>inline-end edge</a> and <a>inline-start
edge</a> of the <a>containing block</a>.)

<!--
<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">&ldquo;Calculating widths, heights and margins&rdquo;</a>
and <a href="#Collapsing">&ldquo;Collapsing margins.&rdquo;</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 <a>collapse</a> with its
        parent's <a>block-start</a> margin and the box is not
        <a>collapsed through,</a> then the box is placed such
        that the box's margin <a>A edge</a> coincides with the
        parent's <a>block-start</a> <a>content edge</a>, the
        margin <a>D edge</a> touches the parent's
        <a>inline-start</a> <a>content edge</a> and the margin
        <a>B edge</a> touches the parent's <a>inline-end</a>
        <a>content edge.</a>

	<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 <a>collapse</a> with its
        parent's <a>block-start</a> margin but the box
        is <a>collapsed through,</a> then its <a>content
        edge</a> (which is also its <a>border edge</a>
        and <a>padding edge</a>) is defined as what it would
        have been if the box had a non-zero <a>footside</a>
        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 <a title="A edge">A</a> margin collapses with
        its parent's <a>block-start</a> margin, then the box is placed
        such that the <a>A edge</a> of the box's border touches
        the parent's <a>block-start</a> <a>content edge,</a> the
        <a>D edge</a> of the box's margin touches the parent's
        <a>inline-start</a> <a>content edge</a> and the <a>B
        edge</a> of the box's margin touches the parent's
        <a>inline-end</a> <a>content edge.</a>

        <p class=issue>[Add illustration.]

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

        <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 <a>collapsed through,</a> it is
        positioned such that the <a>D edge</a> of its margin
        touches the parent's <a>inline-start</a> <a>content
        edge,</a> the <a>B edge</a> of its margin touches the
        parent's <a>inline-end</a> <a>content edge</a> and the
        <a>A edge</a> of its border box is at a distance from
        the <a>C edge</a> 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 <a>collapsed
      through,</a> <span class=issue>[...]</span>
  </ol>
</ul>
-->

<!--=================================================================-->

<h2 id=padding-props>The padding properties</h2>

<pre class=propdef>
Name: padding
Value: <var>&lt;length&gt;</var>{1,4}
Initial: see individual properties
Applies&nbsp;to: all elements
Inherited: no
Animation type: see individual properties
Percentages: width* of containing block
Computed&nbsp;value: see individual properties
Canonical order: N/A
</pre>
    
<p class="footnote">*) if the <em>containing
block</em> is <em>horizontal,</em> otherwise the height


<pre class=propdef>
Name: padding-top , padding-right, padding-bottom, padding-left
Value: <var>&lt;length&gt;</var>
Initial: 0
Applies&nbsp;to: all elements
Inherited: no
Animation type: by computed value
Percentages: width* of containing block
Computed&nbsp;value: &lt;length&gt;
Canonical order: N/A
</pre>

<p class="footnote">*) if the <em>containing
    block</em> is <span><em>horizontal,</em></span> otherwise the height

<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>Allow percentages?

<p class=issue>Allow &ldquo;auto&rdquo;?

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

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

<!--=================================================================-->

<h2 id=margin-props>The margin properties</h2>

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

<pre class=propdef>
Name: margin-top, margin-right, margin-bottom, margin-left
Value: <var>&lt;length&gt;</var> | <var>&lt;percentage&gt;</var> | auto
Initial: 0
Applies&nbsp;to: see text
Inherited: no
Animation type: by computed value
Percentages: width* of containing block
Computed&nbsp;value: the percentage as specified or the
  absolute length or ''auto''
Canonical order: N/A
</pre>

<p class="footnote">*) if the <em>containing
block</em> is <em>horizontal,</em> otherwise the height

<pre class=propdef>
Name: margin
Value: [ <var>&lt;length&gt;</var> | <var>&lt;percentage&gt;</var> | auto]{1,4}
Initial: see individual properties
Applies&nbsp;to: see text
Inherited: no
Animation type: see individual properties
Percentages: width* of containing block
Computed&nbsp;value: see individual properties
Canonical order: N/A
</pre>

<p class="footnote">*) if the <em>containing
block</em> is <em>horizontal,</em> otherwise the height

<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 <a title="collapse" >margin collapsing.</a>

<dt><var>&lt;percentage&gt;</var> <dd>Sets the margin to the given
percentage of the <a>extent</a> of the <a>containing
block.</a> 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
<a>horizontal,</a> respectively <a>vertical.</a>

<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">&ldquo;Calculating widths, heights and margins.&rdquo;</a>
</dl>

<div class=example>
<p>The case of the containing block's extent depending on this
element's margin can occur with floating elements. E.g.:
<pre>
&lt;div style="float: left">
 &lt;p style="margin: 5%">...
&lt;/div>
</pre>
<p>In this case the 5% computes to 5vw.
</div>

<p class=note>Note that the case of a containing block's extent
depending on the percentages was undefined in CSS level&nbsp;2.

<div class=issue>
<p>Some UAs implementing CSS level&nbsp;2 try to solve the set of linear
equations when <var>containing-block</var> is unknown:
<blockquote>
<p><var>margin</var> + <var>width</var> = <var>containing-block</var><br>
<var>margin</var> = <var>percentage</var> &times; <var>containing-block</var>
</blockquote>
<p>If different elements
in a flow yield different values they may take the biggest.
</div>

<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>One idea to distribute boxes better than with 'auto'
(which only works in the inline direction and fails to distribute
negative space) is to add a &ldquo;fill&rdquo; keyword, possibly combined with a
minimum margin: <css>fill</css> or ''1.2em + fill'' or ''calc(1.2em +
fill)''). &ldquo;Fill&rdquo; could also be a unit, so that some fills can get more
space than others: ''margin: 0.5fill'' or ''margin: 2fill''.

<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 <a>horizontal flow,</a> 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 id=width-and-height>The width and height properties</h2>

<pre class=propdef>
Name: width
Value: [<var>&lt;length></var> | <var>&lt;percentage></var>] |
    available | min-content | max-content | fit-content | auto
Initial: auto
Applies to: all elements but non-replaced inline
    elements, table rows, and row groups
Inherited: no
Animation type: by computed value
Percentages: refer to width of containing block
Computed value: 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 ''width/auto'' if the property does not apply; (also see
    prose under &lt;percentage>)
Canonical order: the length or percentage before the
    keyword, if both are present
</pre>

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

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

  <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
  <a>containing block.</a> 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>

  <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 ''height/auto'', except
  that elements with a <a>complex aspect ratio</a> (defined below) are
  considered to
  have an <a>intrinsic ratio</a>. More precisely: for the purposes
  of the section on <a href="#Calculating">&ldquo;Calculating widths,
  heights and margins,&rdquo;</a> the element is treated as if its height
  was ''height/auto'' and it had an <a>intrinsic ratio</a>.
</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>Another idea is to allow optional keywords border-box
and content-box before or after a length or percentage. This would
mean the same as (and overrides) setting the 'box-sizing' property to
that property, but allows width and height to be treated differently
and avoids that width and box-sizing getout of sync.

<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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>

<pre class=propdef>
Name: min-width, min-height
Value: [ [<var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var>] &amp;&amp; [border-box | content-box]? ] |
    available | min-content | max-content | fit-content
Initial: 0
Applies to: all elements but non-replaced
    inline elements, table rows, and row groups
Inherited: no
Animation type: by computed value
Percentages: refer to width, resp. height of
    containing block
Computed value: 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)
Canonical order: the length or percentage before the
    keyword, if both are present
</pre>

<pre class=propdef>
Name: max-width, max-height
Value: [ [<var>&lt;length&gt;</var> |
    <var>&lt;percentage&gt;</var>] &amp;&amp; [border-box | content-box]? ] |
    available | min-content | max-content | fit-content | none
Initial: none
Applies to: all elements but non-replaced inline
    elements, table rows, and row groups
Inherited: no
Animation type: by computed value
Percentages: refer to width, resp. height of
    containing block
Computed value: 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
Canonical order: the length or percentage before the
    keyword, if both are present
</pre>

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

<dl dfn-for="max-width max-height">
  <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=aspect><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 <a>replaced elements</a>:

<dl>
<dt>Type&nbsp;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&nbsp;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&nbsp;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. HTML documents are examples of this:
the width can be chosen freely, but at every width there is a definite
intrinsic height.

<dt>Type&nbsp;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 class=note><span class=index>Raster images</span> are always of
type&nbsp;1. See the 'image-resolution' property for how their size in 'px'
is determined.

<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
several lines if it is too long.)
</div>

<!--=================================================================-->

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

<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,
<a title="padding area">padding</a> or <a title="border
area">border areas</a> 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
''fill'', 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 (&ldquo;only block-level&rdquo;) 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. (&ldquo;Collapsing is
    transitive&rdquo;)

  <!-- 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>&ldquo;collapsed through.&rdquo;</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
<a>block-level</a> 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 id=inline-level>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
module [[!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 calculation.

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

  <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-TRANSFORMS]] do not
affect the width or height and also do not affect the placement of
boxes in the normal flow (see <a href="#block-level">&ldquo;Block-level
formatting&rdquo;</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(<var>min</var>, <var>max</var>) 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</var>&nbsp;>&nbsp;<var>max-width</var>
      <td><var>max-width</var>

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

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

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

      <td><var>max-width</var>
      <td>max(<var>min-height</var>, <var>max-width</var>&nbsp;*&nbsp;<var>h</var>/<var>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>max(<var>min-width</var>, <var>max-height</var>&nbsp;*&nbsp;<var>w</var>/<var>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</var>/<var>w</var>&nbsp;&#8804;&nbsp;<var>min-height</var>/<var>h</var>)

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

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

      <td><var>min-width</var>
      <td><var>max-height</var>
  <tr><td>(<var>w</var>&nbsp;>&nbsp;<var>max-width</var>) and (<var>h</var>&nbsp;&lt;&nbsp;<var>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 &ldquo;left&rdquo; replaced by
&ldquo;top,&rdquo; &ldquo;right&rdquo; by &ldquo;bottom,&rdquo; &ldquo;top&rdquo; by &ldquo;right,&rdquo; &ldquo;bottom&rdquo; by &ldquo;left&rdquo;,
&ldquo;height&rdquo; by &ldquo;width&rdquo; and &ldquo;width&rdquo; by &ldquo;height.&rdquo;

<!-- '100vw' decided at ftf Sep 10, 2007. '100vh' is my suggestion.
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 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&nbsp;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 <a>block-level</a> 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 <a>block-start</a> padding, <a>block-end</a>
padding, <a>block-start</a> margin and <a>block-end</a> 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 <a>orthogonal
  flows</a> (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="https://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 <a>initial containing block</a>

  <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="https://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="https://www.w3.org/TR/css3-break/Overview.html#fragmentainer">&ldquo;fragmentainer,&rdquo;</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&hellip;)
  containing a section with vertical text (represented by digits 1, 2,
  3&hellip;). 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 <a>extent</a> is
not ''auto'', then the used value is calculated by evaluating the
computed value. Otherwise, the <a>extent</a> is
the distance between two edges that are defined as follows:

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

<li>For the second edge: If the element is the <a>root
element</a> or if it has a non-zero <a>block-end</a> padding or a
non-zero <a>block-end</a>
border, then the second edge is the <a>footside</a> <em>margin
edge</em> of the last <a>line box</a> or <a>block-level
box</a> (whichever comes last); otherwise the second edge is the
<a>footside</a> <em>border edge</em> of the last <a>line
box</a> or <a>block-level box</a> (whichever comes last) that
doesn't have its margins <a>collapsed through.</a>
</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 <a>measure,</a> 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 <a>horizontal</a> or <a>vertical,</a>
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>If none of the values is ''auto'', then the used value
  of the inline-end margin is set to the value that satisfies the
  constraint.

  <li>If the <a>measure</a> 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&nbsp;1
  above.</a>

  <li>If both the <a>inline-start</a> and <a>inline-end</a> margins
  are ''auto'', 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&nbsp;1 above.</a>

  <li>If only the <a>inline-start</a> margin is ''auto'' , then set
  the inline-start margin to the value that satisfies the constraint.

  <li>If only the <a>inline-end</a> margin is ''auto'', then set the
  inline-end margin to the value that satisfies the constraint.
</ol>

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

<p>This section applies to <a>block-level,</a> 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 <a>block-start</a> padding, <a>block-end</a>
padding, <a>block-start</a> margin and <a>block-end</a> margin are
calculated from the computed values, with any ''auto'' values replaced
by 0.

<p>If the <a>block flow dimension</a> is ''auto'', the used value
is defined by <a href="#root-height">&ldquo;<css>auto</css> heights for flow
roots.&rdquo;</a> Otherwise, the used value is evaluated from the computed
value.

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



<h3 id=inline-block-or-floating>'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">&ldquo;<css>auto</css> heights for flow roots.&rdquo;
</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">&ldquo;<css>auto</css> heights for flow
roots.&rdquo;</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 &ldquo;unless&rdquo;?</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">&ldquo;<css>auto</css> heights for flow roots.&rdquo;
  </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 <a>static position.</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 for 'bottom'.

  <li>'height' and 'bottom' are ''auto'' and 'top' is not ''auto'':
  The used height is defined by <a href="#root-height">&ldquo;<css>auto</css>
  heights for flow roots.&rdquo;</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 <a>static position;</a> else if 'direction' is
  ''rtl'', the used value of 'right' is its <a>static position.</a>

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

  <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 &ldquo;unless&rdquo;? 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 id=block-level-replaced>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 id=floating>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">&ldquo;<css>auto</css> heights for flow roots.&rdquo;
</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 <a>block-level</a> 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 id=float-prop>The float property</h2>

<pre class=propdef>
Name: float
Value: left | right | top | bottom | start | end | none |
    <var>&lt;page-floats&gt;</var>
Initial: none 
Applies to: all, but see text
Inherited: no 
Animation type: discrete
Percentages: N/A 
Computed value: as specified
Canonical order: order of grammar
</pre>

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

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

<dl dfn-for="float">
  <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'' <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'' <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 id=intro-to-floats>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
&ldquo;floating&rdquo; 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 &ldquo;normal&rdquo; 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">&ldquo;Collapsing margins,&rdquo;
</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 &ldquo;pushed down&rdquo; 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 id=float-rules>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 <a>margin edge</a> of a left-floating box may not
be to the left of the left edge of its <a>containing block</a>. 
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 <a>margin
edge</a> of the current box must be to the right of the right
<a>margin edge</a> 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 <a>margin edge</a> of a left-floating box may not
be to the right of the left <a>margin edge</a> 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 <a>margin edge</a> may not be higher
than the top of its <a>containing block</a>. When the float
occurs between two collapsing margins, the float is positioned as if
it had an otherwise empty <a title="anonymous box">anonymous block
parent</a> taking part in the flow. The position of such a parent
is defined by <a title="collapsed through">the rules</a> in the
section on margin collapsing.

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

<li>The top <a>margin edge</a> of an element's floating box may
not be higher than the top of any <a>line-box</a> 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 <a>margin edge</a> of a top-floating box may not be
above the top edge of its <a>containing block</a>. 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 <a>margin edge</a> of the
current box must be below the bottom <a>margin edge</a> 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 <a>margin edge</a> of a top-floating box may not
be below the top <a>margin edge</a> of any
bottom-floating box that is below it. Analogous rules hold
for bottom-floating elements.

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

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

<li>The right <a>margin edge</a> of an element's floating box
may not be to the right of the right edge of any <a>line-box</a>
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 <a>block-level</a> 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. (&ldquo;Sufficient space&rdquo; means
that the opposite margin does not become negative.)</span>

<!--=================================================================-->

<h2 id=clear-prop>The clear property</h2>

<pre class=propdef>
Name: clear
Value: none | left | right | both
Initial: none 
Applies to: <a>block-level</a> elements 
Inherited: no
Animation type: discrete
Percentages: N/A
Computed value: as specified
Canonical order: N/A
</pre>

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

<!--=================================================================-->

<h2 id=clear-after-prop>The clear-after property</h2>

<pre class="propdef">
Name: clear-after
Value: none | left | right | top | bottom | inside | outside | start | end
        | both | descendants
Initial:      none
Applies to:      block-level elements
Inherited:      no
Animation type: discrete
Percentages:      N/A
Computed&nbsp;value:      specified value
Canonical order:      N/A
</pre>

<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 <a>block-end</a> padding or <a>block-end</a>
border, and there are any floats on the indicated side(s) in the
current <a>flow</a> up to and including the end of this element,
then find the one whose <a title="C edge">C</a> <a>margin edge</a>
is furthest away from the <a>block-start</a> <a>content edge</a> of the
<a>containing block.</a> 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 dfn-for="clear-after">
  <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>

<div class=example>
<p>In simple cases, the effect of 'overflow: hidden' can be quite
similar to 'clear-after: both', e.g., this documents looks the same whether it contains ''overflow: hidden'' or ''clear-after: both'':
<pre>
<b>&lt;html></b>
<b>&lt;style></b>
 div {overflow: hidden; border: solid}
 .float {float: left; width: 20%;
   margin: 1em; border: solid}
<b>&lt;/style></b>
<b>&lt;div></b>
 <b>&lt;p class=float></b>This paragraph floats and is quite long.
 <b>&lt;p></b>short text
<b>&lt;/div></b>
</pre>
<div class=figure>
<p><img src="clear-after4.png" alt="[screendump]">
<p class=caption>The DIV's border goes around the floating box.
</div>

<p>But in more complex cases, the fact that ''overflow: hidden'' affects
overflow and creates a <a>flow root</a> can be visible. This is the
same document, but now there is a floating box <em>before</em> the
DIV:
<pre>
<b>&lt;html></b>
<b>&lt;style></b>
 div {overflow: hidden; border: solid}
 .float {float: left; width: 20%;
   margin: 1em; border: solid}
<b>&lt;/style></b>
<b>&lt;p class=float></b>This paragraph floats and is quite long.
<b>&lt;div></b>
 <b>&lt;p></b>short text
<b>&lt;/div></b>
</pre>
<div class=figure>
<p><img src="clear-after5.png" alt="[screendump]"> <p
class=caption>With ''overflow: hidden'', the floating box before the
DIV causes the DIV as a whole to become narrower
</div>
<div class=figure>
<p><img src="clear-after6.png" alt="[screendump]"> <p
class=caption>With ''clear-after: both'' instead of ''overflow:
hidden'', the floating box before the DIV doesn't change the width of
the DIV, but it <em>does</em> change the height.
</div>
</div>

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

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

<div class=issue id=contain-floats>
<p>Alternative ideas to clear-after are new values on 'overflow',
'height', 'min-height' or 'display', e.g.: ''height: contain''.
</div>

<!--=================================================================-->

<h2 id=overflow-intro>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 (&ldquo;marquee,&rdquo; see [[CSS3-MARQUEE]]).

<h3 id=overflow-props>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 &ldquo;overflow-x and/or -y&rdquo; or similar.

<pre class=propdef>
Name: overflow-x, overflow-y
Value: visible | hidden | scroll | auto | no-display | no-content
Initial: visible
Applies to: non-replaced <em>block-level</em> elements
  and non-replaced ''inline-block'' elements
Inherited: no
Animation type: discrete
Percentages: N/A
Computed&nbsp;value: as specified, except 'visible', see text
Canonical order: N/A
</pre>

<pre class=propdef>
Name: overflow
Value: [ visible | hidden | scroll | auto | no-display |
  no-content ]{1,2}
Initial: see individual properties
Applies to: non-replaced <em>block-level</em> elements
  and non-replaced ''inline-block'' elements
Inherited: no
Animation type: see individual properties
Percentages: N/A
Computed&nbsp;value: as specified, except 'visible', see text
Canonical order: N/A
</pre>

<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&nbsp;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 &ldquo;scroller&rdquo; element will not scroll the
&ldquo;satellite&rdquo; 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 id=visibility-prop>The visibility property</h2>

<pre class=propdef>
Name: visibility
Value: visible | hidden | collapse
Initial:  visible
Applies&nbsp;to: all elements
Inherited: yes
Animation type: discrete
Percentages: N/A
Computed value: as specified
Canonical order: N/A
</pre>

<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 id=stacking>Stacking contexts</h2>

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

<h3 id=definitions>Definitions</h3>

<dl>

<dt>Tree Order</dt>

<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.</dd>

<dt>Element</dt>

<dd>In this description, &ldquo;element&rdquo; 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.</dd>

</dl>

<h3 id=painting>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 painting order for the descendants of 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, <a>block-level</a>
	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, <a>block-level</a> descendants in tree order:
	<ol>
	  <li>
	    <p>If the element is a <a>block-level</a> 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 <a>block-level,</a>
	    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 id=notes>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.2-->, the exact result of these two requirements is
    UA-defined. CSS may in the future
    define this in more detail.

<!--=================================================================-->

<h2 id=float-displace-1>The 'float-displace' and 'indent-edge-reset' properties [alternative&nbsp;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 id=float-displace-prop>The 'float-displace' property</h3>

<pre class="propdef">
Name:      float-displace
Value:      line | indent | block | block-within-page
Initial:      line
Applies&nbsp;to:      all block-level elements
Inherited:      yes
Animation type: discrete
Percentages:      N/A
Computed&nbsp;value:      Same as specified value
Canonical order:      N/A
</pre>

<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
      &ldquo;bar&rdquo; 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.
</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 id=indent-edge-reset-prop>The 'indent-edge-reset' property</h3>

<pre class=propdef>
Name:      indent-edge-reset
Value:      none | margin-edge | border-edge | padding-edge | content-edge
Initial:      none
Applies to:      all elements with a block-level inner formatting context.
Inherited:      no
Animation type: discrete
Percentages:      n/a
Computed value:      specified value
Canonical order:      N/A
</pre>

<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 dfn-for="indent-edge-reset">
  <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 id=float-displace-2>The &lsquo;float-displace&rsquo; property [alternative&nbsp;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:

<pre class=propdef>
Name:      float-displace--alternative-2
Value:      line | indent | block | block-within-page
Initial:      line
Applies&nbsp;to:      all block-level elements
Inherited:      yes
Animation type: discrete
Percentages:      N/A
Computed&nbsp;value:      Same as specified value
Canonical order:      N/A
</pre>

<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&nbsp;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 <a>relative indent</a>
      (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
      <a>relative indent</a> 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 <a>line box</a> normally stretches from an
element's <a>content edge</a> 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 id=contour>For all elements <var>E</var>, and all floats <var>F</var> whose
parent is in the same <a>flow</a> as <var>E</var>, and all
<a>line boxes</a> <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>
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</var>'s, 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 <a>line boxes</a> 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.

<!--=================================================================-->

<h2 class=no-num id=float-displace-3>The &lsquo;float-displace&rsquo; property [alternative&nbsp;3]</h2>

<p class=issue>Yet another alternative. This one adds a fixed indent
rather than one that depends on the context:

<pre class="propdef">
Name:      float-displace--alternative-3
Value:      auto | &lt;length> &amp;&amp; [ block | block-within-page ]?
Initial:      auto
Applies&nbsp;to:      all block-level elements
Inherited:      no
Animation type: discrete
Percentages:      N/A
Computed&nbsp;value:      Same as specified value
Canonical order:      N/A
</pre>

<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&nbsp;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 id=acknowledgments>Acknowledgments</h2>

<p class=issue>To do&hellip;

<!--
<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>]
-->




<!-- Keep this comment at the end of the file
Local variables:
mode: html
sgml-minimize-attributes:t
End:
-->