CSS basic box model

Abstract

CSS (Cascading Style Sheets) 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 the document as a hierarchy of boxes containing words, lines, paragraphs, tables, etc. each with properties such as size, color and font.

This module describes the basic types of boxes, with their padding and margin, and the normal “flow” (i.e., the sequence of blocks of text with margins in-between). It also defines “floating” boxes, but other kinds of layout, such as tables, absolute positioning, ruby annotations, grid layouts, columns and numbered pages, are described by other modules. Also, the layout of text inside each line (including the handling of left-to-right and right-to-left scripts) is defined elsewhere.

Boxes may contain either horizontal or vertical lines of text. Boxes of different orientations may be mixed in one flow. (This is a level 3 feature.)

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than 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.

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 the marquee effect. Please help us improve the next draft by pointing out such differences.

Table of contents

• 1. Dependencies on other modules
• 2. Introduction
• 3. How to read this specification
• 4. Types of boxes
  • 4.1. The ‘display’ property
  • 4.2. Block-level boxes, containing blocks, flows and anonymous boxes
  • 4.3. Run-in boxes
  • 4.4. Compact boxes
• 5. The padding properties
• 6. Margins
  • 6.1. The margin properties
  • 6.2. Collapsing margins
• 7. The ‘width’ and ‘height’ properties
• 8. The ‘min-width’, ‘max-width’, ‘min-height’ and ‘max-height’ properties
• 9. Calculating widths, heights and margins
  • 9.1. Inline, non-replaced elements
  • 9.2. Inline or floating, replaced elements
  • 9.3. Block-level, non-replaced elements in normal flow when ‘overflow’ computes to ‘visible’
  • 9.4. Other block-level, non-replaced elements in normal flow
  • 9.5. ‘Inline-block’ or floating, non-replaced elements
  • 9.6. Absolutely positioned, non-replaced elements
  • 9.7. Absolutely positioned, replaced elements
  • 9.8. Block-level, replaced elements in normal flow
  • 9.9. Floating, non-replaced elements
  • 9.10. ‘Auto’ heights for flow roots
  • 9.11. Shrink-to-fit
• 10. Floating boxes
  • 10.1. Introduction to floats
  • 10.2. The ‘float’ property
  • 10.3. Rules for positioning floats
  • 10.4. The ‘clear’ property
• 11. Overflow
  • 11.1. The ‘overflow’, ‘overflow-x’ and ‘overflow-y’ properties
  • 11.2. The ‘overflow-style’ property
  • 11.3. The marquee properties
• 12. The ‘visibility’ property
• 13. Rotating boxes
• 14. Stacking contexts
• 15. Conformance and profiles
• 16. Acknowledgments
• References
• Index
• Property index

1. Dependencies on other modules

This CSS module depends on the following other CSS modules:

• CSS Text Layout Module [CSS3TEXTLAYOUT] – switch between vertical and horizontal text.
• CSS Syntax Module [CSS3SYN] – syntax of properties and values
• CSS Values and Units Module [CSS3VAL] – definitions of value types <number>, <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>

2. Introduction

Note: The model in this specification differs from the model described in the CSS level 2 specification [CSS21], because (1) it is generalized to apply also to vertical text and (2) it adds properties to control the marquee effect, (speed, direction, etc.). The marquee effect is allowed, but UA-dependent in level 2.

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. The unique element that has no parent 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 tree of rectangular boxes, whose size and position depends on their properties. 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. And inline-level boxes are like words inside a line.

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

The tree of boxes closely mirrors the tree of elements. Each element is transformed into zero or more boxes. If the element is not the root element, then each of its boxes is either a child of a box of the parent element, or it is a child of a box of the element itself. In other words, there may be more or fewer boxes than there are elements, but each box belongs to exactly one element.

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

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

Each box has a content area. 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. Outside the padding is the border area and the outside boundary of that area is the border edge. 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.

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.

A box is horizontal if its ‘block-progression’ property is ‘tb’, otherwise it is vertical.

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

4. Types of boxes

4.1. The ‘display’ property

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

<template>

See the Advanced Layout module [CSS3LAYOUT].

none

This value causes an element to generate no boxes (i.e., the element has no effect on layout). Descendant elements do not generate any boxes either; 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.

The computed value is the same as the specified value, except when ‘float’ is not ‘none’ or when the element is the root element. In those cases, the computed value is as follows:

The value of ‘position’ may also influence the computed value. See [CSS3TBL].

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

