CSS basic box model

Abstract

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

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

In CSS level 3, boxes may contain either horizontal or vertical text. Different orientations can be mixed.

Status of this document

This is a public copy of the editors' draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don't cite this document other than as work in progress.

The (archived) public mailing list www-style@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “css3-box” in the subject, preferably like this: “[css3-box] …summary of comment…”

This document was produced by the CSS Working Group (part of the Style Activity).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

The CSS Working Group plans to ask for W3C Recommendation status for this specification only when there are sufficiently many implementations. See the section “CR exit criteria” for details.

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

Table of contents

• 1. How to read this specification
• 2. Dependencies on other modules
• 3. Introduction & definitions
• 4. The viewport and the canvas
• 5. Aspect ratios of replaced elements
• 6. Basic flow layout
• 7. Types of boxes
  • 7.1. The display property
  • 7.2. Mixing the box model with other formatting models
  • 7.3. Block-level boxes, containing blocks, flows and anonymous boxes
  • 7.4. Run-in boxes
  • 7.5. Compact boxes
• 8. The padding properties
• 9. Margins
  • 9.1. The margin properties
  • 9.2. Collapsing margins
• 10. The width and height properties
• 11. The min-width, max-width, min-height and max-height properties
• 12. Definition of intrinsic sizes – high quality
• 13. Definition of intrinsic sizes – low quality
• 14. Calculating widths, heights and margins
  • 14.1. Inline, non-replaced elements
  • 14.2. Inline or floating, replaced elements
  • 14.3. Block-level, non-replaced elements in normal flow when ‘overflow’ computes to ‘visible’
  • 14.4. Other block-level, non-replaced elements in normal flow
  • 14.5. ‘Inline-block’ or floating, non-replaced elements
  • 14.6. Absolutely positioned, non-replaced elements
  • 14.7. Absolutely positioned, replaced elements
  • 14.8. Block-level, replaced elements in normal flow
  • 14.9. Floating, non-replaced elements
  • 14.10. Auto heights for flow roots
• 15. The float property
  • 15.1. Introduction to floats
  • 15.2. Rules for positioning floats
• 16. The clear property
• 17. The clear-after property
• 18. Overflow
  • 18.1. The overflow, overflow-x and overflow-y properties
• 19. The visibility property
• 20. The alignment property
• 21. The child-align property
• 22. Stacking contexts
  • 22.1. Definitions
  • 22.2. Painting order
  • 22.3. Notes
  • 22.4. The <number> value
  • 22.5. The auto value
  • 22.6. Algorithm for shrink-wrapping replaced elements with complex width/height
• 23. The ‘float-displace’ property
• 24. The ‘indent-edge-reset’ property
• 25. Conformance and profiles
• 26. CR exit criteria
• 27. Acknowledgments
• References
• Index
• Property index

1. How to read this specification

All sections are normative, unless stated otherwise.

Notes look like this and normally start with the word “Note.” Notes are not normative.

Editorial notes look like this. They will be removed before the document becomes Candidate Recommendation.

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 [where?] for the meaning. The “Inherited” and “Initial” rows in the table are used by the Cascading and Inheritance module [CSS3CASCADE] and “Media” by the Media Queries specification [MEDIAQ].

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

2. Dependencies on other modules

This CSS module depends on the following other CSS modules:

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

3. Introduction & definitions

Investigate if it is possible to make a pseudo-element to select anonymous boxes (‘::paragraph’). See minutes of 10 Aug 2011.

Note: The model in this specification differs from the model described in the CSS level 2 specification [CSS21], because it is generalized to apply also to vertical text.

CSS assumes that the document to lay out is modeled as a tree of elements. 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 root element.

CSS describes how each element and each string of text is laid out by transforming the document tree into a set of rectangular boxes, whose size, position, and stacking level on the canvas depend on their properties. We say that an element generates one or more boxes. There are block-level boxes, line boxes and inline-level boxes. A block-level box is like a paragraph. A line box is like a line of text. Inline-level boxes are like words inside a line.

When the specification says a box A contains a box B, then B is a box generated by an element that is a descendant of the element that generated A. Typically, box B is geometrically contained in box A as well, but that need not be the case, because of, e.g., overflow or negative margins.

Note: The precise rules are below and in other modules, but in summary, a block-level box contains either other block-level boxes (e.g., a section containing paragraphs, or a table containing rows), or it contains line boxes (e.g., a paragraph containing lines of text). A line box contains inline-level boxes (e.g., a line with words in different styles). An inline-level box may contain either text interspersed with more inline-level boxes, or it may contain a block-level box (e.g., a small table that is rendered inline).

<ul>
 <li>The first item in the list.
 <li>The second item.
</ul>

Each box belongs to exactly one element. It is either generated directly by the element, or it is an anonymous box (defined below), which is inserted because the layout rules of CSS require a box to contain a certain kind of other box, but the boxes generated by the child elements are not of that kind. The anonymous box is defined to belong to the parent.

Note: This is mainly important for WYSIWYG document editors: if the user selects a box on the screen in order to set a property, the editor knows which element to set the property on.

Properties are set on elements and influence how the element is turned into boxes, but in this specification we refer interchangeably to “the P property of an element” and “the P property of a box” (both of which actually mean “the value of property P of…”), unless it is important to distinguish the box and the element, e.g., because the element has several boxes and they don't all have the same value for the property.

Boxes have padding, a border and margins (see the figure). Different properties determine the thickness of each of these (which may be zero). The margins are also subject to collapsing.

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

When the specification says that the padding or border is “absent” on some side of the box, that actually means that its thickness is zero.

Line boxes cannot have any padding, border or margin, and therefore their margin edge, border edge, padding edge and content edge all coincide.

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.

Note that the edges always form rectangles, even if there is a ‘border-radius’ [CSS3BG] or a shape [CSS3-EXCLUSIONS].

A box or element is horizontal if its ‘writing-mode’ property is ‘horizontal-tb’, otherwise it is vertical. The orientation of a box or element is the pair of values of its ‘writing-mode’ and ‘direction’

This specification sometimes refers to abstract edges head, end, tail and start, which are relative to the orientation of a box. They map to top, right, bottom and left as follows:

For example, the “head padding” by default refers to the ‘padding-top’ and the “end border” is by default the ‘border-right’.

Similarly, the specification sometimes refers to the inline and block flow dimensions of a box, instead of width and height, as follows:

These correspond to the dimensions in the inline base direction and the block flow direction, respectively.

Finally, the headside, endside, tailside and startside of a box are defined as the sides that correspond to the head, end, tail and start, of the containing block of the box.

Check terms. At Cambridge ftf Aug 2008 we chose: Property name: block-flow with values tb | lr | rl | bt. Descriptive terms: horizontal mode (= tb & bt), vertical mode (= lr & rl). The May 2012 Writing Modes module now has ‘writing-mode’ with values ‘horizontal-tb’, ‘vertical-rl’ and ‘vertical-lr’ (and no ‘bt’ anymore).

4. The viewport and the canvas

User agents for continuous media generally offer users a viewport (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 initial containing block).

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

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

5. Aspect ratios of replaced elements

For the purposes of the width and height calculations below, CSS distinguishes four kinds of replaced elements:

Type 1: replaced elements with both intrinsic width and intrinsic height.

These are replaced elements that are meant to be displayed with a certain fixed factor (the intrinsic ratio) 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.

Type 2: replaced elements with only an intrinsic ratio

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. SVG images often fall in the this category.

Type 3: replaced elements with a complex aspect ratio

These are replaced elements that do not have a fixed ratio between their width and height, but that do have a functional relation between them in the sense that for every width there is a unique height. HTML documents are examples of this: the width can be chosen freely, but at every width there is a definite intrinsic height.

Type 4: replaced elements without an intrinsic ratio

These are replaced elements that have no relation between their width and height. Certain SVG images are examples of this.

For raster images without reliable resolution information, a size of 1 px unit per image source pixel must be assumed. These images thus are of type 1.

... <object data="example.html"
      style="width: 30em; height: auto"></object>...

... <object data="example.html"
      style="width: 30em; height: complex"></object>...

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

The mathematical formula would however benefit from a way to negotiate available space against intrinsic size, or even negotiate available space against the number of boxes, so that the formula could be broken in two or more boxes and occupy space on two or more lines (similar to how lines of text are broken or words are hyphenated). But an easier solution might be to extend HTML with native support for math and CSS with math boxes, so that replaced elements remain single boxes.

6. Basic flow layout

As described in the introduction, elements give rise to boxes and those boxes are laid out on a canvas. Different kinds of boxes are laid out differently. This section describes the layout of one flow of boxes.

The approximate model for the layout of a flow of boxes is that sibling boxes are laid out one after the other in one long series with margins between them and parent boxes tightly wrap the series of child boxes. The ‘writing-mode’ property of the parent determines if that series grows down (‘tb’), to the left (‘rl’), to the right (‘lr’) or up (‘bt’). Although the rules below depend on terms that are only defined further down, the rules are given at the outset, to provide at least an approximate model of how boxes are positioned relative to one another.

The following rules define the position of block-level boxes relative to the box that is their flow root. 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].

Before applying these rules, the width, height and margins of each box must be computed as described in the sections “Calculating widths, heights and margins” and “Collapsing margins.”

