CSS Inline Layout Module Level 3

Copyright © 2018 W3C^® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

Status of this document

1. Introduction

This module defines the CSS Inline Layout model, replacing and extending the model as defined in CSS2.1. It is very much a work-in-progress, and implementers should reference CSS2.1 for now.

The root inline box is an anonymous inline box which is automatically generated to hold all of the inline-level contents of a block container (if it has any). It inherits from its parent block container, but is otherwise unstyleable.

Note: Line boxes, like column boxes [css-multicol-1], are fragmentation containers generated by their formatting context and are not part of the CSS box tree.

2. Line Heights and Baseline Alignment

This section is being rewritten. Refer to section 10.8 of [CSS2] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.) The CSS2 specification should be used as the guideline for implementation.

The CSSWG would like to know which baseline values are necessary: if any can be dropped, or any need to be added. See GitHub issue 859.

2.1. Dominant Baselines: the dominant-baseline property

This property specifies the dominant baseline, which is the baseline used to align the box’s text and inline-level contents. It is also indicates the default alignment baseline of any boxes participating in baseline alignment in the box’s alignment context. Values have the following meanings:

However, in SVG text, the origin point of glyphs (used for coordinate-based glyph positioning) is always handled as for central in vertical writing modes.

See [CSS3-WRITING-MODES] for an introduction to dominant baselines.

Should be text-over and text-under instead of text-top and text-bottom, but maybe it’s better not to use those terms for consistency with legacy vertical-align. See GitHub issue 860.

Add first and last values. Note, in this property, these are combinatorial, whereas in the align/justify-self/content properties, it’s singular. Do we want to align the syntaxes wrt hyphens vs. spaces or what? See GitHub issue 861.

2.2. Transverse Box Alignment: the vertical-align property

This shorthand property specifies how an inline-level box is aligned within the line. Values are the same as for its longhand properties, see below.

Authors should use this property (vertical-align) instead of its longhands.

This property will gain first and last keywords, like in the box alignment properties, see CSS Box Alignment 3 §4.2 Baseline Alignment: the baseline keyword and first/last modifiers. The open question is whether they should be added to alignment-baseline or a new sub-property should be created to hold the first | last preference.

2.2.1. Alignment Point: alignment-baseline longhand

Specifies what point of an inline-level box is aligned to what point in the parent. Also selects the alignment baseline of boxes aligned with align-self/justify-self.

Clean up this prose to correctly handle alignment contexts other than inline formatting contexts.

Values are defined below:

For the following definitions, the margin box is used for atomic inlines, the leading box for non-replaced inlines, and the baselines of the box are synthesized if missing in the line-box’s inline axis:

For the following definitions, the alignment subtree is as defined in [CSS2].

SVG implementations may support the following aliases in order to support legacy content:

text-before-edge = text-top
text-after-edge = text-bottom

These values are not allowed in the vertical-align shorthand.

2.2.2. Alignment Shift: baseline-shift longhand

This property specifies by how much the box is shifted up from its alignment point. It does not apply when alignment-baseline is top or bottom.

Authors should use the vertical-align shorthand instead of this property.

Values have the following meanings:

User agents may additionally support the keyword baseline as computing to 0 if is necessary for them to support legacy SVG content.

We would prefer to remove this, and are looking for feedback from SVG user agents as to whether it’s necessary.

3. Drawing Inline Boxes

3.1. Inline Box Heights: the inline-sizing property

This property specifies how the logical height of the content area of an inline box is measured and how it is aligned with its contents. (It has no effect on the size or position of the box’s contents.) Values have the following meanings:

We might want to use this opportunity to more precisely define normal, rename it to match, and possibly introduce any other values that may seem necessary.

4. Initial Letters

The editors would appreciate any examples of drop initials in non-western scripts, especially Arabic and Indic scripts.

4.1. An Introduction to Initial Letters

This section is non-normative.

Large, decorative letters have been used to start new sections of text since before the invention of printing. In fact, their use predates lowercase letters entirely.

4.1.1. Drop Initial

A dropped initial (or “drop cap”) is a larger-than-usual letter at the start of a paragraph, with a baseline at least one line lower than the first baseline of the paragraph. The size of the drop initial is usually indicated by how many lines it occupies. Two- and three-line drop initials are very common.