A block-level box is a box that has a used value for ‘display’ of ‘block’, ‘list-item’, ‘table’, ‘table-*’ (i.e., all table boxes) or <template>. A block-level element is an element all of whose top-level non-anonymous boxes are block-level.

An inline-level box is a box that has a used value for ‘display’ of ‘inline’, ‘inline-block’, ‘inline-table’ or ‘ruby’. [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 ‘block-progression’ 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 ‘block-progression’ of the initial containing block are the same as those of the root element.
• The containing block of other boxes is the rectangle formed by the content edge of their nearest ancestor box that is block-level. This may be an anonymous box. The ‘direction’ and ‘block-progression’ of the containing block are those of the box whose content edge it is.

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.

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’ or ‘inline-table’.
• The value of ‘position’ is neither ‘static’ nor ‘relative’ (see [CSS3POS]).
• The value of ‘block-progression’ is ‘lr’ or ‘rl’ and the value of ‘block-progression’ of its parent box is ‘tb’
• The value of ‘block-progression’ is ‘tb’ and the value of ‘block-progression’ of its parent box is ‘lr’ or ‘rl’.

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 ‘block-progression’ apply to inlines.

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:

1. The used value of its ‘display’ is ‘block’, ‘list-item’, ‘table’ or <template>.
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 { block-progression: tb; float: left }
blockquote[lang|=ja] { block-progression: 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 ‘block-progression’ 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 content edges of its containing block (if the flow root is ‘tb’), or its top and bottom margin edges coincide with the top and bottom content edges of its containing block (if the flow root is ‘rl’ or ‘lr’).

[Define viewport and canvas]

4.3. Run-in boxes

A run-in box behaves as follows:

1. If the run-in box contains a block box, the run-in box becomes a block box.
2. If a sibling block box (that does not float and is not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box. A run-in cannot run in to a block that already starts with a run-in or that itself is a run-in.
3. Otherwise, the run-in box becomes a block box.

<!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. Please consult the section on generated content for information about how run-in boxes interact with generated content. [where?]

4.4. Compact boxes

Define here or in extended box module?

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

6. Margins

6.1. The margin properties

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

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 }

6.2. Collapsing margins

Certain adjoining margins 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: 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 box with ‘overflow’ other than ‘visible’ 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 an ‘inline-block’ box do not collapse (not even with its in-flow children). Assuming the first rule above (“only block-level”) is correct, this rule seems redundant, because an inline block is not block-level.
• Margins of the root element's box do not collapse.
• If a box is collapsed through and it has clearance applied to one of the collapsed margins, then those margins do not collapse with certain of the parent's margins: If clearance is applied to, respectively, the top, right or left margin, then those margins do not collapse with the parent's bottom, left or right margin, respectively.

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

• The top margin of a box A collapses with the top margin of its parent box B if the margins are adjoining and B is ‘tb’.

  Note that A itself may be vertical box.

• The bottom margin of a box A collapses with the bottom margin of its parent box B if the margins are adjoining and B is ‘tb’.

• The left margin of a box A collapses with the left margin of its parent box B if the margins are adjoining and B is ‘rl’ or ‘lr’.

• The right margin of a box A collapses with the right margin of its parent box B if the margins are adjoining and B is ‘rl’ or ‘lr’.

• The top margin of a box A collapses with the bottom margin of a sibling box B if the margins are adjoining and their parent is ‘tb’.

• A right margin of a box A collapses with the left margin of a sibling box B if the margins are adjoining and their parent is ‘rl’ or ‘lr’.

• The top and bottom margins of a box A collapse if the margins are adjoining and the box is ‘tb’. (The box is “collapsed through.”)

  In this case, the position of the element depends on its relationship with the other elements whose margins are being collapsed.

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

  Note that the positions of elements that have been collapsed through have no effect on the positions of the other elements with whose margins they are being collapsed; the top border edge position is only required for laying out descendants of these elements.

• The left and right margins of a box A collapse (“collapse through”) if the margins are adjoining and the box is ‘rl’ or ‘lr’.

  In this case, the position of the element depends on its relationship with the other elements whose margins are being collapsed.

  • If A's parent is ‘rl’:
    • If A's margins are collapsed with its parent's right margin, the right border edge of A is defined to be the same as the parent's.
    • Otherwise (i.e., either the element's parent is not taking part in the margin collapsing, or only the parent's left margin is involved), the position of A's right border edge is the same as it would have been if A had a nonzero top border.
  • If A's parent is ‘lr’:
    • If A's margins are collapsed with its parent's left margin, the left border edge of A is defined to be the same as the parent's.
    • Otherwise (i.e., either the element's parent is not taking part in the margin collapsing, or only the parent's right margin is involved),, the position of A's left border edge is the same as it would have been if A had a nonzero left border.

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

7. The ‘width’ and ‘height’ properties

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

Values have the following meanings:

<length>

Specifies the width of the content area using a length unit.

<percentage>

Specifies a percentage width. The percentage is calculated with respect to the width of the generated box's containing block. If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS3.

auto

The width depends on the values of other properties. See the sections below.

Do we want to define unknown percentages in CSS3? Something simple, such as ‘auto’, or something more fancy, such as trying to solve percentages?

Negative values are illegal.

p { width: 100px }

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

<percentage>

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

none

No limit on the width or height of the box.

Negative values are illegal.

9. 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 (without ‘min-width’, and ‘max-width’) following the rules in the subsections below.
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 (without ‘min-height’, and ‘max-height’) following the rules under “Calculating widths, heights and margins” below.
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’.

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

9.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 equal to the computed value, except that a computed value of ‘auto’ becomes a used value of ‘0’.

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

9.2. Inline or floating, replaced elements

The used values of ‘margin-left’, ‘margin-right’, ‘margin-top’ and ‘margin-bottom’ are equal to 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’, 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.

9.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 following constraints must hold among the used values of the properties.

‘margin-left’ + ‘border-left-width’ + ‘padding-left’ + ‘width’ + ‘padding-right’ + ‘border-right-width’ + ‘margin-right’ + scrollbar width (if any) = width of containing block

If ‘width’ is not ‘auto’ and ‘border-left-width’ + ‘padding-left’ + ‘width’ + ‘padding-right’ + ‘border-right-width’ + scrollbar width (if any) (plus any of ‘margin-left’ or ‘margin-right’ that are not ‘auto’) is larger than the width of the containing block, then any ‘auto’ values for ‘margin-left’ or ‘margin-right’ are, for the following rules, treated as zero. We should drop this paragraph. It causes blocks that are wider than their parent not to be centered (unlike blocks that are narrower), which looks strange.

All the above properties that have a computed value other than ‘auto’ have a used value equal to the computed value, except if they all have a computed value other than ‘auto’. Then the values are said to be “over-constrained” and one of the used values will have to be different from its computed value. If the ‘direction’ property of the containing block has the value ‘ltr’, the specified value of ‘margin-right’ is ignored and the value is calculated so as to make the equality true. If the value of ‘direction’ is ‘rtl’, this happens to ‘margin-left’ instead.

If there is exactly one value specified as ‘auto’, its used value follows from the equality.

If ‘width’ is set to ‘auto’, any other ‘auto’ values become ‘0’ and ‘width’ follows from the resulting equality.

If both ‘margin-left’ and ‘margin-right’ are ‘auto’, their used values are equal. This horizontally centers the element with respect to the edges of the containing block.

The “scrollbar width” value is only relevant if the user agent uses a scrollbar as its scrolling mechanism. See the definition of the ‘overflow’ property.

If ‘margin-top’, or ‘margin-bottom’ are ‘auto’, their used value is 0. If ‘height’ is ‘auto’, the height depends on whether the element has any block-level children and whether it has padding or borders:

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 border-edge of the topmost block-level child box that doesn't have margins collapsed through it and the bottom border-edge of the bottommost block-level child box that doesn't have margins collapsed through it. However, if the element has a nonzero top padding and/or top border, or is the root element, then the content starts at the top margin edge of the topmost child. (The first case expresses the fact that the top and bottom margins of the element collapse with those of the topmost and bottommost children, while in the second case the presence of the padding/border prevents the top margins from collapsing.) Similarly, if the element has a nonzero bottom padding and/or bottom border, then the content ends at the bottom margin edge of the bottommost child.

Only children in the normal flow are taken into account (i.e., floating boxes and absolutely positioned boxes are ignored, and relatively positioned boxes are considered without their offset). Note that the child box may be an anonymous block box.

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

Apply the rules for block-level, non-replaced elements in normal flow, but ignore the resulting values for ‘height’, ‘margin-top’ and ‘margin-bottom’.

If ‘margin-top’, or ‘margin-bottom’ are ‘auto’, their used value is 0. If ‘height’ is ‘auto’, its used value is defined by “‘Auto’ heights for flow roots.”

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

The used values of ‘margin-left’, ‘margin-right’, ‘margin-top’ and ‘margin-bottom’ are their computed values, except that a computed value of ‘auto’ gives a used value of 0.

The used value of ‘width’ is the computed value, unless that is ‘auto’, when used value is the shrink-to-fit width.

The used value of ‘height’ is the computed value, unless that is ‘auto’, when the used value is defined by “‘Auto’ heights for flow roots.”

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

9.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’ + scrollbar width (if any) = 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 shrink-to-fit. 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 shrink-to-fit. 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’ + scrollbar height (if any) = 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’.

The “scrollbar height” and “scrollbar width” values are only relevant if the user agent uses a scrollbar as its scrolling mechanism. See the definition of the ‘overflow’ property.

9.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’ + scrollbar width (if any) = width of containing block

‘top’ + ‘margin-top’ + ‘border-top-width’ + ‘padding-top’ + ‘height’ + ‘padding-bottom’ + ‘border-bottom-width’ + ‘margin-bottom’ + ‘bottom’ + scrollbar height (if any) = 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.

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

9.9. Floating, non-replaced elements

The used values of the margins are equal to the computed values, except that the used values of any margins computed as ‘auto’ are ‘0’.

The used value of ‘width’ is equal to the computed value, except that if ‘width’ is computed as ‘auto’, the used value is the shrink-to-fit width.

If the computed value of ‘height’ is not ‘auto’, the used value is the computed value. Otherwise the used height depends on the descendants, as defined in “‘Auto’ heights for flow roots.”

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

9.11. Shrink-to-fit

Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of ‘margin-left’, ‘border-left-width’, ‘padding-left’, ‘padding-right’, ‘border-right-width’, ‘margin-right’, and the widths of any relevant scroll bars.

Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).

Define in more detail, using a text by David Baron.

10. Floating boxes

10.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 outer edge touches the containing block edge or the outer 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 }