• Consider the first box (in document order) of a set of sibling boxes that all belong to the same flow. There are four cases:

  1. If none of its margins collapse with its parent's head margin and the box is not collapsed through, then the box is placed such that the box's headside margin edge touches the parent's head content edge, the startside margin edge touches the parent's start content edge and the endside margin edge touches the parent's end content edge.

     [Add illustration.]

     [Alternative terminology:] If none of its margins collapse with its parent's A margin and the box is not collapsed through, then the box is placed such that the box's A′ margin edge touches the parent's A content edge, the D′ margin edge touches the parent's D content edge and the B′ margin edge touches the parent's B content edge.

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

     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.

  3. If exactly one of its margins collapses with its parent's head margin, then the box is placed such that the box's headside border edge touches the parent's head content edge, the startside margin edge touches the parent's start content edge and the endside margin edge touches the parent's end content edge.

     [Add illustration.]

  4. If two of its margins collapse with its parent's head margin, then its position is such that its content edge (which is also its border edge) touches its parent's head border edge and that its startside margin edge touches its parent's start content edge and its endside margin edge touches the parent's end content edge.

     Note that the box is effectively invisible, but the edges have to be defined to position any descendants.

• For a box that has a preceding sibling in the same flow there are two cases:

  1. If the box is not collapsed through, it is positioned such that its margin edge touches the parent's start content edge and end content edge and such that its content edge on the touches the [...]

  2. A box that has a preceding sibling in the same flow and that is collapsed through, [...]

7. Types of boxes

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.

7.1. The display property

There is an old proposal to split ‘display’ into display-role (the function of the element in its parent) and display-model (how the element lays out it children). That allows some combinations that have no keyword, such as a table cell (‘display-role: table-cell’) that is itself a table (‘display-model: table’), without the need for an extra wrapper element. It allows certain things (for math layout, e.g.), but is not easy to use. An alternative proposal is an ‘::outside’ pseudo-element to create an extra box on which to set a different ‘display’ value. That is not easy either, and doesn't cascade well. And a third proposal is to allow two values on ‘display’: if there are two (in any order), one is the role and the other the model, unless the pair makes no sense. That doesn't make the concept any easier, but it hides the complexity better.

This property, in combination with ‘float’ and ‘position’, determines the type of box or boxes that are generated for an element. The values are as follows:

inline

Inline boxes.

block

Block boxes.

inline-block

A block box, which itself is flowed as a single inline box, similar to a replaced element. The inside of an inline-block is formatted as a block box, and the box itself is formatted as an inline box.

list-item

One or more block boxes and one marker box. Marker boxes are defined in the Lists module [CSS3LIST]. If the Lists module is not ready, define the position of the marker and the list-style property here? Or refer to CSS 2.1 instead?

run-in

Either block or inline boxes, depending on context (see Run-in boxes). Properties apply to run-in boxes based on their final status (inline-level or block-level).

compact

Either block boxes or a marker box, depending on context (see Compact boxes). Properties apply to compact boxes based on their final status.

table, inline-table, table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, table-caption

See the Tables module [CSS3TBL].

ruby, ruby-base, ruby-text, ruby-base-group, ruby-text-group

See the Ruby module [CSS3RUBY].

align-box or container?

Like ‘block’, but forces the element to be a flow root,, which, e.g., stops its margins from collapsing with margins of child elements and includes floating children in its height. [C.f. the discussion of how to force an element to contain floats.]

none

This value causes an element to not appear in the formatting structure (i.e., in visual media, the element generates no boxes and has no effect on layout). Descendant elements do not generate any boxes either; the element and its content are removed from the formatting structure entirely. This behavior cannot be overridden by setting the ‘display’ property on the descendants.

Note that ‘none’ does not create an invisible box; it creates no box at all. See ‘visibility’ for a mechanisms that enables an element to generate boxes that affect formatting but are not visible themselves.

Note that both ‘clear-after’ and ‘align-box’ can be used to force the next element after this one to start after any floats inside this element, but the effect is not exactly the same. E.g., ‘display: box’ also affects certain forms of margin collapsing.

Note that ‘vertical-al ign’ applies to ‘align-box’ elements, hence the name. The ‘vertical-align’ property doesn't apply to other block-level elements, except ‘table-cell’ elements.

Any sense in vertically spreading out the contents, something like ‘vertical-align: justify’?

Simpler to not use ‘vertical-align’, but creating ‘top-box’, ‘middle-box’ and ‘bottom-box’?

div.slide {
  display: align-box;
  height: 15em;
  vertical-align: middle;
  border: thin solid }

<div class=slide>
  <ul>
    <li>Bullet lists are boring
    <li>They distract from the speaker
    <li>Don't use them!
  </ul>
</div>

The computed value of ‘display’ depends on ‘position’ [CSS3POS], ‘float’ and ‘overflow’:

1. If the specified value of ‘display’ is ‘none’, then the computed value is ‘none’ (and ‘overflow’, ‘float’ and ‘position’ do not apply).
2. Otherwise, if ‘position’ is ‘absolute’ or ‘fixed’, or if ‘float’ is not ‘none’, or if ‘overflow’ is not ‘visible’, or if the element is the root element, then the computed value of ‘display’ is set according to the following table:

   Specified value	Computed value
   inline-table	table
   inline, run-in, table-row-group, table-column, table-column-group, table-header-group, table-footer-group, table-row, table-cell, table-caption, inline-block	block
   others	same as specified

3. Otherwise, the computed value of ‘display’ is the same as the specified value.

7.2. Mixing the box model with other formatting models

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

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

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?

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

7.3. Block-level boxes, containing blocks, flows and anonymous boxes

A block-level box is a box that has a computed value for ‘display’ of ‘block’, ‘align-box’, ‘list-item’, ‘table’, ‘table-*’ (i.e., all table boxes, see [CSS3TBL]), ‘run-in’ (under certain circumstances, see “Run-in boxes” ), or ‘compact’ (under certain circumstances, see “Compact boxes”).

An inline-level box is a box that has a computed value for ‘display’ of ‘inline’, ‘inline-block’, ‘inline-table’, ‘ruby’, ‘run-in’ (under certain circumstances), or ‘compact’ (under certain circumstances).

[What about the other ruby values?]

An anonymous box, informally, is a box that cannot be addressed with CSS selectors. All its properties, except for ‘display’, have their default values (either the initial value or inherited). Anonymous boxes are created when the CSS box model requires a child box with a certain value for ‘display’, but the child actually has a different value. In that case an anonymous box of the right kind is created and wraps the child (or children). Other modules (e.g., [CSS3TBL], [CSS3TEXT]) may also define anonymous boxes. The anonymous boxes defined by this module are the following:

• A block-level box may contain either line boxes or block-level 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>Somebody whose name I have
forgotten, said, long ago: <q>a box is
a box,</q> and he probably meant it.</p>

p { display: block }
q { display: block; margin: 1em }

Note that the anonymous boxes defined in this module are all block-level, but anonymous boxes defined in other modules may be different.

The containing block 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:

• The containing block of the root element's top-level boxes is a rectangle with the dimensions of the viewport, anchored at the canvas's 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 initial containing block. The ‘direction’ and ‘writing-mode’ of the initial containing block are the same as those of the root element.
• For other elements, the containing block is one of the following:
  1. If the element is a ‘run-in’ that is rendered inline in a sibling element, then its containing block is the content edge of the principal box of that sibling.
  2. Otherwise, if the parent has a principal box that is a block container box (e.g., if the parent is a ‘table-cell’ or a ‘block’), then the containing block is the content edge of the parent's principal box.
  3. Otherwise the containing block is the same as that of the parent.

In the above, a block container box 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’. Note that most floating and absolutely positioned elements have a computed ‘display’ of ‘block’. Also, a flow root has a computed ‘display’ of ‘block’. Or insert the definition of block container box from CSS 2.1 here?

Also define principal box somewhere.

Issue 142 of CSS 2.1 suggests that an anonymous cell box, unlike anonymous block boxes, can establish the containing block for its children. If that is accepted, make sure the table module modifies the above definition.

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.

If an element [or a viewport?] 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.

A flow root is a box that satisfies at least one of the following:

• The value of ‘float’ is not ‘none’.
• The used value of ‘overflow’ is not ‘visible’.
• The value of ‘display’ is ‘table-cell’, ‘table-caption’ (see [CSS3TBL]), ‘inline-block’, ‘inline-table’ or ‘align-box’.
• The value of ‘position’ is ‘absolute’ or ‘fixed’ (see [CSS3POS]).
• The box is vertical and its parent is horizontal.
• The box is horizontal and its parent is vertical.
• The value of ‘transform’ is not ‘none’.
• The value of ‘child-align’ is not ‘auto’. [If ‘child-align’ is adopted, rather than, say, ‘margin: fill’]

Note that an element with ‘display: inline’ therefore cannot be a flow root: it doesn't float (otherwise its ‘display’ would be ‘block’), and neither ‘overflow’ nor ‘writing-mode’ apply to inlines.

Note: The terminology in the CSS level 2 specification is different. A flow root is called “an element that establishes a new formatting context.”

Other modules may define additional flow roots. [Can we thus remove ‘table-caption’, ‘table-cell’, and ‘position’ from the list above?]

The flow (a.k.a. normal flow) of a given flow root is a set of boxes. A box belongs to the flow if all of the following are true:

1. The used value of its ‘display’ is ‘block’, ‘list-item’ or ‘table’.
2. The used value of its ‘float’ is ‘none’.
3. The used value of its ‘position’ is ‘static’ or ‘relative’.
4. It is either a child of the flow root or a child of a box that belong to the flow.

<div class=sidebar>
 <p>Text in a sidebar.
 <p>Here is quote:
 <blockquote lang=ja>
  <p>...
 </blockquote>
 <p>Etc. etc.
</div> 

div.sidebar { writing-mode: tb; float: left }
blockquote[lang|=ja] { writing-mode: rl; height: 10em }