The exact size and position of a dropped initial depends on the alignment of its glyph. Reference points on the drop cap must align precisely with reference points in the text. The alignment constraints for drop initials depend on the writing system.

In Western scripts, the top reference points are the cap height of the initial letter and of the first line of text. The bottom reference points are the alphabetic baseline of the initial letter and the baseline of the Nth line of text. Figure 2 shows a simple two-line drop cap, with the relevant reference lines marked.

In Han-derived scripts, the initial letter extends from the block-start edge of the glyphs on the first line to the block-end edge of the glyphs on the Nth line.

In certain Indic scripts, the top alignment point is the hanging baseline, and the bottom alignment point is the text-after-edge.

4.1.2. Sunken Initial Letters

Some styles of drop initials do not align with the first line of text. A sunken initial (or “sunken cap”) both sinks below the first baseline, and extends above the first line of text.

4.1.3. Raised Initial Letters

A raised initial (often called a “raised cap” or “stick-up cap”) “sinks” to the first text baseline.

Note: A proper raised initial has several advantages over simply increasing the font size of a first letter. The line spacing in the rest of the paragraph will not be altered, but text will still be excluded around large descenders. And if the size of raised initial is defined to be an integral number of lines, implicit baseline grids can be maintained.

4.2. Selecting Initial Letters

Initial letters are typically a single letter, although they may include punctuation or a sequence of characters which are perceived by the user to be a single typographic unit. The ::first-letter pseudo-element, as defined in [SELECT], can be used to select the character(s) to be formatted as initial letters.

Authors who need more control over which characters are included in an initial letter, or who want to apply initial-letters formatting to replaced elements or multiple words can alternately apply the initial-letters property to the first inline-level child of a block container.

<p>This paragraph has a dropped “T”.
<p><img alt="H" src="illuminated-h.svg">ere we have an illuminated “H”.
<p><span>Words may also</span> be given initial letter styling at the beginning of a paragraph.

::first-letter, /* style first paragraph’s T */
img, /* style illuminated H */
span /* style phrase inside span */
{ initial-letters: 2; }

4.2.1. Initial Letter Punctuation

Since ::first-letter selects punctuation before or after the first letter, these characters are included in the initial-letters when ::first-letter is used.

Should there be a way to opt out of this behavior? See Github Issue 310.

4.3. Creating Initial Letters: the initial-letters property

Renaming this property (and the others in this section) is currently under discussion.

This property specifies styling for dropped, raised, and sunken initial letters. It takes the following values:

An initial letter is an in-flow box to which initial-letters applies and is not normal; this triggers the special layout considerations described below.

p::first-letter { initial-letters: 2; }

4.3.1. Applicability

To give authors more control over which characters can be styled as an initial letter and to allow the possibility of multi-character initial letters (such as for first word or first phrase styling), the initial-letters property applies not just to the CSS-defined ::first-letter pseudo-element, but also to inside-positioned ::marker pseudo-elements and inline-level boxes that are placed at the start of the first line. Specifically, initial-letters applies to any inline-level box—including any such ::first-letter or ::marker box—that is the first child of its parent box and whose ancestors (if any) that are descendants of its containing block are all first-child inline boxes that have a computed initial-letters value of normal.

<p><span><em><b>This phrase</b> is styled</em> <strong>specially</strong>. &hellip;</span>

em { initial-letters: 2; }
b { initial-letters: 3; }

[ADD RENDERING HERE]
THIS PHRASE IS STYLED specially. …

If initial-letters is applied to an inline-level box that is not positioned at the start of the line due to bidi reordering or which is otherwise preceded by other inline-level content, its used value is normal, and it is not formatted as an initial letter.

Note: The initial-letters property cannot apply to any element whose float is not none or position is not static, because these values cause its display to compute to block.

The effect of the initial-letters property is undefined on children of ruby base container boxes and on ruby container boxes.

4.3.2. Properties

All properties that apply to an inline box also apply to an initial letter (unless it is an atomic inline, in which case the set of properties that apply to an atomic inline apply) except for vertical-align and its sub-properties, font-size, and line-height. Additionally, all of the sizing properties and box-sizing also apply to initial letters.

4.3.3. Layout Model

An initial letter is laid out following the steps outlined below:

1. Find the used font size based on its initial-letters size, initial-letters-align alignment points, and font metrics. Note that no layout is required in this step. The font size used for sizing the initial letter contents does not affect its computed font-size property (and therefore has no effect on the computation of em length values, etc.).
2. Size the initial letter’s content box.

   If its width/height is definite, use that value (clamped as required by the min size and max size properties, and handling box-sizing as required) for that dimension of the box. In the case of a definite inline size, text-align is honored for aligning the contents of the initial letter within its box in the inline axis (using its inline-axis bearings as usual, not the bounding box of its glyph outlines). In the case of a definite block size, align-content is honored for aligning its contents in the block axis (using its block-axis bearings, synthesizing them if needed).

   Otherwise it is considered to have an automatic size in that dimension and is sized and positioned to coincide with the smallest rectangle that would include the bounding boxes of all its glyphs—excluding any that hang (see hanging-punctuation)—as well as the margin boxes of any atomic inlines it contains.

   Should the hanging punctuation be included in the box instead (so that the box is drawn around the punctuation when it is made visible through borders/background), but rather only excluded when positioning the box (so that the initial letter remains flush, with the hanging punctuation properly hanging)? See discussion.

3. In the inline axis, the initial letter’s margin box is placed at the start edge of the line. If it is a non-atomic inline with an automatic inline size and has no padding or borders, it is negatively offset by the distance from the start edge of its content box to the point in the content that would have been placed at the start edge of the containing block if it had initial-letters: none.

   In the block axis, the initial letter is anchored to the dominant baseline of the first formatted line, positioned with respect to that baseline such that it would sink the number of lines specified by initial-letters’s second argument if its containing block held only the initial letter itself followed by an infinite sequence of plain text as the direct contents of its root inline box.

   

4. Exclude content within the inline letter’s margin box according to initial-letters-wrap.

4.3.4. Content-box Size, Margins, Borders, and Padding

Initial letters can be styled with margins, padding, and borders just like any other box. Unless initial-letters-align is border-box, its vertical alignment and sizing are not affected; however the effective exclusion area is (and corresponds to the margin area).

When padding and borders are zero, the initial letter may be kerned; see below.

4.4. Alignment of Initial Letters: the initial-letters-align property

As mentioned earlier, the alignment of initial letters depends on the script used. The initial-letters-align property can be used to specify the proper alignment.

This property specifies the alignment points used to size and position an initial letter. Two sets of alignment points are necessary: the over and under alignment points of the initial letter are matched to corresponding over and under points of the surrounding text.

Values have the following meanings:

Is there a proper typographic term for the hebrew “hanging” baseline?

span.initial {
  initial-letters: 2;
  initial-letters-align: ideographic;
}

span.initial {
initial-letters: 2;
initial-letters-align: hebrew;
}

Except when border-box is specified, the alignment points of the initial letter are automatically determined from its contents:

1. If the initial letter is an atomic inline, use its over and under content-box edges.
2. Else if the initial letter contains any character from the Han, Hangul, Kana, or Yi Unicode scripts, use the ideographic character face bottom and top edge baselines.
3. Else if the initial letter contains any character from the Devanagari, Bengali, and Gurmukhi Unicode scripts, use the hanging and alphabetic baselines.
4. Else if the initial letter contains any character from the Hebrew Unicode scripts, use the ideographic character face bottom and top edge baselines.
5. Else use the alphabetic and cap-height baselines.

What is the proper alignment for South Asian scripts that do not have the explicit hanging baseline, such as Tamil or Telugu? See GitHub issue 864

Note: The ordering of keywords in this property is fixed in case border-box is expanded to [ border-box | alphabetic | ideographic | hebrew | hanging ] to allow explicitly specifying the initial letter’s alignment points.

4.4.1. UA Default Stylesheet for initial-letters-align

In order to provide the better behavior by default, UAs must include in their default UA style sheet the following rules:

[lang]:lang(zh, ja, ko, ii) {
  initial-letters-align: ideographic;
}
[lang]:lang(iw, yi, lad, jrb) {
  initial-letters-align: hebrew;
}
[lang]:lang(hi, mr, ne, pi, kok, brx, mai, sd, sa) {
  initial-letters-align: hanging;
}
/* Script tags override language tags */
[lang]:lang('*-Latn', '*-Cyrl') {
  initial-letters-align: alphabetic;
}
[lang]:lang('*-Hani', '*-Hant', '*-Hans') {
  initial-letters-align: ideographic;
}