10.2. The ‘float’ property

This property specifies whether a box should float to the left, right, or not at all. It may be set for any element, but only applies to elements that generate boxes that are not absolutely positioned. The values of this property have the following meanings:

left

...

right

...

none

...

<page-floats>

See Generated Content for Paged Media [CSS3GCPM].

10.3. Rules for positioning floats

[To do: copy from CSS2 [CSS21] and generalize to vertical text]

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

10.4. The ‘clear’ property

[To do: copy from CSS2 [CSS21] and generalize to vertical text]

11. Overflow

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

11.2. The ‘overflow-style’ property

This property specifies the preferred scrolling methods for elements that overflow (see the ‘overflow’ property.) The value is either ‘auto’, meaning no preference, or a list of methods in order of preference. The UA should use the first scrolling method in the list that it supports. If it supports none of them, it must act as if the value was ‘auto’.

A UA that support a certain scrolling mechanism may be able to support it only in certain cases. E.g., a UA may be able to use the marquee effect only in the horizontal direction (or the line progression direction), or it may be able to use a panner only if none of the ancestor boxes uses a panner.

scrollbar

Scrollbars are typically narrow strips inserted on one or two edges of an element and which often have arrows to click on and a “thumb” to drag up and down (or left and right) to move the contents of the element.

panner