Note that a flow root is not necessarily block-level, it may be an ‘inline-block’, e.g.

The boxes of a flow are laid out inside their flow root one after the other in the direction of the ‘writing-mode’ property of the flow root and in the same order as in the source document. Their position is given by how much their margins overlap (see “Collapsing margins”) and by the fact that their side margin edges coincide with content edges of their containing blocks. More precisely: Each box's left and right margin edges coincide with the left and right edges of its containing block (if the flow root is ‘tb’), or its top and bottom margin edges coincide with the top and bottom edges of its containing block (if the flow root is ‘rl’ or ‘lr’).

7.4. Run-in boxes

A ‘run-in’ element (or pseudo-element) A behaves as follows:

1. If A has any children that inhibit run-in behavior (see below), then A is rendered as if it had ‘display: block’.
2. Let B be the first of A's following siblings that is neither floating nor absolutely positioned nor has ‘display: none’. If B exists and has a specified value for ‘display’ of ‘block’ or ‘list-item’ and is not replaced, then A is rendered as an ‘inline’ element at the start of B's principal box. Note: A is rendered before B's ‘:before’ pseudo-element, if any. See [CSS3GENCON].
3. Otherwise, A is rendered as if it had ‘display: block’.

In the above, “siblings” and “children” include both normal elements and :before/:after pseudo-elements.

An element or pseudo-element C inhibits run-in behavior if one or more of the following are true. (Note that the definition is recursive.)

• C is not floating and not absolutely positioned and the computed value of its ‘display’ is one of ‘block’, ‘list-item’, ‘table’ or ‘run-in’.
• C has a computed value for ‘display’ of ‘inline’ and it has one or more children that inhibit run-in behavior. (Where “children” includes both normal elements and :before/:after pseudo-elements.)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
  <HEAD>
    <TITLE>A run-in box example</TITLE>
    <STYLE type="text/css">
      H3 { display: run-in }
    </STYLE>
  </HEAD>
  <BODY>
    <H3>A run-in heading.</H3>
    <P>And a paragraph of text that
       follows it.
  </BODY>
</HTML>

A run-in heading. And a
paragraph of text that 
follows it.

Despite appearing visually as part of the following block box, a run-in element still inherits properties from its parent in the source tree. It is undefined in level 2 if a run-in inherits from a ‘:first-line’ pseudo-element. How about in level 3?

7.5. Compact boxes

Define here or in extended box module?

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.

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

dl[compact] dt {display: compact}

Whether a compact box C is displayed as a block or in the margin is determined as follows. Let N be the next sibling element in document order in the same flow as C, if any. Let W be the hypothetical distance between the startside margin edge and endside margin edge of C if the ‘display’ property of C were set to ‘block’ and any ‘auto’ on its inline dimension were replaced by ‘fit-content’.

• If there is no such N, then C is displayed as a block.
• If N has a ‘display’ of ‘list-item’, then C is displayed as a block.
• If N is not block-level, then C is displayed as a block.
• If the startside margin of N is less than W, then C is displayed as a block.
• Otherwise, C is displayed in the margin.

If C is displayed as a block, it is a block-level element and it is sized and positioned exactly as if its ‘display’ had been ‘block’.

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

Do we do anything to avoid that floats overlap with C? Do we do anything if C is taller than N? E.g., adjust the ‘min-height’ of N?

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

8. The padding properties

Sets the thickness of the padding area. The value may not be negative.

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

Note that percentages on ‘padding-top’ and ‘padding-bottom’ are relative to the width of the containing block, not the height (at least in a horizontal flow; in a vertical flow they are relative to the height).

Note that percentages are not required for CSS level 2.

h1 { padding: 0.5em }
h1 { padding-top: 0.5em;
     padding-right: 0.5em;
     padding-bottom: 0.5em;
     padding-left: 0.5em }

p { font-size: 10pt;
    padding-left: 2em;
    padding: -11pt;
    padding-left: calc(1em - 11pt)
}

9. Margins

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

9.1. The margin properties

<stretch> = fill( [ <length>  | <percentage> ] )

<stretch> = fill

These properties set the thickness of the margin area. The value may be negative.

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

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

Margins must satisfy certain constraints, which means that the used value may be different from the computed value. See “Calculating widths, heights and margins.” The meaning of ‘auto’ is also explained there.

Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width).

p { margin: 1em 2em }
p { margin-top: 1em;
    margin-right: 2em;
    margin-bottom: 1em;
    margin-left: 2em }

9.2. Collapsing margins

Certain adjoining margins, as defined in this section, combine to form a single margin. Those margins are said to collapse. Margins are adjoining if there are no nonempty content, padding or border areas or clearance to separate them.

p { display: block; margin-bottom: 2em 0 1em 0 }
div { display: block; margin: 2.5em 0 }
...
<p>First paragraph</p>
<div>
  <p>Second paragraph</p>
</div>

p { display: block; margin: 2em 0 1em 0 }
div { display: block; margin: 2.5em 0;
      border: thin solid }
...
<p>First paragraph</p>
<div>
  <p>Second paragraph</p>
</div>

If a set of adjoining margins collapses, then the width of the resulting margin is M - N, where M is the maximum of the adjoining margins that are positive, or zero if there are none; and N is the minimum of the adjoining margins that are negative, or zero if there are none.

We call an element or box collapsed through if two of its margins collapse with each other.

<p>First paragraph
<p>Second paragraph
<p>
<p>Last paragraph

The following two sets of rules determine which margins collapse.

• Only margins of block-level boxes can collapse.
• Margins of a floated box do not collapse with any other margins.
• Margins of a flow root do not collapse with its children's margins.
• Margins of an absolutely positioned box (see [CSS3POS]) do not collapse with any other margins.
• Margins of the root element's box do not collapse with any other margins.
• If a box is collapsed through and it has clearance 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.
• If a horizontal element has a ‘height’ that is not ‘auto’, or if setting its ‘min-height’ and ‘max-height’ to their initial values would change its used height, then the tail margin of the element does not collapse with any of its children's margins. [Check with latest CSS 2.1 if min/max width/height still have this effect.]
• Similarly, if a vertical element has a ‘width’ that is not ‘auto’, or if setting its ‘min-width’ and ‘max-width’ to their initial values would change the used width, then the tail margin of the element does not collapse with any of its children's margins. [Check with latest CSS 2.1 if min/max width/height still have this effect.]

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

• If a margin P collapses with a margin Q and margin Q with a margin R, then P, Q and R collapse together. (“Collapsing is transitive”)

• A margin of a box collapses with the head margin of its parent box if those two margins are adjoining.

• A margin of a box collapses with the tail margin of its parent box if those two margins are adjoining.

• The head margin of a box collapses with the tail margin of a sibling box if the two margins are adjoining.

• The top and bottom margins of a box A collapse with each other if the two margins are adjoining and the parent box B is horizontal. (The box is “collapsed through.”)

• The left and right margins of a box A collapse with each other if the two margins are adjoining and the parent box B is vertical. (The box is “collapsed through.”)

If a box A is collapsed through and it has the same mode as its parent (i.e., both are horizontal or both are vertical), then the position of its head border edge is defined as follows.

• If the box A's margins are collapsed with its parent's head margin, the head border edge of A is defined to be the same as the parent's head border edge.
• Otherwise, either the parent is not taking part in the margin collapsing, or only the parent's tail margin is involved. The position of A's head border edge is defined to be the same as it would have been if A had a nonzero tail border.

Note that box A 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 A.

<p style="margin-bottom: 2em">The bottom margin of this
box…</p>

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

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

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

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

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

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.

10. The width and height properties

These properties specify the width and height of the content area or border area (depending on ‘box-sizing’) of certain boxes.

Values have the following meanings:

<length>

Specifies the size using a length unit. Negative values are illegal. If the keyword ‘border-box’ is present, the length sets the size of the border box; if ‘content-box’ is present, it sets the size of the content box; if neither is present, the ‘box-sizing’ property determines which size is set.

<percentage>

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 containing block. Negative percentages are illegal. If the containing block's width, resp. height depends on this element, then the percentage is relative to ‘100vw’, resp. ‘100vh’. If the keyword ‘border-box’ is present, the percentage sets the size of the border box; if ‘content-box’ is present, it sets the size of the content box; if neither is present, the ‘box-sizing’ property determines which size is set.

available

Equal to the containing block width or height minus the current element's margin, border, and padding. If the required width, resp. height of the containing block is unknown (depends on this element), then ‘available’ is equal to ‘100vw’, resp. ‘100vh’.

max-content

The intrinsic preferred width or height.

min-content

The intrinsic minimum width or height.

fit-content

Equal to max(‘min-content’, min(‘max-content’, ‘available’)).

auto

The width or height depends on the values of other properties. See Calculating widths, heights and margins below.

complex

(Only on ‘height’.) The same as ‘auto’, except that elements with a complex aspect ratio are considered to have an intrinsic ratio. More precisely: for the purposes of the section on “Calculating widths, heights and margins,” the element is treated as if its height was ‘auto’ and it had an intrinsic ratio.

Another possible value is <non-negative-number>, which would mean ‘min-content’ times that number.

Note that ‘available’, ‘max-content’, ‘min-content’, ‘fit-content’, ‘border-box’, ‘content-box’ and ‘complex’ do not exist in level 2.

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, even if ‘box-sizing’ is ‘border-box’.

‘Available’, ‘max-content’, ‘min-content’ and ‘fit-content’ only have effect in the inline progression direction: when ‘writing-mode’ is ‘tb’ and these keyword are set on ‘height’, they act like ‘auto’; ditto when ‘writing-mode’ is something else and the keywords are set on ‘width’.

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.