This only covers the most common cross-linguistic transcription systems. Should we include any other / all script tags in the UA style sheet?

4.5. Sizing Initial Letters

The size of a drop initial is determined by the need to satisfy the required alignment. For an N-line drop initial in a Western script, the cap-height of the letter needs to be (N – 1) times the line-height, plus the cap-height of the surrounding text. Note this height is not the font size of the drop initial.

Actually calculating this font size is tricky. For an N-line drop initial, we find the drop initial font size to be:

The line height used in this calculation is the line-height of the containing block (or, in the case where a baseline grid is in use, the baseline-to-baseline spacing required by the baseline grid [CSS3-LINE-GRID]). The contents of the lines spanned, and therefore any variation in their heights and positions, is not accounted for.

4.5.1. Shaping and Glyph Selection

When initial-letters is not normal, shaping should still occur across the box’s boundaries, see CSS Text 3 §8.3 Shaping Across Element Boundaries. For example, if the first letter of the Farsi word “پس” were styled with initial-letters: 2 1, both letters would be styled in their joined forms, with initial-form “ﭘ” as the initial letter, followed by the normally-styled final-form “ﺲ”. Note that the two letters might not always graphically connect, even when shaped in their joining forms.

Are there other things we need to consider here?

4.6. Space Around Initial Letters

The glyph(s) of an initial letter do not always fit within the specified sink. For example, if an initial letter has a descender, it could crash into the (n+1)th line of text. This is not desirable.

Text is therefore excluded around the glyph bounding boxes of the initial letters.

Specifically, for non-atomic initial letters, the content box of the element is sized to fit:

• The specified amount of sink (i.e the distance from the top alignment point to the bottom alignment point).
• The actual ascent and descent and side bearings of all the glyphs it contains that are part of its inline formatting context, even if they leak outside their em boxes.
• The margin boxes of all the atomic inlines it contains that are part of its inline formatting context, even if they leak outside its own line-height.

The margin box of the initial letter is then made an exclusion area for subsequent text.

4.7. Positioning and Kerning Initial Letters

In the block axis, the initial letter is positioned to satisfy its alignment requirements. (See initial-letters-align.)

In the inline axis, the position of the inline letter is given by aligning its start margin edge to the start edge of the containing block.

However, if the initial letter is a non-atomic inline with zero padding and borders, the UA must apply an additional negative offset on the start side, of the amount necessary to optically align the first glyph to the containing block edge as it would be in normal text.

4.8. Initial Letter Wrapping: the initial-letters-wrap property

Note: initial-letters-wrap is at risk.

This property specifies whether lines impacted by an initial letter are shortened to fit the rectangular shape of the initial letter box or follow the contour of its end-edge glyph outline.

This example shows why contour-fitting the first line is necessary, and why it is dropped when the initial letter is followed by a space:

Do we need an unconditional first? (I.e. Should we rename this value to auto and add a first value that does not check for spaces?) See GitHub issue 410

If the value of shape-outside is not none, shape-outside is used instead of the glyph outline.

Note: This value is at-risk.

Note: In this example, the exclusion area for the drop initial is larger than its glyph in order to preserve inline-axis alignment.

Note: This value is also at-risk.

This really needs font-relative lengths to be relative to the used size.

Note: This value exists because it is easier to implement. Authors are encouraged to use the first value and to set margins to control spacing, and to use this as a fallback for glyph detection if necessary.

h1 + p:first-letter {
  initial-letters: 3; /* 3-line drop-cap */
  initial-letters-wrap: first;
  margin-right: 0.1em;
}
@supports (not (initial-letters-wrap: first)) {
  /* Classes auto-generated on paragraphs to match first letter. */
  p.A:first-letter {
    initial-letters-wrap: -40%; /* Start of glyph outline, assuming correct font. */
  }
}

These values and related annoyance is likely unnecessary if someone submits a patch to Blink to support first.

Edit figure to show how auto behaves in varying contexts

p::first-letter {
  initial-letters: 3;
  initial-letters-wrap: none;
}

p::first-letter {
  initial-letters: 3;
  initial-letters-wrap: all;
}

p::first-letter {
  initial-letters: 3;
  initial-letters-wrap: first;
}