A panner is typically a rectangle shown in one corner of the element, with a smaller rectangle inside. The larger rectangle represents all the available content of the element and the smaller one the visible part. The smaller rectangle can be moved around by the user to move the content of the element accordingly.

move

The value ‘move’ refers to a method where the user can move the content of the element directly (rather than indirectly by moving a scrollbar or a panner). Typically, the mouse pointer changes into a hand or a cross of four arrows to indicate that the user can drag the content around with the mouse. Sometimes the user needs to explicitly activate the move mode and in that case he often can use both dragging (with the mouse) and key events to move the content.

marquee

The marquee effect (value ‘marquee’) consists of the content moving autonomously, without any user events to control it. A user who waits long enough will eventually see all the content that overflows.

This specification does not define what scrollbars, panners or the visual indicators for the ‘move’ method look like. The ‘marquee’ method is further defined below.

Another idea is to make ‘overflow’ a shorthand for ‘overflow-style’ and overflow-policy, where overflow-policy has syntax “visible | hidden | scroll | auto” and ‘overflow’ has “<‘overflow-policy’> || <‘overflow-style’>”. Then it is possible to write, e.g., ‘overflow: auto marquee, scrollbar’.

11.3. The marquee properties

The marquee effect consists of the UA slowly moving the content of a box so that, over time, all parts of the box are visible at least once. The speed of the movement, whether the movement is in one direction only or back and forth, how far the content moves and how often may vary. But, unlike for most other scrolling mechanisms, these factors are not dependent on user events. Typically, marquee is used in contexts where there is no room for a scrollbar or other visible mechanism or when user interaction is limited: instead of actively moving hidden content into view with a scrollbar or similar mechanism, the user waits while the content moves by.

