inline-block

Computes to ''inline flow-root''.

inline-table

Computes to ''inline table''.

inline-flex

Computes to ''inline flex''.

inline-grid

Computes to ''inline grid''.

Automatic Box Type Transformations

The Root Element’s Principal Box

Display Order: the 'order' property

	Name: order
	Value: <>
	Initial: 0
	Applies to: [=flex items=] and [=grid items=]
	Inherited: no
	Computed value: specified integer
	Animation type: by computed value type
	

Here's an example of a catalog item card which has a title, a photo, and a description. Within each entry, the source document content is ordered logically with the title first, followed by the description and the photo. This provides a sensible ordering for speech rendering and in non-CSS browsers. For a more compelling visual presentation, however, 'order' is used to pull the image up from later in the content to the top of the card.

		article.sale-item {
			display: flex;
			flex-flow: column;
		}
		article.sale-item > img {
			order: -1; /* Shift image before other content (in layout order) */
			align-self: center;
		}
		

		<article class="sale-item">
			<h1>Computer Starter Kit</h1>
			<p>This is the best computer money can buy, if you don’t have much money.
			<ul>
				<li>Computer
				<li>Monitor
				<li>Keyboard
				<li>Mouse
			</ul>
			<img src="images/computer.jpg"
				alt="You get: a white desktop computer with matching peripherals.">
		</article>
		

Computer Starter Kit

This is the best computer money can buy, if you don't have much money.

• Computer
• Monitor
• Keyboard
• Mouse

Reordering and Accessibility

Invisibility: the 'visibility' property

	Name: visibility
	Value: visible | hidden | collapse
	Initial: visible
	Applies to: all elements
	Inherited: yes
	Percentages: N/A
	Media: visual
	Computed Value: as specified
	Animation type: discrete
	

visible

The generated box is visible, as normal.

hidden

Any boxes generated by the element are [=invisible=]. Descendants of the element can, however, be visible if they have ''visibility: visible''.

collapse