p { width: 100px }

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}

<div>
  <p class=available>available: as wide as parent.
  <p class=min-content>min-content: as narrow as possible.
  <p class=max-content>max-content: As wide as needed, even
    if that means wider than the parent.
  <p class=fit-content>fit-content: As wide as needed.
  <p class=fit-content>fit-content: As wide as needed, but
    no wider than the parent.
  <p class=float>auto: depends on flow (=float).
  <p class=auto>auto: depends on flow (=normal).
</div>

div.side {
    width: 48%;
    width: 50% border-box }

div.side {
    width: 50%;
    box-sizing: border-box }

11. The min-width, max-width, min-height and max-height properties

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

<length>

Specifies a fixed minimum or maximum for ‘width’ or ‘height’. Negative values are illegal.

<percentage>

Specifies a minimum or maximum for ‘width’ or ‘height’ as a percentage of the corresponding dimension of the containing block. 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. Or: use the initial value?

max-content

The intrinsic preferred width or height.

min-content

The intrinsic minimum width or height.

available

The containing block width or height minus margin, border, and padding.

fit-content

For ‘max-width’/‘max-height’, same as ‘max-content’. For ‘min-width’/‘min-height’, same as ‘min-content’.

none

No limit on the width or height of the box.

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, even if ‘box-sizing’ is ‘border-box’.

‘Available’, ‘max-content’, ‘min-content’ and ‘fit-content’ only have effect in the inline progression direction: when ‘writing-mode’ is ‘tb’, keyword values on ‘min-height’ and ‘max-height’ act like ‘0’ and ‘none’, resp., and when ‘writing-mode’ is something else, keyword values on ‘min-width’ and ‘max-width’ act like ‘0’ and ‘none’, resp.

12. Definition of intrinsic sizes – high quality

The size of a box often depends on the width or height of its content. This section defines two measures of that size: the intrinsic preferred width (IPREF) is, roughly, the size the content would have if no “soft” line breaks were inserted; the intrinsic minimum width (IMIN) is, roughly, the narrowest the box can get by breaking all lines at all possible places. Or stated another way: they are the largest width that the content can usefully fill and the smallest width that the content can fit in without unintended overflow.

The intrinsic minimum width (IMIN) of a horizontal, non-replaced element E is defined as the smallest length ≥ 0 such that

OVERFLOW(E,IMIN) ≤ OVERFLOW(E,w) for all w ≥ 0

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

OVERFLOW(E,w) = W - w

The intrinsic preferred width (IPREF) of a horizontal, non-replaced element E is defined as the smallest length ≥ 0 such that

HEIGHT(E,IPREF) ≤ HEIGHT(E,w) for all w ≥ 0

and

HEIGHT(E,IPREF) < HEIGHT(E,w) or OVERFLOW(E,IPREF) ≤ OVERFLOW(E,w) for all w ≥ 0

where HEIGHT(E,w) is defined as follows. Set the ‘display’ of E to ‘block’, ‘float’ to ‘none’, ‘position’ to ‘static’, ‘overflow’ to ‘visible’, ‘min-width’ to ‘0’, ‘max-width’ to ‘none’, ‘height’ to ‘auto’, ‘min-height’ to ‘0’, ‘max-height’ to ‘none’ and ‘width’ to w. Then HEIGHT(E,w) is the height as defined below in “Auto heights for flow roots.”

OVERFLOW is not necessarily monotonic in w and a binary search for IMIN and IPREF may thus fail.

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

We probably want a definition that gives the same result in easy cases (only inline content) but is quicker to compute in complex cases.

13. Definition of intrinsic sizes – low quality

UA's may also, if speed is preferred over quality, use the approximate intrinsic minimum width (AMIN) instead of IMIN and the approximate intrinsic preferred width (APREF):

AMIN = max(W₁,W₂,W₃,W₄)
APREF = max(P₁,P₂,P₃,P₄)

where

W₁

Break the text content of E at all possible break points and find the width W₁ of the widest stretch of unbreakable text. Break points are determined as normal, i.e., taking ‘white-space’ into account and using language-dependent information, such as whether hyphens are added after a break. If ‘text-indent’ applies to the text, add its value to the first stretch (which may thus get a negative width, if ‘text-indent’ is sufficiently negative). If there is no text, or if the widest stretch has a negative width, then W₁ is set to 0.

W₂

Let W₂ be the largest of the widths of the margin boxes of all replaced child elements that have an intrinsic width, a ‘position’ of ‘static’ or ‘relative’, and a ‘display’ other than ‘none’. If there are no such children, or if the largest width is negative, W₂ is 0.

W₃

(Recursively) determine the AMIN_i of all horizontal, non-replaced child elements C_i with a ‘position’ of ‘static’ or ‘relative’ and a ‘display’ other than ‘none’. Let w_i be the sum of AMIN_i and the left and right margins, padding and border of C_i. Then W₃ is the largest of those w_i. If there are no such child elements, or if the largest w_i is negative, then W₃ is 0.

W₄

Let W₄ be the largest of the widths of the margin boxes of all vertical, non-replaced child elements with ‘position’ either ‘static’ or ‘relative’, ‘display’ other then ‘none’ and ‘width’ set to a <length>. If there are no such elements, or if the largest of the widths is negative, then W₄ is 0. Note that this calculation does not require looking at the contents of elements.

P₁

… [Define inline formatting contexts as longest sequences of text and elements without hard line breaks or blocks?]

Note that several kinds of child elements are ignored for the calculation of AMIN, e.g., vertical elements with ‘width’ of ‘auto’. Also, tables aren't laid out.

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

14. Calculating widths, heights and margins

The following two algorithms define the used value of ‘width’ and ‘height’ respectively and also the used values of the ‘margin’ properties and of ‘top’, ‘right’ ‘bottom’ and ‘left’.

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,

For ‘width’:

1. The tentative used width is calculated following the rules in the subsections below. If ‘transform’ is not ‘none’, it is assumed to be ‘rotate(0)’ (i.e., the identity transform) for the purposes of this calcutlation.
2. 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’.
3. 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’.

For ‘height’:

1. The tentative used height is calculated following the rules in the sections below. If ‘transform’ is not ‘none’, it is assumed to be ‘rotate(0)’ (i.e., the identity transform) for the purposes of this calcutlation.
2. 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’.
3. 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’.

If ‘transform’ is not ‘none’, the used width or height is further modified as follows:

• If the element is horizontal and ‘height’ is ‘auto’, then the used height is the height of the content box after the transformation is applied.
• If the element is vertical and ‘width’ is ‘auto’, then the used width is the width of the content box after the transformation is applied.

Note that translations [CSS3-2D-TRANSFORMS] do not affect the width or height and also do not affect the placement of boxes in the normal flow (see “Basic flow layout” ).

However, for replaced elements with an intrinsic ratio and both ‘width’ and ‘height’ specified as ‘auto’, the algorithm is as follows:

Select from the table the resolved height and width values for the appropriate constraint violation. Take the max-width and max-height as max(min, max) so that min ≤ max holds true. In this table w and h 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.

Then apply the appropriate rules in the subsections below, as if ‘width’ and ‘height’ were computed as these values.

Note that some values of the ‘image-scaling’ property ([CSS3PAGE]) may further change the used values of ‘width’ and ‘height’.

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

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

14.1. Inline, non-replaced elements

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’ by 0.

Note that this section applies equally when the containing block is horizontal as when it is vertical.

14.2. Inline or floating, replaced elements

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

If ‘height’ and ‘width’ both have computed values of ‘auto’ and the element also has an intrinsic width, then that intrinsic width is the used value of ‘width’.

If ‘height’ and ‘width’ both have computed values of ‘auto’ and the element also has an intrinsic height, then that intrinsic height is the used value of ‘height’.

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:

(used height) * (intrinsic ratio)

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:

(used width) / (intrinsic ratio)

If ‘height’ and ‘width’ both have computed values of ‘auto’ and the element has an intrinsic ratio but no intrinsic height or width 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 constraint equation used for block-level, non-replaced elements in normal flow. The used value for ‘height’ is: (used width) / (intrinsic ratio).

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

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

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.

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.

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

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.

Note that this section applies equally when the containing block is horizontal as when it is vertical.

14.3. Block-level, non-replaced elements in normal flow when ‘overflow’ computes to ‘visible’

This section also applies to block-level non-replaced elements in normal flow when ‘overflow’ does not compute to ‘visible’ but has been propagated to the viewport.

The used values of the head padding, tail padding, head margin and tail margin are calculated from their computed values, with any ‘auto’ values replaced by 0.

If the computed value of the block flow dimension is not ‘auto’, then the used value is calculated by evaluating the computed value. Otherwise, the block flow dimension is the distance between two edges that are defined as follows:

• For the first edge: If the element is the root element or if it has a non-zero head padding or a non-zero head border, then the first edge is the headside margin edge of the first line box or block-level box (whichever comes first); otherwise the first edge is the headside border edge of the first line box or block-level box (whichever comes first) that doesn't have its margins collapsed through.
• For the second edge: If the element is the root element or if it has a non-zero tail padding or a non-zero tail border, then the second edge is the tailside margin edge of the last line box or block-level box (whichever comes last); otherwise the second edge is the tailside border edge of the last line box or block-level box (whichever comes last) that doesn't have its margins collapsed through.

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.

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 {border-bottom: 0.2em dashed}
img {height: 3em; display: block; margin: 1em}
...
<div>
  <img src="img1" alt=...>
  <img src="img2" alt=...>
</div>

With respect to the inline dimension, the following constraint must hold among the used values of the given properties.