li {overflow: auto; overflow-style: marquee; white-space: nowrap}

The values are:

scroll

Start completely off one side, scroll all the way across and completely off.

slide

Start completely off one side, scroll in, and stop as soon as no more content is off that side.

alternate

Start with all overflow on one side, then scroll until there is no more overflow on that side. For the next loop, start with content overflowing on the other side (i.e., where the previous loop ended).

Is ‘bounce’ a better name than ‘alternate’?

The content of an element moves as one piece. E.g., if a element has two lines of text, both lines scroll together, even if only one of them overflows.

This property specifies how often the content moves. UAs should restart the loop count every time the element turns from completely invisible into (fully or partially) visible. E.g., an element that is outside the viewport starts moving when it is scrolled into view.

A UA may also take the visibility of the UA viewport itself into account, e.g., if the element is hidden behind a pop-up window or if the UA is iconified.

If ‘marquee-loop’ is different for different states of the element, e.g., ‘p {marquee-loop: 0} p:hover {marquee-loop: infinite}’, the loop counter must be reset each time the element enters a state with a different computed value.

li {overflow: auto; overflow-style: marquee; marquee-loop: 0}
li:focus, li:hover {marquee-loop: 1}

Is ‘infinite’ a better default than ‘1’?

This property determines the initial direction in which the content moves if the marquee effect is used. The actual direction depends on ‘direction’ and ‘block-progression’ as follows:

Note that ‘marquee-style: alternate’ moves content in the opposite direction on even-numbered loops.

This property determines how fast the content scrolls. The actual speed depends on the UA and the type of content. But, for a given UA and a given element, the following must always be true: slow < normal < fast.

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

13. Rotating boxes

Should probably be in the extended Box module instead of here…

The value of ‘rotation-point’ is a pair of values that defines a point as an offset from the top left border edge. Percentages refer to the width and height of the border box. Values may be negative.

‘Rotation’ rotates a block-level element counterclockwise around the point given by ‘rotation-point’. The border, padding and content are rotated, and also any background that is not ‘fixed’. All static or relatively positioned child elements (and their static and relatively positioned children, recursively) are rotated along. But absolutely positioned and fixed descendant elements are not.

Note that this means that rotation is relative. A child of a box that is rotated 45deg and that has a rotation of -45deg itself, actually ends up horizontal (but probably in a different location than when both rotations had been 0).

Rotation doesn't affect parent or sibling elements, they are laid out as if the element's rotation was 0. Conceptually, the element is first laid out without any rotation, then any relative positioning is applied to it (see [CSS3POS]) and finally any rotation. The rotation point is relative to the box after relative positioning.

Note that, like relative positioning, rotation can thus cause an element's box to overlap other boxes. It is the author's responsibility to give the element wide enough margins if such overlapping is not desired.

When a box is broken over several columns or pages, each of the boxes is rotated separately around its own rotation point.

The computed value of ‘rotation’ is the angle normalized to fall in 0deg ≤ angle < 360deg. The computed value or ‘rotation-point’ is a pair in which any <length> is made absolute, keywords are replaced by percentages and percentages are left as specified.

H1 {rotation: 180deg}

thead th {
    block-progression: rl;
    padding: 0.5em 1em;
    rotation: 45deg;
    rotation-point: bottom left }

In the table example, how are the borders rotated? Because the borders belong to two elements that are rotated individually.

Dave Hyatt proposes to generalize the property and call it “transform” with a syntax and functionality like in SVG, i.e., a property that accepts a series of transformations (rotations, translations, arbitrary affine transformations).

14. Stacking contexts

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

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 section, “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.

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

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 [still the case?], the exact result of these two requirements is UA-defined.

15. Conformance and profiles

16. Acknowledgments

References

Normative references:

[CSS3BG]