p::first-letter {
  initial-letters: 3;
  initial-letters-wrap: all;
}

4.9. Line Layout

An initial letter box is considered in-flow in its block formatting context, and is part of the contents of the line box in which it originates. Aside from vertical alignment, its interaction with the rest of the contents of the line is as normal, except in a few specific circumstances…

4.9.1. Inline Flow Layout: Alignment and Justification

For a raised initial no special consideration is given for alignment and justification: it is treated similar to any other inline-level content.

However, for a sunken initial its inline-start edge is anchored to the inline-start edge of the line box (after indentation) and text alignment affects the remaining content of the line in the remaining space, without moving the initial letter box itself.

Note: The CSSWG was not aware of any reasonable use cases for mixing non-start text alignment with dropped initial letters, and this was the most sensible behavior proposed. This behavior may be reconsidered if use cases require otherwise.

In addition, to ensure consistent alignment of all the impacted lines, any letter-spacing or justification opportunity that would normally be introduced by the juxtaposition of the contents of a sunken initial and the subsequent contents of the line is suppressed. (Note that this does not affect word-spacing or the justification opportunity introduced by a word separator because that space is provided by the typographic character unit alone and not by its juxtaposition with an adjacent character.)

4.9.2. Edge Effects: Indentation and Hanging Punctuation

text-indent and hanging-punctuation apply to the first line of text as normal in the presence of initial letters. Lines affected by the exclusion are shortened, as in the presence of floats, and are affected the same way.

The interaction of initial-letter and hanging-punctuation is under discussion.

4.9.3. Ancestor Inlines

If the initial letter box is contained by inline box ancestors, the boundaries of those inline boxes are drawn to exclude the initial letter box, as if it were outside their startmost margin edge. This is a purely geometric operation: it does not affect e.g. property inheritance or the effective letter-spacing between the initial letter box and subsequent content.

4.9.4. Multi-line Initial Letters

4.10. Clearing Initial Letters

4.10.1. Raised and sunken caps

The margin box of an initial letter contributes to the size of its containing element. Initial letters that extend above the first line of text, known as “raised caps” or “sunken caps,” do not extend up into previous elements. Since the content box for an initial letter includes all glyph ink, this also means that accents or other ink above the cap height of an initial letter will not impinge on previous elements.

Handle glyph ink above cap height of font. Proposal: Make it an exclusion area for line boxes and border boxes. Include margin specified on initial-letters as part of exclusion area in order to control spacing.

Draw a box model diagram here. Does the margin of the initial letter collapse with its container?

4.10.2. Short paragraphs with initial letters

A paragraph with an initial letter can have fewer lines of text than the initial letter occupies. In this case, the initial letter’s top alignment is still honored, and its exclusion area continues into any subsequent blocks. This forces the subsequent inline-level content to wrap around the initial letter—exactly as if that block’s text were part of its own containing block. (This is similar to how floats exclude content in subsequent block boxes.)

If the subsequent block starts with an initial letter, establishes an independent formatting context, or specifies clear in the initial letter’s containing block’s start direction, then it must clear the previous block’s initial letter.

4.10.3. Interaction with floats

Initial letters are not floats: they are in-flow inline-level content that belongs to a line box. Therefore:

• The clear property does not care about initial letters: it neither applies to initial letters nor clears them when applied to nearby floats.
• Like line boxes or floats, initial letter boxes must not overlap the margin boxes of any floats participating in the same block formatting context. An overlapping initial letter box is shifted inward or downward until either it fits without overlapping or there are no more floats present.
• If a line box’s start edge shifts or moves down to clear a float, an initial letter originating in it moves with it; likewise if an initial letter shifts inward or moves downward to clear a float, its originating line box and subsequent line boxes shorten and/or move accordingly.
• If an inline-start float originates in the first line of content adjacent to an initial letter, then it moves past the initial letter towards the containing block edge, exactly as if the initial letter were any other inline-level content.

  However, if such a float originates in subsequent lines of content adjacent to a (sunk) initial letter, then that float must clear the initial letter.

See CSS2§9.5 for more information about the layout of floats and adjacent content. [CSS2]

Whether an inline-end float originating in subsequent lines must clear the initial letter (as inline-start floats do) is still under discussion. There is no aesthetic reason to require it; however it’s yet unclear how the underlying layout model would distinguish between the two cases.