start margin + start border + start padding + inline dimension + end padding + end border + end margin = inline dimension of containing block

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 inline dimension negative, then set its used value to 0. Ditto for start padding and end padding. Note that such negative values can only happen when the specified value includes ‘calc()’. Then apply one of the following cases:

1. If none of the values is ‘auto’, then there are three sub-cases:

   1. If the current element's ‘alignment’ is ‘center’, then the used values of start margin and end margin are set so that they are the same and the constraint is satisfied.
   2. If ‘alignment’ corresponds to the end edge, then the used value of the end margin is set to the value that satisfies the constraint.
   3. If ‘alignment’ has any other value, then the used value of the start margin is set to the value that satisfies the constraint.
2. If the inline dimension 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 inline dimension so that the constraint is satisfied. If that makes the used value negative, then set it to 0 instead and apply case 1 above.
3. If both the start and end margins are ‘auto’, and ‘alignment’ is ‘center’, then solve the constraint under the extra condition that the start and end margin are equal.
4. If both the start and end margins are ‘auto’, and ‘alignment’ is not ‘center’, then solve the constraint under the extra condition that the start and end margins are equal. But if that makes them negative, then set both to 0 and apply case 1 above.
5. If only the start margin is ‘auto’ and ‘alignment’ corresponds to the end edge, then set the start margin to the value that satisfies the constraint.
6. If only the start margin is ‘auto’ and ‘alignment’ does not correspond to the end edge, then set the start margin to the value that satisfies the constraint. But if that makes it negative, then set it to 0 instead and apply case 1 above.
7. If only the end margin is ‘auto’ and ‘alignment’ corresponds to the start edge, then set the end margin to the value that satisfies the constraint.
8. If only the end margin is ‘auto’ and ‘alignment’ does not correspond to the start edge, then set the end margin to the value that satisfies the constraint. But if that makes it negative, then set it to 0 instead and apply case 1 above.

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

Note also that only ‘alignment: center’ guarantees proper centering. Setting the margins to ‘auto’ only centers blocks if they are narrower than their containing block, because only one of the two margins is allowed to become negative.

<div>
  <p>A paragraph here.
</div>

p {alignment: right}

p {alignment: center}

p {margin-left: auto; margin-right: auto; alignment: center}

p {margin-left: auto; alignment: left}

p {margin-right: auto; alignment: right}

p {margin-right: 2em; alignment: right}

p {margin-right: 2em; margin-left: 4em; alignment: right}

14.4. Other block-level, non-replaced elements in normal flow

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

The used values of head padding, tail padding, head margin and tail margin are calculated from the computed values, with any ‘auto’ values replaced by 0.

If the block flow dimension is ‘auto’, the used value is defined by “‘Auto’ heights for flow roots.” Otherwise, the used value is evaluated from the computed value.

Apply the rules for start margin, start padding, inline dimension, end padding and end margin as given above in “Block-level, non-replaced elements in normal flow when ‘overflow’ computes to ‘visible’.”

14.5. ‘Inline-block’ or floating, non-replaced elements

Not yet generalized with head, tail, etc.

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.

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.

If the computed value of ‘height’ is ‘auto’, the used value is defined by “‘Auto’ heights for flow roots.” 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 “‘Auto’ heights for flow roots.” Otherwise it is calculated by evaluating the computed value.

For inline-block boxes, the margin box is used when calculating the height of the line box. Does this belong here?

14.6. Absolutely positioned, non-replaced elements

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

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

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

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.

This constraint must hold among the used values:

‘left’ + ‘margin-left’ + ‘border-left-width’ + ‘padding-left’ + ‘width’ + ‘padding-right’ + ‘border-right-width’ + ‘margin-right’ + ‘right’ = width of containing block

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 static position and apply rule number three below; otherwise, set ‘right’ to the static position and apply rule number one below.

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’). Should we remove the phrase starting with “unless”? 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.

Otherwise, set ‘auto’ values for ‘margin-left’ and ‘margin-right’ to 0, and pick the one of the following six rules that applies.

1. ‘left’ and ‘width’ are ‘auto’ and ‘right’ is not ‘auto’, then the width is as for ‘fit-content’. Then solve for ‘left’.
2. ‘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 static position, otherwise set ‘right’ to the static position. Then solve for ‘left’ (if ‘direction’ is ‘rtl’) or ‘right’ (if ‘direction’ is ‘ltr’).
3. ‘width’ and ‘right’ are ‘auto’ and ‘left’ is not ‘auto’, then the width is ‘fit-content’. Then solve for ‘right’.
4. ‘left’ is ‘auto’, ‘width’ and ‘right’ are not ‘auto’, then solve for ‘left’.
5. ‘width’ is ‘auto’, ‘left’ and ‘right’ are not ‘auto’, then solve for ‘width’.
6. ‘right’ is ‘auto’, ‘left’ and ‘width’ are not ‘auto’, then solve for ‘right’.

This constraint must also hold among the used values:

‘top’ + ‘margin-top’ + ‘border-top-width’ + ‘padding-top’ + ‘height’ + ‘padding-bottom’ + ‘border-bottom-width’ + ‘margin-bottom’ + ‘bottom’ = height of containing block

If all three of ‘top’, ‘height’, and ‘bottom’ are ‘auto’, set ‘top’ to the static position and apply rule number three below.

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.

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

1. ‘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 “‘Auto’ heights for flow roots.” 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’.
2. ‘top’ and ‘bottom’ are ‘auto’ and ‘height’ is not ‘auto’: The used value of ‘top’ is its static position. 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’.
3. ‘height’ and ‘bottom’ are ‘auto’ and ‘top’ is not ‘auto’: The used height is defined by “‘Auto’ heights for flow roots.” 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’.
4. ‘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’.
5. ‘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’.
6. ‘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’.

14.7. Absolutely positioned, replaced elements

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:

1. The used value of ‘width’ and ‘height’ is determined as for inline replaced elements.
2. 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.
3. 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 static position; else if ‘direction’ is ‘rtl’, the used value of ‘right’ is its static position.
4. If both ‘top’ and ‘bottom’ have the value ‘auto’, then the used value of ‘top’ is its static position.
5. If ‘left’ or ‘right’ (or both) are ‘auto’, and ‘margin-left’ is ‘auto’, then the used value of ‘margin-left’ is 0.
6. If ‘left’ or ‘right’ (or both) are ‘auto’, and ‘margin-right’ is ‘auto’, then the used value of ‘margin-right’ is 0.
7. 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. Remove the part starting with “unless”? It looks better to center the image.

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

‘left’ + ‘margin-left’ + ‘border-left-width’ + ‘padding-left’ + ‘width’ + ‘padding-right’ + ‘border-right-width’ + ‘margin-right’ + ‘right’ = width of containing block

‘top’ + ‘margin-top’ + ‘border-top-width’ + ‘padding-top’ + ‘height’ + ‘padding-bottom’ + ‘border-bottom-width’ + ‘margin-bottom’ + ‘bottom’ = height of containing block

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.

If the second equation is over-constrained, ignore the value for ‘bottom’ and solve for that value.

14.8. Block-level, replaced elements in normal flow

Apply the rules for inline replaced elements, but ignore the resulting values for ‘margin-left’ and ‘margin-right’. To compute the used value of those, apply the rules for block-level, non-replaced elements using the used values just found for ‘width’, ‘border’ and ‘padding’ as if they were the computed values.

14.9. Floating, non-replaced elements

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

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

If the computed value of ‘height’ is ‘auto’, the used value is given by “‘Auto’ heights for flow roots.” 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.

14.10. Auto heights for flow roots

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

If it only has inline-level children, the height is the distance between the top of the topmost line box and the bottom of the bottommost line box.

If it has block-level children, the height is the distance between the top margin-edge of the topmost block-level child box and the bottom margin-edge of the bottommost block-level child box.

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

In addition, if the element has any floating descendants whose bottom margin edge is below the 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.

15. The float property

Adding ‘start’ and ‘end’ was decided at 2009-12-02 telcon. Precide definitions not yet decided: does it depend on ‘direction’ of the element itself or its parent?

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

The ‘float’ property in turn influences the computed value of ‘display’. See “The display property.”

The values of this property have the following meanings:

top

Same as ‘left’

left

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

bottom

same as ‘right’

right

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.

start

If the ‘direction’ property is ‘ltr’, the same as ‘left’; otherwise the same as ‘right’.

end

If the ‘direction’ property is ‘rtl’, the same as ‘right’; otherwise the same as ‘left’.

none

The box is not floated.

<page-floats>

See Generated Content for Paged Media [CSS3GCPM]. Check that the names page-top, page-bottom, next-top, or otherwise do not clash with top and bottom

contour

Text is flowed around the actual shape of the element rather than around its margin box. Only applies if the element is a replaced element without a border and without padding. See under ‘float-displace’ for how it affects text flow.

User agents may treat float as ‘none’ on the root element.

The exclusion zone of a floating element is, roughly, the area that text may not intrude into when it flows around a float. More precisely, given a point P and a floating element F, the following determines if P is inside or outside the exclusion zone of F:

• If F is a replaced element and its value of ‘float’ includes the keyword ‘contour’ and F has no border and no padding:

  • If F is a horizontal element:

    • If ‘float’ is ‘left’ or ‘top’, then P is inside the exclusion zone of F iff P or any point to the right of P on a horizontal line through P is a in a non-transparent area of F.

    • If ‘float’ is ‘right’ or ‘bottom’, then P is inside the exclusion zone of F iff P or any point to the left of P on a horizontal line through P is a in a non-transparent area of F.

  • If F is vertical:

    • If ‘float’ is ‘left’ or ‘top’, then P is inside the exclusion zone of F iff P or any point below P on a vertical line through P is a in a non-transparent area of F.

    • If ‘float’ is ‘right’ or ‘bottom’, then P is inside the exclusion zone of F iff P or any point above P on a vertical line through P is a in a non-transparent area of F.