Tim Boland; Bert Bos. CSS3 Backgrounds and Borders Module. 16 February 2005. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2005/WD-css3-background-20050216

[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. CSS3 Text Module. 27 June 2005. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2005/WD-css3-text-20050627

[CSS3TEXTLAYOUT]

Elika J. Etemad; Paul Nelson. CSS3 Text Layout Module. (forthcoming). W3C Working Draft. (Work in progress.)

[CSS3VAL]

Håkon Wium Lie; Chris Lilley. CSS3 module: Values and Units. 13 July 2001. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2001/WD-css3-values-20010713

Informative references:

[CSS21]

Bert Bos; et al. Cascading Style Sheets, level 2 revision 1. 11 April 2006. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2006/WD-CSS21-20060411

[CSS3CASCADE]

Håkon Wium Lie. CSS3 module: Cascading and inheritance. 19 February 2002. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2002/WD-css3-cascade-20020219

[CSS3GCPM]

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

[CSS3LAYOUT]

Bert Bos. CSS3 Advanced Layout Module. 15 December 2005. W3C Working Draft. (Work in progress) URL: http://www.w3.org/TR/2005/WD-css3-layout-20051215/

[CSS3LIST]

Ian Hickson; Tantek Çelik. CSS3 module: Lists. 7 November 2002. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2002/WD-css3-lists-20021107

[CSS3PAGE]

Håkon Wium Lie; Melinda Grant. CSS3 Paged Media Module. 25 February 2004. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2004/CR-css3-page-20040225

[CSS3POS]

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

[CSS3RUBY]

Michel Suignard. CSS3 Ruby Module. 14 May 2003. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2003/CR-css3-ruby-20030514

[CSS3TBL]

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

[MEDIAQ]

Håkon Wium Lie; Tantek Çelik; Daniel Glazman. Media Queries. 8 July 2002. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708

Index

• alternate, #
• anonymous box,, #
• auto
  • value of 'overflow', #
• background-position, #
• block, #
• block-level, #
• block-progression, #
• border, #
• border area, #
• border-bottom-width, #
• border edge., #
• border-left-width, #
• border-right-width, #
• border-top-width, #
• bottom, #
• canvas, #
• clear, #
• collapse, #
• collapsed through, #
• compact, #
• computed value, #
• containing block, #
• content area., #
• content edge., #
• direction, #
• display, #
• element, #
• float, #
• flow, #
• flow root, #
• height, #
• hidden, #, #
• horizontal, #
• image-scaling, #
• initial containing block., #
• inline, #
• inline-block, #
• inline-level, #
• inline-table, #
• intrinsic, #
• left, #
• line box., #
• list-item, #
• margin, #
• margin area, #
• margin-bottom, #
• margin edge., #
• margin-left, #
• margin-right, #
• margin-top, #
• marquee-direction, #
• marquee-loop, #
• marquee-speed, #
• marquee-style, #
• max-height, #
• max-width, #
• min-height, #
• min-width, #
• no-content, #
• no-display, #
• none, #, #
• normal flow, #
• overflow, #
• overflow-style, #
• overflow-x, #
• overflow-y, #
• padding, #
• padding area, #
• padding-bottom, #
• padding edge., #
• padding-left, #
• padding-right, #
• padding-top, #
• position, #
• replaced, #
• right, #
• root element., #
• rotation, #
• rotation-point, #
• ruby, #
• ruby-base, #
• ruby-base-group, #
• ruby-text, #
• ruby-text-group, #
• run-in, #
• scroll, #
• scrolling mechanism, #
• scroll (marquee-style), #
• shrink-to-fit, #
• slide, #
• static position, #
• table, #
• table-caption, #
• table-cell, #
• table-column, #
• table-column-group, #
• table-footer-group, #
• table-header-group, #
• table-row, #
• table-row-group, #
• top, #
• used value., #
• <angle>, #
• <bg-position>, #
• <length>, #
• <number>, #
• <page-floats>, #
• <template>, #
• vertical., #
• viewport, #
• visibility, #
• visible, #, #
• width, #
• z-index, #

Property index

Properties defined elsewhere:

• block-progression, direction: [CSS3TEXTLAYOUT]
• border, border-top-width, border-right-width, border-bottom-width, border-left-width, background-position: [CSS3BG]
• bottom, top, z-index: [CSS3POS]
• image-scaling: [CSS3PAGE]
• position: [CSS3POS] and [CSS3LAYOUT]