4.10.4. Interaction with Fragmentation (Pagination)

Since a single glyph cannot be fragmented across pages (or columns or other fragmentation containers), an initial letter is considered monolithic [css-break-3] for the purpose of block-axis fragmentation (breaking across pages, columns, regions, etc.). Additionally, breaks between the in-flow lines alongside an initial letter box are avoided, much as breaks between line boxes affected be widows and orphans are avoided. However, if there is a forced break alongside the initial letter box, then it takes precedence; but has no effect on the initial letter box itself.

As with other monolithic objects, if an initial letter box occurs at the top of a fragmentation container and that fragmentation container is too short to contain it, it may be either truncated or sliced. Adjacent content, however, must be fragmented according to its own rules, not truncated or sliced along with the initial letter.

Appendix A: Synthesizing Alignment Metrics

A.1: Synthesizing Baselines (and Other Font Metrics) for Text

Some fonts might not contain the metrics information necessary to align text properly as described in this module. User agents may use the following strategies in the absence of a required metric:

The amount by which the lowercase “o” descends below the alphabetic baseline can be subtracted from its highest point to measure the x-height.

Pick a default.

Somebody sanity-check these heuristics please.

• x-height: .5em;
• cap-height: .66em;
• hanging baseline: .6em;
• Hebrew hanging baseline: ???

A.2: Synthesizing Baselines for Replaced Content

Copy over text from CSS Writing Modes and expand for additional baseline values.

Note: Authors can use margins (positive or negative) to adjust the alignment of replaced content within a line.

img[src^="/text/"] {
  height: 1em; /* Size to match adjacent text */
  margin-bottom: -0.2em; /* Baseline at 20% above bottom */
}
...
<p>This is some text with words written in an unencoded script:
<img src="/text/ch3439.png" alt="...">
  <img src="/text/ch3440.png" alt="...">
  <img src="/text/ch3442.png" alt="...">

Note: A future level of CSS may include a way of specifying a full baseline table for replaced elements. (This will probably look like a baseline-table property that accepts ''[<baseline-keyword> <percentage>]+''.)

Changes

Changes since the 24 May 2016 Working Draft include:

• Added outline of property to control the logical height of inline boxes. (Issue 1974)
• Better defined handling of initial letters that are descendants of other inline boxes and clarified applicability in the presence of ::marker, bidi reordering, and other complications. (Issue 2184, Issue 2705)
• Defined interaction of initial letters and text-align, letter-spacing, and justification. (Issue 884)
• Renamed initial-letter to initial-letters. (Issue 862)
• Better defined interaction of initial letters and floats. (Issue 360, Issue 689)
• Improved recommended default UA style sheet rules for initial letters.
• Changed applicability of properties to initial letters from explicit list to reference to properties applying to inline boxes (with a few exceptions). (Issue 2700)
• Defined sizing properties to apply to initial letters. (Issue 863)
• Defined shape-outside to apply to initial letters with initial-letter-wrap: all. (Issue 885)
• Specified that Arabic shaping applies between an initial letter and subsequent text. (Issue 2399)
• Defined interaction of initial letters and fragmentation. (Issue 2404)
• Fixed math errors in definition of initial-letter-wrap: grid. (Issue 947)

Acknowledgments

Special thanks goes to the initial authors, Eric A. Meyer and Michel Suignard.

In additions to the authors, this specification would not have been possible without the help from:

David Baron, David M Brown, Oriol Brufau, John Daggett, Stephen Deach, Sylvain Galineau, David Hyatt, Shinyu Murakami, Tess O’Connor, Sujal Parikh, Florian Rivoal, Alan Stearns, Bobby Tung, Chris Wilson, Grzegorz Zygmunt.

Conformance

Document conventions

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.

Conformance classes

Conformance to this specification is defined for three conformance classes:

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.

Requirements for Responsible Implementation of CSS

The following sections define several conformance requirements for implementing CSS responsibly, in a way that promotes interoperability in the present and future.

Partial Implementations

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.

Implementations of Unstable and Proprietary Features

To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.

Implementations of CR-level Features

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.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at https://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

Index

Terms defined by this specification

• alignment-baseline, in §2.2.1
• all, in §4.8
• alphabetic
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
  • value for initial-letters-align, in §4.4