• If F is not a replaced element, or if ‘float’ does not include the keyword ‘contour’, or if F has a border or a padding:

  • If F is horizontal:

    • If ‘float’ is ‘left’ or ‘top’, then P is inside the exclusion zone of F iff P or any point to the right of P on a horizontal line through P is inside the margin area of F.

    • If ‘float’ is ‘right’ or ‘bottom’, then P is inside the exclusion zone of F iff P or any point to the left of P on a horizontal line through P is inside the margin area of F.

  • If F is vertical:

    • If ‘float’ is ‘left’ or ‘top’, then P is inside the exclusion zone of F iff P or any point below P on a vertical line through P is inside the margin area of F.

    • If ‘float’ is ‘right’ or ‘bottom’, then P is inside the exclusion zone of F iff P or any point above P on a vertical line through P is inside the margin area of F.

Non-transparent in this case means anything other than fully transparent. E.g., an area that is 90% transparent is non-transparent.

Note that the ‘margin’ is ignored for the purposes of determining the exclusion zone if ‘contour’ is used. To create a visual “margin” around an image, an author can instead include an area in the image that is 99% transparent.

It might occasionally be nice to be able to give that “margin” a thickness in em without scaling the whole image, but that is a difficult operation…

Replaced elements can be handled by plug-ins and the plug-in API may not provide access to the contour of the object. Should there be a sentence about UAs not having to compute a contour in such a case?

15.1. Introduction to floats

(This section is not normative.)

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

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.

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.

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, line boxes 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.

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

...

<p>
  <span> </span>
  Supercalifragilisticexpialidocious
</p>

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

img.icon { 
  float: left;
  margin-left: 0;
}

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

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

As stated in “Collapsing margins,” the margins of floating boxes never collapse with margins of adjacent boxes. Thus, in the previous example, vertical margins do not collapse between the P box and the floated IMG box.

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.

The following example illustrates the use of the ‘clear’ property to prevent content from flowing next to a float.

p { clear: left }

15.2. Rules for positioning floats

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

1. The left margin edge of a left-floating box may not be to the left of the left edge of its containing block. An analogous rule holds for right-floating elements.
2. 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 margin edge of the current box must be to the right of the right margin edge of the earlier box, or its top must be lower than the bottom of the earlier box. Analogous rules hold for right-floating boxes.
3. The right margin edge of a left-floating box may not be to the right of the left margin edge of any right-floating box that is to the right of it. Analogous rules hold for right-floating elements.
4. A floating box's top margin edge may not be higher than the top of its containing block. When the float occurs between two collapsing margins, the float is positioned as if it had an otherwise empty anonymous block parent taking part in the flow. The position of such a parent is defined by the rules in the section on margin collapsing.
5. The top margin edge of a floating box may not be higher than the margin top of any block-level or floated box generated by an element earlier in the source document.
6. The top margin edge of an element's floating box may not be higher than the top of any line-box containing a box generated by an element earlier in the source document.
7. 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.
8. A floating box must be placed as high as possible.
9. 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.

<P>a<SPAN style="float: right">b</SPAN></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:

[Still some words like lower and higher to replace...]

1. The top margin edge of a top-floating box may not be above the top edge of its containing block. An analogous rule holds for bottom-floating elements.
2. 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 margin edge of the current box must be below the bottom margin edge 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.
3. The bottom margin edge of a top-floating box may not be below the top margin edge of any bottom-floating box that is below it. Analogous rules hold for bottom-floating elements.
4. A floating box's right margin edge may not be to the right of the right edge of its containing block. When the float occurs between two collapsing margins, the float is positioned as if it had an otherwise empty anonymous block parent taking part in the flow. The position of such a parent is defined by the rules in the section on margin collapsing.
5. The right margin edge of a floating box may not be to the right of the right margin edge of any block-level or floated box generated by an element earlier in the source document.
6. The right margin edge of an element's floating box may not be to the right of the right edge of any line-box containing a box generated by an element earlier in the source document.
7. 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.
8. A floating box must be placed as far to the right as possible.
9. 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.

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:

[...]

Note that a box with a value of ‘float’ other than ‘none’ is a flow root.

The border box of a table, a block-level replaced element, or an element in the normal flow that is a flow root (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, by increasing one margin and decreasing the opposite margin. (“Sufficient space” means that the opposite margin does not become negative.)

16. The clear property

[To do: copy from CSS2 [CSS21] and generalize to vertical text, define clearance.]

17. The clear-after property

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 there are any floats in the current flow up to and including the end of this element that float to the indicated side(s), then find the one whose tailside margin edge is furthest away from the head content edge of the containing block. Then increase the tailside padding of the current element by the minimum amount needed so that the padding edge is at least as far away from the head content edge of the containing block as the tailside margin edge of that float.

Note: Since a floating element is a flow root, setting ‘clear-after’ on such an element only takes into account any descendant floats in the flow established by the element itself.

The value of the property determines which kinds of floats are taken into account:

none

No effect.

left, top

Only left and top floating elements are considered.

right, bottom

Only right and bottom floating elements are considered,

inside

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

outside

Analogous

start

If the ‘direction’ of the element is ‘ltr’, same as ‘left’, otherwise same as ‘right’.

end

If the ‘direction’ of the element is ‘ltr’, same as ‘right’, otherwise same as ‘left’.

both

Both left/top and right/bottom floats are considered.

descendants

All floats in the element's flow that are descendants of the element are considered, but not any other floats.

Use only two values: height-includes-floats and height-does-not-include floats? [DavidB 2004-02-29]

section {clear: left right after}

Daniel Beardsmore proposed a property ‘underhang-limit: <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.

18. Overflow

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

18.1. The overflow, overflow-x and overflow-y properties

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

These properties specify whether content is clipped when it overflows the element's content area. 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.

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

visible

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

hidden

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

scroll

This value indicates that the content is clipped and that if the user agent uses a scrolling mechanism 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.

auto

The behavior of the ‘auto’ value is UA-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes.

no-display

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 <tillh@opera.com>, July 21, 2005]

no-content

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 <tillh@opera.com>, July 21, 2005]

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

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

The para above is from CSS 2.1. Need to check if the introduction of overflow-x/y changes anything.

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.

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.

Note that a box with ‘overflow’ other than ‘visible’ is a flow root.

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

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
       }

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

<container>
 <scroller>
  <satellite/>
  <body/>
 </scroller>
</container>

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 without 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 is needed.

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

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

The scrolling mechanism 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.

Note that ‘overflow-x’ and ‘overflow-y’ did not exist in CSS2.

Note that ‘text-overflow’ (see [CSS3TEXT]) can be used to give a visual indication where text has been clipped.

19. The visibility property

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:

visible

The generated box is visible.

hidden

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

collapse

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

20. The alignment property