Indicates that the box is collapsed, which can cause it to take up less space than otherwise in a formatting-context–specific way. See dynamic row and column effects in tables [[!CSS2]] and [[css-flexbox-1#visibility-collapse|collapsed flex items]] in flex layout [[!CSS-FLEXBOX-1]]. In all other cases, however, (i.e. unless otherwise specified) this simply makes the box [=invisible=], just like ''visibility/hidden''.

Run-In Layout

		<dl class='dict'>
			<dt>dictionary
			<dd>a book that lists the words of a language in alphabetical
			    order and gives their meaning, or that gives the equivalent
			    words in a different language.
			<dt>glossary
			<dd>an alphabetical list of terms or words found in or relating
			    to a specific subject, text, or dialect, with explanations; a
			    brief dictionary.
		</dl>
		<style>
		.dict > dt {
			display: run-in;
		}
		.dict > dt::after {
			content: ": "
		}
		</style>
		

		dictionary: a book that lists the words of a language
		in alphabetical order and explains their meaning.

		glossary: an alphabetical list of terms or words found
		in or relating to a specific subject, text, or dialect,
		with explanations; a brief dictionary.
		

• A run-in box with a ''flow'' inner display type inlinifies its contents.
• If a run-in sequence is immediately followed by a block box that does not establish a new block formatting context, it is inserted as direct children of that block box: after its ''::marker'' pseudo-element's boxes (if any), but preceding any other boxes generated by the contents of the block (including the box generated by the ''::before'' pseudo-element, if any). This re-parenting recurses if possible (so that the run-in effectively becomes part of the deepest subsequent “paragraph” in its formatting context, collecting newly-adjacent run-ins as it goes). The reparented content is then formatted as if originally parented there. Note that only layout is affected, not inheritance, because property inheritance for non-anonymous boxes is based only on the element tree.
• Otherwise (if the run-in sequence is not followed by such a block), an anonymous block box is generated around the run-in sequence and all immediately following inline-level content (up to, but not including, the next run-in sequence, if any).

Appendix A: Glossary

root element

The [=CSS/element=] at the root of the [=document tree=]. In a [=document tree=] produced under the DOM, this is the [=document element=]; in HTML it is the <{html}> element. [[DOM]] [[HTML]]

principal box

When an [=CSS/element=] generates one or more [=boxes=], one of them is the [=principal box=], which contains its descendant boxes and generated content, and is also the box involved in any positioning scheme. Some elements may generate additional boxes in addition to the principal box (such as ''display/list-item'' elements, which generate an additional marker box, or ''display/table'' elements, which generate a [=principal box|principal=] [=table wrapper box=] and an additional [=table grid box=]). These additional boxes are placed with respect to the principal box.

inline-level

Content that participates in inline layout. Specifically, inline-level boxes and [=text sequences=].

block-level

Content that participates in [=block layout=]. Specifically, block-level boxes.

inline box

A non-replaced inline-level box whose inner display type is ''flow''. The contents of an inline box participate in the same inline formatting context as the inline box itself.

inline

Used as a shorthand for inline box or inline-level box where unambiguous, or as an adjective meaning inline-level. The latter usage is deprecated.

atomic inline

An inline-level box that is replaced (such as an image) or that establishes a new formatting context (such as an ''inline-block'' or ''inline-table'') and cannot split across lines (as inline boxes and ruby containers can). Any inline-level box whose inner display type is not ''flow'' establishes a new formatting context of the specified inner display type.

block container

A block container either contains only inline-level boxes participating in an inline formatting context, or contains only block-level boxes participating in a block formatting context (possibly generating anonymous block boxes to ensure this constraint, as defined in CSS2§9.2.1.1). A block container that contains only inline-level content establishes a new inline formatting context. The element then also generates a root inline box which wraps all of its inline content. Note, this root inline box concept effectively replaces the "anonymous inline element" concept introduced in CSS2§9.2.2.1. A block container establishes a new block formatting context if its parent formatting context is not a block formatting context; otherwise, when participating in a block formatting context itself, it either establishes a new block formatting context for its contents or continues the one in which it participates, as determined by the constraints of other properties (such as 'overflow' or 'align-content'). Note: A block container box can both establish a block formatting context and an inline formatting context simultaneously.

block box

A block-level box that is also a block container. Note: Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells, for example, are block containers but not block-level boxes. Similarly, not all block-level boxes are block containers: block-level replaced elements (''display: block'') and flex containers (''display: flex''), for example, are not block containers.

block

Used as a shorthand for block box, block-level box, or block container box, where unambiguous.

replaced element

An element whose content is outside the scope of the CSS formatting model, such as an image or embedded document. For example, the content of the HTML <{img}> element is often replaced by the image that its <{img/src}> attribute designates. Replaced elements often have [=natural dimensions=]. For example, a bitmap image has a natural width and a natural height specified in absolute units (from which the natural ratio can obviously be determined). On the other hand, other objects may not have any natural dimensions (for example, a blank HTML document). See [[css-images-3]]. User agents may consider a [=replaced element=] to not have any [=natural dimensions=] if it is believed that those dimensions could leak sensitive information to a third party. For example, if an HTML document changed natural size depending on the user's bank balance, then the UA might want to act as if that resource had no [=natural dimensions=]. The content of replaced elements is not considered in the CSS formatting model; however, their [=natural dimensions=] are used in various layout calculations. Replaced elements always establish an [=independent formatting context=]. A non-replaced element is one that is not replaced, i.e. whose rendering is dictated by the CSS model.

containing block

A rectangle that forms the basis of sizing and positioning for the [=boxes=] associated with it. Notably, a [=containing block=] is not a [=box=] (it is a rectangle), however it is often derived from the dimensions of a [=box=]. Each [=box=] is given a position with respect to its [=containing block=], but it is not confined by this [=containing block=]; it can [=overflow=]. The phrase “a box’s containing block” means “the [=containing block=] in which the box lives,” not the one it generates. In general, the [=box edge|edges=] of a [=box=] act as the [=containing block=] for descendant boxes; we say that a box “establishes” the [=containing block=] for its descendants. If properties of a [=containing block=] are referenced, they reference the values on the [=box=] that generated the [=containing block=]. (For the initial containing block, values are taken from the root element unless otherwise specified.) See [[CSS2]] Section 9.1.2 and Section 10.1 and [[CSS-POSITION-3#def-cb]] for details.

containing block chain

A sequence of successive containing blocks that form an ancestor-descendant chain through the containing block relation. For example, an inline box’s containing block is the content box of its closest block container ancestor; if that block container is an in-flow block, then its containing block is formed by its parent block container; if that grandparent block container is absolutely positioned, then its containing block is the padding edges of its closest positioned ancestor (not necessarily its parent), and so on up to the initial containing block.

initial containing block

The containing block of the [=root element=]. The [=initial containing block=] establishes a [=block formatting context=], and takes the [=principal writing mode=] of the document (see [[css-writing-modes-4#icb]]). In [=continuous media=], it has the dimensions of the [=small viewport size=] and is anchored at the canvas origin. In [=paged media=], see [[!CSS-PAGE-3]] for its position and dimensions.

formatting context

A formatting context is the environment into which a set of related boxes are laid out. Different [=formatting contexts=] lay out their boxes according to different rules. For example, a flex formatting context lays out boxes according to the flex layout rules [[CSS-FLEXBOX-1]], whereas a block formatting context lays out boxes according to the block-and-inline layout rules [[CSS2]]. Additionally, some types of [=formatting contexts=] interleave and co-exist: for example, an [=inline formatting context=] exists within and interacts with the [=block formatting context=] of the element that establishes it, and a [=ruby container=] overlays a [=ruby formatting context=] over the [=inline formatting context=] in which its [=ruby base container=] participates. A box either establishes a new [=independent formatting context=] or continues the [=formatting context=] of its containing block. In some cases, it might additionally establish a new (non-independent) co-existing formatting context. Unless otherwise specified, however, establishing a new formatting context creates an independent formatting context. The type of formatting context established by the box is determined by its inner display type. E.g. a grid container establishes a new grid formatting context, a ruby container establishes a new ruby formatting context, and a block container can establish a new block formatting context and/or a new inline formatting context. See the 'display' property.

independent formatting context

When a box establishes an independent formatting context (whether that [=formatting context=] is of the same type as its parent or not), it essentially creates a new, independent layout environment: except through the sizing of the box itself, the layout of its descendants is (generally) not affected by the rules and contents of the [=formatting context=] outside the box, and vice versa.

For example, in a block formatting context, floated boxes affect the layout of surrounding boxes. But their effects do not escape their formatting context: the box establishing their formatting context grows to fully contain them, and floats from outside that box are not allowed to protrude into and affect the contents inside the box.

As another example, margins do not collapse across [=formatting context=] boundaries.

Exclusions are able to affect content across [=independent formatting context=] boundaries. (At time of writing, they are the only layout feature that can.) [[CSS3-EXCLUSIONS]] Certain properties can force a box to establish an independent formatting context in cases where it wouldn't ordinarily. For example, making a box out-of-flow causes it to blockify as well as to [=establish an independent formatting context=]. As another example, certain values of the 'contain' property can cause a box to establish an independent formatting context. Turning a block into a scroll container will cause it to establish an independent formatting context; however turning a subgrid into a scroll container will not-- it continues to act as a subgrid, with its contents participating in the layout of its parent grid container. A [=block box=] that [=establishes an independent formatting context=] establishes a new [=block formatting context=] for its contents. In most other cases, forcing a box to [=establish an independent formatting context=] is a no-op-- either the box already establishes an independent formatting context (e.g. flex containers), or it's not possible to establish a totally independent new formatting context on that type of box (e.g. non-replaced inline boxes).

block formatting context

inline formatting context

[=block formatting context|Block=] and [=inline formatting contexts=] are defined in CSS 2.1 Section 9.4. [=Inline formatting contexts=] exist within (are part of their containing) [=block formatting contexts=]; for example, line boxes belonging to the [=inline formatting context=] interact with floats belonging to the [=block formatting context=].

block layout

The layout of [=block-level boxes=], performed within a [=block formatting context=].

block formatting context root

A block container that establishes a new block formatting context.

BFC

Abbreviation for block formatting context or block formatting context root. Has various informal definitions referring to boxes which contain internal floats, exclude external floats, and suppress margin collapsing, and may therefore refer specifically to one of: * a block container that establishes a new block formatting context for its contents * a block box (i.e. a block-level block container) that establishes a [=block formatting context=] for its contents (as distinguished from a block box which does not) * (very loosely) any block-level box that establishes a new [=formatting context=] (other than an inline formatting context)

out-of-flow

in-flow

A box is out-of-flow if it is extracted from its expected position and interaction with surrounding content and laid out using a different paradigm outside the normal flow of content in its parent formatting context. This occurs if the box is floated (via 'float') or [=absolutely positioned=] (via 'position'). A box is in-flow if it is not out-of-flow. Note: Some [=formatting contexts=] inhibit floating, so that an element with ''float: left'' is not necessarily out-of-flow.

document order

The order in which boxes or content occurs in the document (which can be different from the order in which it appears for rendering). For the purpose of determining the relative order of pseudo-elements, the box-tree order is used, see [[css-pseudo-4#treelike]].

Appendix B: Effects of ''display: contents'' on Unusual Elements

Appendix C: Box Construction Guidelines for Spec Authors

Acknowledgments

Changes

Changes Since 2023 Candidate Recommendation Snapshot

• Inlined the CSS2.1 definition of the [=initial containing block=] for [=continuous media=], cross-referenced its [=writing mode=] propagation as defined in [[CSS-WRITING-MODES-4]], and clarified that it refers to the [=small viewport size=]. (Issue 6453)

Changes Since 2020 Candidate Recommendation

• Renamed “text run” to “[=text sequence=]”. (Issue 7768)
• Defined [=root element=] and clarified its layout as a [=block-level=] in [[#root]] and the definition of [=initial containing block=]. (PR 8095, Issue 7207, Issue 6480, Issue 7786)
• Pulled in the 'order' property definition from [[CSS-FLEXBOX-1]], since it also applies to [=grid items=]. (Issue 5865)
• Imported the 'visibility' property definition from [[CSS2]] and updated it to be more thorough and complete. (Issue 6123)
• Defined that [=replaced elements=] with a [=layout-internal=] 'display' are treated as ''display: inline''. (Issue 6000)
• Clarified that the <> values actually [=computed value|compute=] to the same value as their two-keyword equivalents. (Issue 5575)

  inline-…

  Behaves as Computes to ''inline …''.

  Note: Although these keywords and their equivalents compute to the same value, their [=specified values=] remain distinct.

  Note: The {{Window/getComputedStyle()}} serialization rules will always output these precomposed keywords rather than the equivalent two-keyword pairs due to the [[cssom#serializing-css-values|shortest, most backwards-compatible serialization principle]].

• Clarified that [=blockification=] and [=inlinification=] are [=computed value=] changes. (Issue 6251)

  Some layout effects require [=blockification=] or [=inlinification=] of the box type, which sets the box’s [=computed value|computed=] outer display type to ''block'' or ''inline'' (respectively).

• Added definition for [=block layout=] to glossary, for convenience.
• Updated references to CSS Grid Layout.
• Various minor editorial clarifications and cross-linking improvements.

Changes Since 2019 Candidate Recommendation

• Merged in additional prose from [[!CSS2]] into the definition of [=containing block=].
• Clarified that, for the purpose of CSS, DOM nodes other than elements and text are ignored.

  (Some source documents start from more complex trees, such as the DOM, which can have comment nodes and other types of things. For the purposes of CSS, all of these additional types of nodes are ignored, as if they didn't exist.)

• Improved/moved glossary definitions relating to [=absolute positioning=].

• Defined box tree parentage; see parent box.
• Added definition of absolutely positioned to the glossary; copied from CSS2 for easier referencing.
• Added cross-references to various forms of fragmentation in [[#intro]].
• Renamed “table box” to “table grid box” to more easily distinguish from “table wrapper box”.
• Added “unless otherwise specified” to root → initial containing block propagation, since there are some regrettable special exceptions for the HTML <{body}> element.

Changes Prior to Candidate Recommendation Status

• Elements with ''display: contents'' that behave as ''display: none'' now compute to ''display: none''. (Issue 2755)
• Distinguished “new” formatting context from independent formatting context since certain formatting contexts layer. (Issue 2597, Issue 1457)
• Defined that block boxes that establish an independent formatting context have a used 'display' of ''flow-root'', to provide an easier point of reference. (Issue 1550)
• Clarified that 'display' is not animatable (as opposed to discretely animatable). (Issue 2938)
• Minor editorial fixes.

• Deferred the box-suppress/display-or-not property to the next level of Display, in order to provide time for further discussion of use cases.
• Specified the effects of ''display: contents'' on unusual elements such as replaced elements and form controls.
• Clarified that an element’s ''::before'' and ''::after'' pseudo-elements still exist if its own box is not generated due to ''display: contents''.
• Clarified that event bubbling is not affected by ''display: contents''.
• Clarified interaction of run-ins with out-of-flow elements and ''::first-letter''.
• Switched ''table-caption'' and ''table-cell'' to use ''flow-root'' as their inner display type, since they always form a formatting context root.
• Closed off remaining issues and added at-risk list.

• Added definitions for in-flow and out-of-flow to glossary.

• Removed display-inside, display-outside, and display-extras longhands, in favor of just making 'display' multi-value. (This was done to impose constraints on what can be combined. Future levels of this specification may relax some or all of those restrictions if they become unnecessary or unwanted.)
• Created the ''flow'' and ''flow-root'' inner display types to better express flow layout display types and to create an explicit switch for making an element a BFC root. (This should eliminate the need for hacks like ''::after { clear: both; }'' and ''overflow: hidden'' that are intended to accomplish this purpose.)

Privacy Considerations

Security Considerations

Self-Review Questionnaire

1. Does this specification deal with personally-identifiable information?

   No.

2. Does this specification deal with high-value data?

   No.

3. Does this specification introduce new state for an origin that persists across browsing sessions?

   No.

4. Does this specification expose persistent, cross-origin state to the web?

   No.

5. Does this specification expose any other data to an origin that it doesn’t currently have access to?

   No.

6. Does this specification enable new script execution/loading mechanisms?

   No.

7. Does this specification allow an origin access to a user’s location?

   No.

8. Does this specification allow an origin access to sensors on a user’s device?

   No.

9. Does this specification allow an origin access to aspects of a user’s local computing environment?

   No.

10. Does this specification allow an origin access to other devices?

    No.

11. Does this specification allow an origin some measure of control over a user agent’s native UI?

    No.

12. Does this specification expose temporary identifiers to the web?

    No.

13. Does this specification distinguish between behavior in first-party and third-party contexts?

    No.

14. How should this specification work in the context of a user agent’s "incognito" mode?

    No differently.

15. Does this specification persist data to a user’s local device?

    No.

16. Does this specification have a "Security Considerations" and "Privacy Considerations" section?

    Yes.

17. Does this specification allow downgrading default security characteristics?

    No.