This section is normative.
CSS takes a source document, organized as a tree of elements and text nodes, and renders it onto a canvas (such as your screen, a piece of paper, or an audio stream). To do this, it generates an intermediary structure, the box tree, which represents the formatting structure of the rendered document. Each box in the box tree represents its corresponding element (or pseudo-element) in space and/or time on the canvas, while each text run in the box tree likewise represents the contents of its corresponding text nodes.
To create the box tree, CSS first uses cascading and inheritance, to assign a computed value for each CSS property to each element and text node in the source tree. (See [CSS3-CASCADE].)
Then, for each element, CSS generates zero or more boxes as specified by that element’s display property. Typically, an element generates a single box. However, some display values (e.g. display: list-item) generate more than one box (e.g. a principal block box and a marker box). And some values (such as none or contents) cause the element and/or its descendants to not generate any boxes at all. Boxes are often referred to by their display type—e.g. a box generated by an element with display: block is called a “block box” or just a “block”.
A box is assigned the same styles as its generating element, unless otherwise indicated. In general, inherited properties are assigned to the principal box, and then inherit through the box tree to any other boxes generated by the same element. Non-inherited properties default to applying to the principal box, but when the element generates multiple boxes, are sometimes defined to apply to a different box: for example, the border properties applied to a table element are applied to its table box, not to its principal table wrapper box. If the value computation process alters the styles of those boxes, and the element’s style is requested (such as through getComputedStyle()), the element reflects, for each property, the value from the box to which that property was applied.
Similarly, each contiguous sequence of sibling text nodes generates a text run containing their text contents, which is assigned the same styles as the generating text nodes. If the sequence contains no text, however, it does not generate a text run.
An anonymous box is a box that is not associated with any element. Anonymous boxes are generated in certain circumstances to fix up the box tree when it requires a particular nested structure that is not provided by the boxes generated from the element tree. For example, a table cell box requires a particular type of parent box (the table row box), and will generate an anonymous table row box around itself if its parent is not a table row box. (See [CSS2] § 17.2.1.) Unlike element-generated boxes, whose styles inherit strictly through the element tree, anonymous boxes (which only exist in the box tree) inherit through their box tree parentage.
In the course of layout, boxes and text runs can be broken into multiple fragments. This happens, for example, when an inline box and/or text run is broken across lines, or when a block box is broken across pages or columns. A box therefore consists of one or more box fragments, and a text run consists of one or more text fragments. See [CSS3-BREAK] for more information on fragmentation.
Note: Many of the CSS specs were written before this terminology was ironed out, or refer to things incorrectly, so view older specs with caution when they’re using these terms. It should be possible to infer from context which term they really mean. Please report errors in specs when you find them, so they can be corrected.
Note: Further information on the “aural” box tree and its interaction with the display property can be found in the CSS Speech Module. [CSS-SPEECH-1]
1.1. Module interactionsThis module replaces and extends the definition of the display property defined in [CSS2] section 9.2.4.
None of the properties in this module apply to the ::first-line or ::first-letter pseudo-elements.
This specification follows the CSS property definition conventions from [CSS2]. Value types not defined in this specification are defined in CSS Values & Units [CSS-VALUES-3]. Other CSS modules may expand the definitions of these value types.
In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the CSS-wide keywords keywords as their property value. For readability they have not been repeated explicitly.
2. Box Layout Modes: the display propertyThe display property defines an element’s display type, which consists of the two basic qualities of how an element generates boxes:
the inner display type, which defines (if it is a non-replaced element) the kind of formatting context it generates, dictating how its descendant boxes are laid out. (The inner display of a replaced element is outside the scope of CSS.)
the outer display type, which dictates how the principal box itself participates in flow layout.
Text runs have no display type.
Some display values have additional side-effects: such as list-item, which also generates a ::marker pseudo-element, and none, which causes the element’s entire subtree to be left out of the box tree.
The
displayproperty has no effect on an element’s semantics: these are defined by the
document languageand
are not affected by CSS. Aside from the
nonevalue, which also affects the aural/speech output
[CSS-SPEECH-1]and interactivity of an element and its descendants, the
displayproperty only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element
withoutaffecting the underlying document semantics.
Values are defined as follows:
<display-outside> = block | inline | run-in ;
<display-inside> = flow | flow-root | table | flex | grid | ruby ;
<display-listitem> = <display-outside>? && [ flow | flow-root ]? && list-item;
<display-internal> = table-row-group | table-header-group |
table-footer-group | table-row | table-cell |
table-column-group | table-column | table-caption |
ruby-base | ruby-text | ruby-base-container |
ruby-text-container ;
<display-box> = contents | none ;
<display-legacy> = inline-block | inline-table | inline-flex | inline-grid ;
The following informative table summarizes the values of display:
Note: Following the precedence rules of “most backwards-compatible, then shortest”, serialization of equivalent display values uses the “Short display” column. [CSSOM]
2.1. Outer Display Roles for Flow Layout: the block, inline, and run-in keywordsThe <display-outside> keywords specify the element’s outer display type, which is essentially its principal box’s role in flow layout. They are defined as follows:
If a <display-outside> value is specified but <display-inside> is omitted, the element’s inner display type defaults to flow.
2.2. Inner Display Layout Models: the flow, flow-root, table, flex, grid, and ruby keywordsThe <display-inside> keywords specify the element’s inner display type, which defines the type of formatting context that lays out its contents (assuming it is a non-replaced element). They are defined as follows:
If its outer display type is inline or run-in, and it is participating in a block or inline formatting context, then it generates an inline box.
Otherwise it generates a block container box.
Depending on the value of other properties (such as position, float, or overflow) and whether it is itself participating in a block or inline formatting context, it either establishes a new block formatting context for its contents or integrates its contents into its parent formatting context. See CSS2.1 Chapter 9. [CSS2]
If a <display-inside> value is specified but <display-outside> is omitted, the element’s outer display type defaults to block—except for ruby, which defaults to inline.
2.3. Generating Marker Boxes: the list-item keywordThe list-item keyword causes the element to generate a ::marker pseudo-element [CSS-PSEUDO-4] with the content specified by its list-style properties (CSS 2.1§12.5 Lists) [CSS2] together with a principal box of the specified type for its own contents.
If no inner display type value is specified, the principal box’s inner display type defaults to flow. If no outer display type value is specified, the principal box’s outer display type defaults to block.
Note: In this level, as restricted in the grammar, list-items are limited to the Flow Layout display types (block/inline/run-in with flow/flow-root inner types). This restriction may be relaxed in a future level of this module.
2.4. Layout-Internal Display Types: the table-* and ruby-* keywordsSome layout models, such as table and ruby, have a complex internal structure, with several different roles that their children and descendants can fill. This section defines those “layout-internal” display values, which only have meaning within that particular layout mode.
Unless otherwise specified, both the inner display type and the outer display type of elements using these display values are set to the given keyword.
The <display-internal> keywords are defined as follows:
table-cell boxes have a flow-root inner display type.
table-caption boxes have a flow-root inner display type.
ruby-base and ruby-text have a flow inner display type.
Boxes with layout-specific display types generate anonymous wrapper boxes around themselves when placed in an incompatible parent, as defined by their respective specifications.
For example, Table Layout requires that a
table-cellbox must have a
table-rowparent box.
If it is misparented, like so:
<div style="display:block;"> <div style="display:table-cell">...</div> </div>
It will generate wrapper boxes around itself, producing a structure like:
block box └anonymous table box └anonymous table-row-group box └anonymous table-row box └table-cell box
Even if the parent is another internal table element, if it’s not the correct one, wrapper boxes will be generated. For example, in the following markup:
<div style="display:table;">
<div style="display:table-row">
<div style="display:table-cell">...</div>
</div>
</div>
Anonymous wrapper box generation will produce:
table box └anonymous table-row-group box └table-row box └table-cell box
This "fix-up" ensures that table layout has a predictable structure to operate on.
2.5. Box Generation: the none and contents keywordsWhile display can control the types of boxes an element will generate, it can also control whether an element will generate any boxes at all.
The <display-box> keywords are defined as follows:
Note: As only the box tree is affected, any semantics based on the document tree, such as selector-matching, event handling, and property inheritance, are not affected.
This value behaves as display: none on replaced elements and other elements whose rendering is not entirely controlled by CSS; see Appendix B: Effects of display: contents on Unusual Elements for details.
Note: Replaced elements and form controls are treated specially because removing only the element’s own generating box is a more-or-less undefined operation. As this behavior may be refined if use cases (and more precise rendering models) develop, authors should use display: none rather than display: contents on such elements for forward-compatibility.
Similarly, if a text node is defined to behave as display: none, it generates no text runs.
Elements with either of these values do not have inner or outer display types, because they don’t generate any boxes at all.
Note: As these values cause affected elements to not generate a box, anonymous box generation rules will ignore the elided elements entirely, as if they did not exist in the box tree.
Markup-based relationships, however, are not affected by these values, as they are solely rendering-time effects. For example, although they may affect which table cell appears in a column, they do not affect which table cell is associated with a particular column element. Similarly, they cannot affect which HTML summary element is associated with a particular table or whether a legend is the name of a fieldset.
CSS level 2 used a single-keyword syntax for display, requiring separate keywords for block-level and inline-level variants of the same layout mode. These <display-legacy> keywords map as follows:
Some layout effects require blockification or inlinification of the box type, which sets the box’s outer display type to block or inline (respectively). (This has no effect on display types that generate no box at all, such as none or contents.) Additionally:
If a block flow box is inlinified, its inner display type is set to flow-root so that it remains a block container.
If an inline flow box is inlinified, it recursively inlinifies all of its in-flow children, so that no block-level descendants break up the inline formatting context in which it participates.
For legacy reasons, if an inline flow-root box (aka inline-block) is blockified, it becomes a block box (losing its flow-root nature). For consistency, a run-in flow-root box also blockifies to a block box.
If a layout-internal box is blockified, its inner display type converts to flow so that it becomes a block container. Inlinification has no effect on layout-internal boxes. (However, placement in such an inline context will typically cause them to be wrapped in an appropriately-typed anonymous inline-level box.)
Note: There are two methods used to fix up box types when a box is mismatched to its context. One is transformation of the computed value of display, such as blockification and inlinification described here. The other, taking place during box tree construction (after computed values have been determined), is the creation of intermediary anonymous boxes, such as happens in tables, ruby, and flow layout.
The root element’s display type is always blockified. Additionally, a display of contents computes to block on the root element.
3. Run-In LayoutA run-in box is a box that merges into a block that comes after it, inserting itself at the beginning of that block’s inline-level content. This is useful for formatting compact headlines, definitions, and other similar things, where the appropriate DOM structure is to have a headline preceding the following prose, but the desired display is an inline headline laying out with the text.
For example, dictionary definitions are often formatted so that the word is inline with the definition:
<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>
Which is formatted as:
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 behaves exactly as any other inline-level box, except:
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.
A run-in sequence is a maximal sequence of consecutive sibling run-in boxes and intervening white space and/or out-of-flow boxes.
Note: This statement implies that out-of-flow boxes are reparented if they are between two run-in boxes. Another alternative would be to leave behind the intervening out-of-flow boxes, or to have out-of-flow boxes impede the running-in of earlier boxes. Implementers and authors are encouraged to contact the CSSWG if they have a preferred behavior, as this one was picked somewhat at random.
This fixup occurs before the anonymous block and inline box fixup described in CSS2§9.2, and affects the determination of the first formatted line of the affected elements as if the run-in sequence were originally in its final location in the box tree.
Note: As the earliest run-in represents the first text on the first formatted line of its containing block, a ::first-letter pseudo-element applied to that block element selects the first letter of the run-in, rather than the first letter of its own contents.
Note: This run-in model is slightly different from the one proposed in earlier revisions of [CSS2].
Appendix A: GlossaryThe following terms are defined here for convenience:
Some elements may generate additional boxes in addition to the principal box (such as list-item elements, which generate an additional marker box, or table elements, which generate a principal table wrapper box and an additional table box). These additional boxes are placed with respect to the principal box.
Any inline-level box whose inner display type is not flow establishes a new formatting context of the specified inner display type.
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.
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 elments (display: block) and flex containers (display: flex), for example, are not block containers.
img element is often replaced by the image that its src attribute designates. Replaced elements often have intrinsic dimensions: an intrinsic width, an intrinsic height, and an intrinsic ratio. For example, a bitmap image has an intrinsic width and an intrinsic height specified in absolute units (from which the intrinsic ratio can obviously be determined). On the other hand, other documents may not have any intrinsic dimensions (for example, a blank HTML document).
User agents may consider a replaced element to not have any intrinsic dimensions if it is believed that those dimensions could leak sensitive information to a third party. For example, if an HTML document changed intrinsic size depending on the user’s bank balance, then the UA might want to act as if that resource had no intrinsic dimensions.
The content of replaced elements is not considered in the CSS formatting model; however, their intrinsic dimensions are used in various layout calculations.
A non-replaced element is one that is not replaced, i.e. whose rendering is dictated by the CSS model.
When a box establishes a new 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 the rules and contents of the formatting context outside the box, and vice versa. However, certain types of formatting context 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.
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 formatting context boundaries. (At time of writing, they are the only layout feature that can.) [CSS3-EXCLUSIONS]
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)
Note: some formatting contexts inhibit floating, so that an element with float: left is not necessarily out-of-flow.
See [CSS2] Chapter 9 for a fuller definition of these terms.
Appendix B: Effects of display: contents on Unusual ElementsThis section is (currently) non-normative.
Some elements aren’t rendered purely by CSS box concepts; for example, replaced elements (such as img), many form controls (such as input), and SVG elements.
This appendix defines how they interact with display: contents.
HTML Elementsbr
wbr
meter
progress
canvas
embed
object
audio
iframe
img
video
frame
frameset
input
textarea
select
display: contents behaves as display: none.
legend
Per HTML, a legend with display: contents is not a rendered legend, so it does not have magical display behavior. (Thus, it reacts to display: contents normally.)
button
details
fieldset
These elements don’t have any special behavior; display: contents simply removes their principal box, and their contents render as normal.
Behaves as normal for display: contents.
svg element that has CSS box layout (this includes all svg whose parent is an HTML element, as well as document root elements)
display: contents behaves as display: none.
use
display: contents strips the element from the formatting tree, and hoists its contents up to display in its place. These contents include the shadow-DOM content for use.
display: contents behaves as display: none.
When an element is stripped from the formatting tree, then any SVG attributes on that element that control the layout and formatting of its child content (or shadow DOM content) are ignored when rendering the contents. However, SVG presentation attributes continue to affect CSS property inheritance, the same as CSS styles set in any other way.
Is this description clear enough to identify the SVG attributes affected by display: contents? <https://github.com/w3c/csswg-drafts/issues/2502>
The intention here is that the
display: nonebehavior applies whenever the "rendering context" inside the element is different than the context outside of it. If the element’s child elements would not be valid children of the element’s parent, you cannot simply hoist them up the formatting tree.
For example, text content and text formatting elements in SVG require a text element context; if you remove a text, its child text content and elements are no longer valid. For that reason, display: contents on text prevents the entire text element from being rendered. In contrast, any content inside a tspan or textPath is also valid content inside the parent text formatting context, so the hoisting behavior applies for these elements.
Similarly, if hoisting would convert the children from non-rendered elements (e.g., a shape inside a pattern or symbol) to rendered elements (e.g., a shape that is a direct child of the svg), that is an invalid change of rendering context. Never-rendered container elements therefore cannot be "un-boxed" by display: contents. (Also, authors cannot override the display property on these elements: it is forced to none by an !important user agent style rule.)
For all MathML elements, display: contents behaves as display: none.
Appendix C: Box Construction Guidelines for Spec AuthorsThis section is non-normative guidance for specification authors.
A box cannot be blockified and inlinified at the same time; if such a thing would occur, define which wins over the other.
Non-principal non-anonymous boxes can’t be blockified: blockification affects the element’s computed values and thus determines the type of its principal box.
Boxes which blockify their contents can’t directly contain inline-level content; any boxes or text runs generated within such an element must be blockified or wrapped in an anonymous block container.
Boxes which inlinify their contents can’t directly contain block-level boxes; any boxes generated within such an element must be inline-level.
We would like to thank the many people who have attempted to separate out the disparate details of box generation over the years, most particularly Bert Bos, whose last attempt with display-model and display-role didn’t get anywhere, but primed us for the current spec, and Anton Prowse, whose relentless assault on CSS2.1 Chapter 9 forced some order out of the chaos. Honorable mentions also go to David Baron, Oriol Brufau, Mats Palmgren, and Boris Zbarsky for their feedback.
ChangesChanges since the 20 July 2017 Working Draft include:
Tightened up rules for the blockification of inline-block / inline flow-root to ensure compatibility with CSS2. (Issue 1246) Updated handling of run-in flow-root to match. (Issue 1715)
Adjusted grammar of display to list the list-item keyword last. This affects the expected serialization order. (Issue 1621)
Added better definition of interaction between block formatting contexts and inline formatting contexts in block containers that establish inline formatting contexts. (Issue 1553)
More clearly defined the way property values are reflected between an element and its boxes (in the case of an element generating multiple boxes). (Issue 1643)
Clarified that empty text objects are ignored for CSS rendering. (Issue 1808)
Clarified that display has no effect on document semantics, since this is a common bug in UAs. (Issue 2355)
Fixed error in definition of display’s computed value (which is definitely not “as specified”, due to blockification and inlinification rules triggered by various properties). (Issue 1716)
Added definition for document order.
Added missing SVG elements to Appendix B’s details on display: contents (Issue 2118), clarified effect of SVG attributes (Issue 2502), and defined behavior for MathML (Issue 2167).
Added some guidance to future spec authors of anonymous box construction rules. (Issue 1643)
Pushed the section about “becoming a formatting context” back to CSS Containment where it is used.
Various minor wording fixes and clarifications.
Changes since the 26 January 2017 Working Draft include:
Remove inline-list-item value that is equivalent to inline list-item.
Added the notion of “text nodes” to the element tree, and “text runs” to the box tree to define behavior in the context of display: contents. (Issue 19, Issue 32)
Defined that the root element is “in flow”. (Issue 3)
Defined interaction of ::first-line/::first-letter and run-in. (Issue 5, Issue 42)
Clarified that block/inline/run-in only dictates behavior in flow layout; it is ignored in other contexts.
Run-ins are a type of inline box, not just "like" an inline box.
Fixed the lack of recursion in of run-in’s box-tree munging. (Issue 45)
Added an appendix on how display: contents works on “unusual elements”. (Issue 8, Issue 18)
Fix blockification and inlinification rules, particularly handling of layout-internal types. (Issue 35, Issue 57)
Clarified interaction of various box tree fixups. (Issue 38, Issue 48)
Added the definition of becoming a formatting context.
Miscellaneous minor fixes and minor clarifications.
A Disposition of Comments is also available.
Changes since the 15 October 2015 Working Draft include:
Changes since the 21 July 2015 Working Draft include:
Changes since the 11 September 2014 Working Draft include:
This specification introduces no new privacy or security considerations.
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:
Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.
A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.
A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)
An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.
The following sections define several conformance requirements for implementing CSS responsibly, in a way that promotes interoperability in the present and future.
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported property values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.
Once a specification reaches the Candidate Recommendation stage, implementers should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec, and should avoid exposing a prefixed variant of that feature.
To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3