• auto, in §2.1
• baseline
  • dfn for baseline-shift, in §2.2.2
  • value for alignment-baseline, in §2.2.1
• baseline-shift, in §2.2.2
• border-box, in §4.4
• bottom, in §2.2.1
• center, in §2.2.1
• central
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
• dominant baseline, in §2.1
• dominant-baseline, in §2.1
• dropped initial, in §4.1.1
• first, in §4.8
• grid, in §4.8
• hanging
  • value for dominant-baseline, in §2.1
  • value for initial-letters-align, in §4.4
• hebrew, in §4.4
• ideographic
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
  • value for initial-letters-align, in §4.4
• initial letter, in §4.3
• initial letter box, in §4.3
• initial-letters, in §4.3
• initial-letters-align, in §4.4
• initial letter sink, in §4.3
• initial letter size, in §4.3
• initial-letters-wrap, in §4.8
• inline-sizing, in §3.1
• <integer>, in §4.3
• <length>
  • value for baseline-shift, in §2.2.2
  • value for initial-letters-wrap, in §4.8
• mathematical
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
• middle
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
• none, in §4.8
• normal
  • value for initial-letters, in §4.3
  • value for inline-sizing, in §3.1
• <number>, in §4.3
• <percentage>
  • value for baseline-shift, in §2.2.2
  • value for initial-letters-wrap, in §4.8
• raised initial, in §4.1.3
• root inline box, in §1
• sink, in §4.3
• stretch, in §3.1
• sub, in §2.2.2
• sunken initial, in §4.1.2
• super, in §2.2.2
• text-after-edge, in §2.2.1
• text-before-edge, in §2.2.1
• text-bottom
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
• text-top
  • value for alignment-baseline, in §2.2.1
  • value for dominant-baseline, in §2.1
• top, in §2.2.1
• vertical-align, in §2.2

Terms defined by reference

• [css-align-3] defines the following terms:
  • align-content
  • align-self
  • alignment baseline
  • alignment context
  • baseline alignment
  • justify-self
  • last
  • synthesized baseline
• [css-break-3] defines the following terms:
  • forced break
  • fragment
  • fragmentation
  • fragmentation container
  • monolithic
  • orphans
  • widows
• [css-cascade-4] defines the following terms:
  • computed value
  • sub-property
  • used value
• [css-display-3] defines the following terms:
  • atomic inline
  • block
  • block container
  • block formatting context
  • box tree
  • containing block
  • formatting context
  • in-flow
  • independent formatting context
  • inline box
  • inline-level
  • inline-level box
• [css-fonts-3] defines the following terms:
  • font-size
• [css-lists-3] defines the following terms:
  • inside
• [css-multicol-1] defines the following terms:
  • column box
• [css-page-floats-3] defines the following terms:
  • none
• [css-position-3] defines the following terms:
  • position
  • static
• [css-pseudo-4] defines the following terms:
  • ::first-letter
  • ::marker
  • first formatted line
• [css-ruby-1] defines the following terms:
  • display
  • ruby
• [css-shapes-1] defines the following terms:
  • shape-outside
• [css-sizing-3] defines the following terms:
  • automatic size
  • box-sizing
  • max size
  • min size
  • sizing property
  • stretch fit
• [css-values-3] defines the following terms:
  • <integer>
  • <length>
  • <number>
  • <percentage>
  • ?
  • em
  • |
  • ||
• [css-writing-modes-4] defines the following terms:
  • block axis
  • block size
  • block-axis
  • block-end
  • block-start
  • height
  • horizontal writing mode
  • inline axis
  • inline size
  • inline-axis
  • inline-start
  • line-over
  • line-under
  • logical height
  • logical width
  • mixed
  • over
  • sideways
  • sideways-right
  • text-orientation
  • under
  • upright
  • vertical writing mode
  • width
• [CSS2] defines the following terms:
  • clear
  • float
  • line-height
• [css3-exclusions] defines the following terms:
  • content area
• [CSS3TEXT] defines the following terms:
  • content language
  • hang
  • hanging-punctuation
  • justification opportunity
  • letter-spacing
  • text-align
  • text-indent
  • typographic character unit
  • unicode script
  • word separator
  • word-spacing

References

Normative References

Informative References

Property Index

Issues Index