Another way to allow real centering of boxes would be to allow ‘margin: any’ (or ‘margin: fill’ or some other keyword that suggest “as large as possible, even if that means negative”) with the meaning that ‘margin: auto’ had before CSS 2.1. See also ACTION-18 (especially the ideas at end of Bert's comment ), which is continued in ISSUE-53.

For consistency with ‘text-align’, maybe this should be called ‘block-align’.

This property influences how a block in the normal flow is aligned in its parent in the inline progression direction. It affects the used values of ‘margin-left’ and ‘margin-right’ (for horizontal blocks) or ‘margin-top’ and ‘margin-bottom’ (for vertical blocks), as defined in “Calculating widths, heights and margins.”

The initial value depends on both ‘writing-mode’ and ‘direction’, as follows:

Note that this property doesn't exist in level 2.

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

<p>Lorem ipsum dolor sit amet...
<h2>A section heading</h2>
<p>Lorem ipsum dolor sit amet...
<h2>Another section heading</h2>
<p>Lorem ipsum dolor sit amet...

A possible rendering of the example.

21. The child-align property

Other names: block-align (but note that it influences the children of the block, not the block itself), block-vertical-align (but note that it really means horizontal if the block's ‘writing-mode’ is ‘lr’ or ‘rl’).

Another way to allow centering and other alignments of boxes would be to allow ‘margin: any’ (or ‘margin: fill’ or some other keyword). See the explanation at the end of Bert's comment on ACTION-18. This is ISSUE-53.

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

top, bottom, left, right

Child blocks are aligned in the current block depending on the ‘child-align’ and ‘writing-mode’ as follows:

	top	bottom	left	right
tb	top	bottom	top	top
rl	right	right	left	right
lr	left	left	left	right

middle

Child blocks are centered in the block progression direction.

auto

Child blocks are aligned according to ‘writing-mode’: at the top if ‘tb’, at the right if ‘rl’ and at the left if ‘lr’.

An element with ‘child-align’ values other than ‘auto’ is a flow root. Content of such a block is formatted as follows:

1. Content is laid out as a regular sequence of blocks.
2. To be discussed: If the smallest rectangle that encloses all margin boxes of the children (excluding absolutely positioned children and counting relatively positioned children as if they had zero offset) is bigger in the block progression direction than the content box of the current element, then the content is placed in that content box as if ‘child-align’ were ‘top’.
3. The content is shifted such that the rectangle that encloses all margin boxes of the children (excluding absolutely positioned children and counting relatively positioned children as if they had zero offset) touches an edge of the content box. Which edge of the rectangle and which edge of the content box is determined by the table above. But if ‘child-align’ is ‘middle’, the rectangle is instead centered in the content box.

div {child-align: bottom}

div {grid: "a"};
div::slot(a) {vertical-align: bottom}

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

Or, alternatively, ‘child-align’ doesn't apply to elements that ‘vertical-align’ applies to, i.e., only to ‘block’, ‘list-item’, ‘inline-block’ and ‘run-in’ (under circumstances).

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

22. Stacking contexts

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

22.1. Definitions

Tree Order

Preorder depth-first traversal of the rendering tree, in logical (not visual) order for bidirectional content, after taking into account properties that move boxes around such as the ‘run-in’ value of ‘display’.

Element

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

22.2. Painting order

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

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.

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.

The stacking order for an element generating a stacking context (see the ‘z-index’ property) is:

1. If the element is a root element:

   1. background color of element over the entire canvas.
   2. background image of element, over the entire canvas, anchored at the origin that would be used if it was painted for the root element.

2. If the element is a block, list-item, or other block equivalent:

   1. background color of element unless it is the root element.
   2. background image of element unless it is the root element.
   3. border of element.

   Otherwise, if the element is a block level table:

   1. table backgrounds (color then image) unless it is the root element.
   2. column group backgrounds (color then image).
   3. column backgrounds (color then image).
   4. row group backgrounds (color then image).
   5. row backgrounds (color then image).
   6. cell backgrounds (color then image).
   7. all table borders (in tree order for separated borders).

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

4. For all its in-flow, non-positioned, block-level descendants in tree order: If the element is a block, list-item, or other block equivalent:

   1. background color of element.
   2. background image of element.
   3. border of element.

   Otherwise, the element is a table:

   1. table backgrounds (color then image).
   2. column group backgrounds (color then image).
   3. column backgrounds (color then image).
   4. row group backgrounds (color then image).
   5. row backgrounds (color then image).
   6. cell backgrounds (color then image).
   7. all table borders (in tree order for separated borders).

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

6. If the element is an inline element that generates a stacking context, then:

   1. For each line box that the element is in:

      1. Jump to 7.2.1 for the box(es) of the element in that line box (in tree order).

7. Otherwise: first for the element, then for all its in-flow, non-positioned, block-level descendants in tree order:

   1. If the element is a block-level replaced element, then: the replaced content, atomically.

   2. Otherwise, for each line box of that element:

      1. For each box that is a child of that element, in that line box, in tree order:

         1. background color of element.

         2. background image of element.

         3. border of element.

         4. For inline elements:

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

               1. If this is a run of text, then:

                  1. 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).
                  2. 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).
                  3. the text.
                  4. 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).

               2. Otherwise, jump to 7.2.1 for that element.

            For inline-block and inline-table elements:

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

            For inline-level replaced elements:

            1. the replaced content, atomically.

         Some of the boxes may have been generated by line splitting or the Unicode bidirectional algorithm.

      2. Optionally, the outline of the element (see 10 below).

   3. Optionally, if the element is block-level, the outline of the element (see 10 below).

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

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

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

22.3. Notes

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

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 2.1, the exact result of these two requirements is UA-defined. CSS3 may define this in more detail. [Replace 2.1 by 3. Check if inline backgrounds are still undefined, otherwise say result is UA-dependent.]

22.4. The <number> value

A <number> value sets the width or height to that many times the intrinsic width resp. height of the element. The computed value is the number itself.

If a replaced element does not have an intrinsic size or if it has a complex relation between width and height, the used value for ‘width: N’ is N × W, where W is 300px or the largest width that fits the device, whichever is smaller; the used value for ‘height: N’ is N × W/2.

img {width: 50px}  /* exactly 50px wide */
img {width: 50%}   /* half as wide as the containing block */
img {width: 50em}  /* 50× the current font size */
img {width: auto}  /* the intrinsic size */
img {width: 1}     /* ditto, i.e., the intrinsic size */
img {width: 0.5}   /* half the intrinsic width */

Note that <number> does not exist in CSS level 2.

22.5. The auto value

We describe the meaning of ‘auto’ on elements that have horizontal flow. Vertical flow is analogous, but with the roles of ‘width’ and ‘height’ interchanged.

On a replaced element, the meaning of ‘auto’ depends on whether the element has an intrinsic size or not, as follows.

1. If the replaced element has an intrinsic width and an intrinsic height, then the used value for ‘width: auto’ is

   (intrinsic width)/(intrinsic height) × (used value for height),

   The used value for ‘height: auto’ is

   (intrinsic height)/(intrinsic width) × (used value for width),

   unless both ‘width’ and ‘height’ are ‘auto’, in which case the used value of the former is the intrinsic width and the used value of the latter is the intrinsic height.

2. If the element has an aspect ratio (but no intrinsic width or height, because then it would fall under the preceding case), then the used value for ‘width: auto’ is

   (aspect ratio) × (used value for height),

   The used value for ‘height: auto’ is

   (used value for width) / (aspect ratio),

   unless both ‘width’ and ‘height’ are ‘auto’, in which case the used width is 300px or the maximum width that fits the device, whichever is smaller; and the used height is (aspect ratio) × (used width).

3. If the element has an intrinsic width, but no intrinsic height and no aspect ratio (i.e., the height can be chosen freely), then the value used for ‘width: auto’ is the intrinsic width and the value used for ‘height: auto’ is 150px or half the maximum width that fits the device, whichever is smaller.

4. If the element has an intrinsic height, but no intrinsic width and no aspect ratio, then the value used for ‘height: auto’ is the intrinsic height and the value used for ‘width: auto’ is 300px or the maximum width that fits the device, whichever is smaller.

5. If the element has a complex relation between width and height, then the used value of ‘auto’ is the result of the algorithm below.

6. If the element has no intrinsic width, no intrinsic height, no aspect ratio and no relation between width and height, then the value used for ‘width: auto’ is 300px or the largest width that fits the device, whichever is smaller; and the value used for ‘height: auto’ is 150px or half the largest width that fits the device, whichever is smaller.

Examples of replaced elements with an intrinsic size are most raster images (PNG, JPEG, etc.) and certain SVG graphics. SVG graphics and other scalable images may also have just an aspect ratio and no intrinsic width or height. Certain SVG graphics may have neither an intrinsic size nor an aspect ratio; they adapt to any width and height. Examples of replaced elements with a complex relation between width and height are HTML files and objects that can only take certain discrete sizes, such as a command a line that must be a whole number of characters wide and high.

For non-replaced elements, ‘auto’ on ‘height’ is always the intrinsic height that corresponds to the element's computed width. The computed value of ‘auto’ on ‘width’ depends on the type of box:

1. If the element is a flow root other than the root element, width is the intrinsic width.
2. If the element is the root element on paged media, the value is the computed width value of the ‘size’ property.
3. Otherwise, if the element is a block-level element and its containing block also has a horizontal flow, equation (1) below determines the width.
4. Otherwise, if the element is block-level and the containing block has a different orientation, the computed value is the intrinsic width.
5. Otherwise (i.e., the element is positioned, is a table element or a ruby), see the positioning [CSS3POS], table [CSS3TBL] or ruby [CSS3RUBY] modules.

Note that in CSS2, floating elements (case 1) were given a certain small, UA-dependent width, but in CSS3 they are given their intrinsic width (often referred to as "shrink-wrapped").

‘Min-width’, ‘max-width’, ‘min-height’ and ‘max-height’ impose further constraints on the computed value. See below.

22.6. Algorithm for shrink-wrapping replaced elements with complex width/height

Should this algorithm be defined by CDF/WICD instead? Or by some plug-in API? If the replaced object has a complex relation between width and height, then the CSS UA cannot itself compute the value to use for ‘auto’ or ‘shrink-wrap’. Instead, the UA has to ask an external “oracle”. We assume there is a function that the CSS UA can call, which takes as input the following parameters:

• the object to compute the size of
• the computed value of ‘min-width’
• the computed value of ‘min-height’
• the computed value of ‘max-width’
• the computed value of ‘max-height’
• the computed value of ‘width’
• the computed value of ‘height’
• an auxiliary width
• an auxiliary height

Note that most can be of various types: <length>, <percentage>, ‘auto’, ‘shrink-wrap’ or ‘none’.

The auxiliary width is the width of the containing block minus this element's margin, padding and border, unless the containing block's width depends on this element's width, in which case the width of the viewport is given. The suggested height is analogous, but using the containing block's height.

The returned values are

• The object's preferred width (a <length>)
• The object's preferred height (a <length>)

If ‘width’ is ‘auto’ or ‘shrink-wrap’, the used width will be

max(min-width, min(preferred-width, max(min-width, max-width)))

If ‘height’ is ‘auto’ or ‘shrink-wrap’, the used height will be

max(min-height, min(preferred-height, max(min-height, max-height)))

If the used width is different from the preferred width, the UA may call the oracle again with the used width instead of the computed width in order to get a new value for the preferred height.

Note that the size of the box may still be different from the object's preferred size. Whether the object resizes to the box's size or not depends on the object. The ‘fit’ property determines how the object is positioned relative to the box if their sizes differ.

If a CSS UA is used as an oracle, it should behave as follows: The parameters should be interpreted as the corresponding style rules on the root element of the object (‘:root’) with specificity 1 at the start of the author style sheet. The auxiliary width and height should be interpreted as the size of the viewport.

...
<style type="text/css">
  object {display: block; width: 100%; height: shrink-wrap}
</style>
...
<object data="other.html">
  <p>See <a href="other.html">other</a> document.
</object>
...

Note that the oracle may need to have access to the whole object before computing its width and height. E.g., the height of a transcluded HTML file is only known after the whole file has been downloaded and formatted. Thus the use of ‘shrink-wrap’ may cause a delay in the rendering of a document, or may cause reflow if the oracle is called asynchronously.

Note that there was no concept of “complex width/height” in CSS level 2, so UAs that understand level 3 will use a different size for transcluded HTML files than UAs for level 2. In particular, level 2 UAs will render a 300 by 150px block with scrollbars instead of a block that is as big as neeeded to contain the transclusion.

23. The ‘float-displace’ property

Value:     auto | <length> && [ block | block-within-page ]?
Inherited: no

img {float: left}
ul {float-displace: 2em block}
li {margin-left: 2em}

<p>
  <img src=... alt=... style="float: left">
  Paragraph before the list.

<ul>
  <li>First item
  <li>Second item
</ul>

Paragraph before the list.

  * First item
  * Second item

+----+Paragraph before the list.
|\  /|
| */ |First item
| *\ |Second item
|/  \|
+----+

+----+Paragraph before the list.
|\  /|
| \/ |  * First item
| /\ |  * Second item
|/  \|
+----+

This property determines the line wrapping policy in the presence of floats. Values have the following meanings:

line

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.) [add description or image?]

indent

The distance between the margin edge of the floats and the start of the line box is set to the distance between the active reference indent edge (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.

Example of ‘float-displace: indent’. Note that the “bar” paragraph has the same indent (green arrow) next to the float as below it .

block

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.

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.

Example of ‘float-displace: block’

block-within-page

As for the ‘block’ value, but the determination of intrusions that adjust the width of the block is done separately on each page on which the block appears. Thus, the block may be narrowed on the first page due to one or more intrusions, but may expand (or contract) its width on subsequent pages with different intrusions. The computed value of the ‘width’ property for this case is...?

OL, UL, LI {float-displace: indent}
TABLE {float-displace: block}

24. The ‘indent-edge-reset’ property

This property determines which edge to use as the reference indent edge when calculating the amount of indent to preserve when the value of ‘float-displace’ is set to ‘indent’.

none

This block does not introduce a new reference edge.

margin-edge

border-edge

padding-edge

content-edge

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.

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.

25. Conformance and profiles

Levels 1, 2 and 3…

UAs that render must either support vertical elements or the ‘vertical’ media feature.

26. CR exit criteria

As described in the W3C process document, a Candidate Recommendation (CR) is a specification that W3C recommends for use on the Web. The next stage is “Recommendation,” when the specification is sufficiently implemented.

For this specification to be proposed as a W3C Recommendation, the following conditions shall be met. There must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:

independent

each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.

interoperable

passing the respective test case(s) in the official CSS test suite, or, if the implementation is not a Web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review.

implementation

a user agent which:

1. implements the specification.
2. is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or “nightly build”). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability.
3. is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward).

A minimum of sixth months of the CR period must have elapsed. This is to ensure that enough time is given for any remaining major errors to be caught.

Features will be dropped if two or more interoperable implementations are not found by the end of the CR period.

Features may/will also be dropped if adequate/sufficient (by judgment of CSS WG) tests have not been produced for those feature(s) by the end of the CR period.

27. Acknowledgments

To do…

References

Normative references:

[CSS21]

Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-CSS2-20110607

[CSS3-2D-TRANSFORMS]

Simon Fraser; et al. CSS 2D Transforms. 15 December 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-css3-2d-transforms-20111215/

[CSS3-WRITING-MODES]

Elika J. Etemad; Koji Ishii. CSS Writing Modes Module Level 3. 1 May 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/

[CSS3BG]

Bert Bos; Elika J. Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 17 April 2012. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/CR-css3-background-20120417/

[CSS3GENCON]

Ian Hickson. CSS3 Generated and Replaced Content Module. 14 May 2003. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2003/WD-css3-content-20030514

[CSS3SYN]

L. David Baron. CSS3 module: Syntax. 13 August 2003. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2003/WD-css3-syntax-20030813

[CSS3TEXT]

Elika J. Etemad; Koji Ishii. CSS Text Level 3. 19 January 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-css3-text-20120119/

[CSS3UI]

Tantek Çelik. CSS Basic User Interface Module Level 3 (CSS3 UI). 17 January 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-css3-ui-20120117/

[CSS3VAL]

Håkon Wium Lie; Tab Atkins; Elika J. Etemad. CSS Values and Units Module Level 3. 8 March 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-css3-values-20120308/

Informative references:

[CSS3-EXCLUSIONS]

Vincent Hardy; Rossen Atanassov; Alan Stearns. CSS Exclusions and Shapes Module Level 3. 3 May 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-css3-exclusions-20120503/

[CSS3-MARQUEE]

Bert Bos. CSS Marquee Module Level 3. 5 December 2008. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2008/CR-css3-marquee-20081205

[CSS3CASCADE]

Håkon Wium Lie. CSS3 module: Cascading and inheritance. 15 December 2005. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2005/WD-css3-cascade-20051215

[CSS3GCPM]

Håkon Wium Lie. CSS Generated Content for Paged Media Module. 8 June 2010. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2010/WD-css3-gcpm-20100608

[CSS3LAYOUT]

Bert Bos; César Acebal. CSS Template Layout Module. 29 April 2010. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2010/WD-css3-layout-20100429

[CSS3LIST]

Tab Atkins Jr. CSS Lists and Counters Module Level 3. 24 May 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-css3-lists-20110524

[CSS3PAGE]

Håkon Wium Lie; Melinda Grant. CSS3 Module: Paged Media. 10 October 2006. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2006/WD-css3-page-20061010

[CSS3POS]

Bert Bos. CSS3 Positioning Module. (forthcoming). W3C Working Draft. (Work in progress.)

[CSS3RUBY]

Richard Ishida. CSS3 Ruby Module. 30 June 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-css3-ruby-20110630/

[CSS3TBL]

Bert Bos; David Hyatt. CSS3 Tables Module. (forthcoming). W3C Working Draft. (Work in progress.)

[MEDIAQ]

Florian Rivoal. Media Queries. 26 April 2012. W3C Proposed Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2012/PR-css3-mediaqueries-20120426/

Index

• A,, 3.
• A-C, 3.
• adjoining, 9.2.
• alignment, 20.
• AMIN, 13.
• <angle>, 2.
• anonymous box,, 7.3.
• approximate intrinsic minimum, 13.
• approximate intrinsic preferred, 13.
• APREF, 13.
• A′,, 3.
• auto
  • value of ‘width’ or ‘height’, 22.5.
• B,, 3.
• B-D, 3.
• <bg-position>, 2.
• block
  • value of ‘float-displace’, 23.
• block container box, 7.3.
• block flow dimension, 3.
• block flow direction, 2.
• block-level, 7.3.
• border area, 3.
• border box., 3.
• border edge., 3.
• both
  • value of ‘clear-after’, 17.
• box-sizing, 2.
• B′,, 3.
• C, 3.
• canvas, 4.
• child-align, 21.
• clear, 16.
• clear-after, 17.
• clearance., 16.
• collapse., 9.2.
• collapsed through, 9.2.
• complex aspect ratio, 5.
• computed value, 2.
• containing block, 7.3.
• contains, 3.
• content area, 3.
• content box, 3.
• content edge., 3.
• C′, 3.
• D,, 3.
• direction, 2.
• display, 7.1.
• document tree, 3.
• D′, 3.
• element, 3.
• element tree, 3.
• end,, 3.
• endside,, 3.
• exclusion zone, 15.
• float, 15.
• float-displace, 23.
• flow, 7.3.
• flow root, 7.3.
• formatting context, 7.3.
• generated box, 3.
• head,, 3.
• headside,, 3.
• height, 10.
• horizontal, 3.
• IMIN, 12.
• indent-edge-reset, 24.
• inhibits run-in behavior, 7.4.
• initial containing block., 7.3.
• inline base direction., 2.
• inline dimension, 3.
• inline-level, 7.3.
• intrinsic, 2.
• intrinsic height., 5.
• intrinsic minimum, 12.
• intrinsic preferred, 12.
• intrinsic width, 5.
• IPREF, 12.
• <length>, 2.
• line box., 2.
• margin, 9.1.
• margin area, 3.
• margin-bottom, 9.1.
• margin edge., 3.
• margin-left, 9.1.
• margin-right, 9.1.
• margin-top, 9.1.
• max-height, 11.
• max-width, 11.
• min-height, 11.
• min-width, 11.
• new formatting context, 7.3.
• no-content, 18.1.
• no-display, 18.1.
• none
  • value of ‘clear-after’, 17.
  • value of ‘indent-edge-reset’, 24.
• Non-transparent, 15.
• normal flow, 7.3.
• <number>, 2.
• orientation, 3.
• overflow, 18.1.
• overflow-x, 18.1.
• overflow-y, 18.1.
• padding, 8.
• padding area, 3.
• padding-bottom, 8.
• padding box., 3.
• padding edge., 3.
• padding-left, 8.
• padding-right, 8.
• padding-top, 8.
• <percentage>, 2.
• principal box, 7.3.
• raster images, 5.
• reference indent edge, 24.
• relative indent, 23.
• replaced element, 2., 5.
• root element., 3.
• scrolling mechanism, 18.1.
• "shrink-wrapped", 22.5.
• start,, 3.
• startside, 3.
• static position, 14.6.
• <stretch>, 9.1.
• SVG, 5., 5., 7.2., 22.5.
• tail, 3.
• tailside, 3.
• transform, 2.
• tree
  • of elements, 3.
• used value., 2.
• vertical., 3.
• viewport, 4.
• visibility, 19.
• width, 10.
• writing-mode, 2.
• WYSIWYG document editors, 3.

Property index