img#edge { width: 80%; height: 70%;}

dt.label { display: run-in; }

spec:css-align-3; type:dfn; text:alignment baseline

spec:css-backgrounds-3; type:property; text:box-shadow

spec:css-box; type:dfn; text:content area

spec:css-break-3; type:dfn; text:fragment

spec:css-shapes-1; type:property; text:shape-margin

spec:svg2; type:dfn; text: current text position

spec:css-writing-modes-3; type:dfn; text:baseline

spec:css-fonts-4; type:property; text:font-language-override

spec:css-align-3; type:value; for:align-content; text:center

spec:css2; type:value; for:float; text:none

spec:css-box-3; type:dfn; text:margin box

spec:css-box-3; type:dfn; text:margin edge

spec:css-box-3; type:dfn; text:padding edge

spec:css-box-3; type:dfn; text:border edge

spec:css-box-3; type:dfn; text:content edge

spec:css-display-3; type:dfn; text:inline box

spec:css-display-3; type:dfn; text:inline-level box

spec:css-display-3; type:dfn; text:in-flow

spec:css-display-3; type:dfn; text:containing block

This module defines [=inline layout=], the CSS model

for laying out a mixed stream of text and [=inline-level=] boxes,

and defines controls for the [=block-axis=] alignment and sizing

of this content within each line.

It also adds a [[#initial-letter-styling|special layout mode for drop caps and similar initial letter styling]].

Note: Line-breaking, justification, and other aspects of

inline-axis positioning of [=inline-level=] content

are handled in the <a href="https://www.w3.org/TR/css-text/">CSS Text Module</a>.

ISSUE: Many aspects of layout here depend on font metrics.

While the relevant metrics exist in OpenType for Latin/Cyrillic/Greek

and for <abbr title="Chinese/Japanese/Korean">CJK</abbr>,

they are missing for many other writing systems.

For example, the visual top metric for Hebrew has no metric in the OpenType tables.

For this module to work well for the world,

we need fonts to provide the relevant metrics for all writing systems,

and that means both that OpenType needs to allow such metrics

and font designers need to provide accurate numbers.

See <a href="https://github.com/w3c/csswg-drafts/issues/5244">issue</a> and

<a href="https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf">liaison statement</a>.

This module

replaces and extends the CSS inline layout model and features defined in

[[!CSS2]] section 10.8.

This specification follows the <a href="https://www.w3.org/TR/CSS2/about.html#property-defs">CSS property definition conventions</a> from [[!CSS2]]

using the <a href="https://www.w3.org/TR/css-values-3/#value-defs">value definition syntax</a> from [[!CSS-VALUES-3]].

Value types not defined in this specification are defined in CSS Values &amp; Units [[!CSS-VALUES-3]].

Combination with 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 <a>CSS-wide keywords</a> as their property value.

For readability they have not been repeated explicitly.

In <dfn>inline layout</dfn>,

a mixed, recursive stream of text and [=inline-level boxes=]

forming an <dfn>inline formatting context</dfn> within a [=block container=]

are laid out by [=fragmenting=] them into a stack of [=line boxes=].

Within each [=line box=],

[=inline-level boxes=] are [[#alignment|aligned to each other]] along the [=block axis=],

typically by the [=baselines=] of their text.

Any [=block container=] that directly contains

[=inline-level=] content--

such as [=inline boxes=], [=atomic inlines=], and [=text sequences=]--

establishes an [=inline formatting context=]

to lay out its contents using [=inline layout=].

The [=block container=]’s [=content edges=] form the [=containing block=]

for each of the [=inline-level boxes=]

participating in its [=inline formatting context=].

The [=block container=] also generates

a <dfn export>root inline box</dfn>,

which is an <a lt="anonymous box">anonymous</a> [=inline box=] that holds

all of its [=inline-level=] contents.

(Thus, all text in an [=inline formatting context=] is directly contained

by an [=inline box=],

whether the [=root inline box=] or one of its descendants.)

The [=root inline box=] inherits from its parent [=block container=],

but is otherwise unstyleable.

In an [=inline formatting context=],

content is laid out along the [=inline axis=],

ordered according to the

<a href="https://www.w3.org/TR/css-writing-modes-3/#text-direction">Unicode bidirectional algorithm and its controls</a> [[CSS-WRITING-MODES-3]]

and distributed according to the typesetting controls in [[CSS-TEXT-3]].

[=Inline-axis=] [=margins=], [=borders=], and [=padding=]

are respected between [=inline-level boxes=]

(and their margins do not <a href="https://www.w3.org/TR/CSS2/box.html#collapsing-margins">collapse</a>).

The resulting rectangular area that contains the boxes

that form a single line of [=inline-level content=]

is called a <dfn export>line box</dfn>.

Note: <a>Line boxes</a> and <a>inline boxes</a> and <a>inline-level boxes</a>

are each different things!

See [[CSS-DISPLAY-3]] for an in-depth discussion of box types and related terminology.

[=Line boxes=] are created as needed

to hold [=inline-level=] content

within an [=inline formatting context=].

When an [=inline box=] exceeds the [=logical width=] of a [=line box=],

or contains a <a spec="css-text-3">forced line break</a>,

it is split (see [[css-text-3#line-breaking]])

into several [=fragments=] [[CSS-BREAK-3]],

which are partitioned across multiple [=line boxes=].

Like [=column boxes=] in [=multi-column layout=] [[CSS-MULTICOL-1]],

[=line boxes=] are [=fragmentation containers=]

generated by their [=formatting context=],

and are not part of the CSS [=box tree=].

Note: [=Inline boxes=] can also be

<a href="https://www.w3.org/TR/css-writing-modes-3/#bidi-box-model">split into several fragments

within the same line box due to bidirectional text processing</a>.

See [[CSS-WRITING-MODES-3]].

[=Line boxes=] are stacked

as the direct contents of the [=block container box=]

in its [=block flow direction=]

and aligned within this container as specified by 'align-content' [[CSS-ALIGN-3]].

Thus, an [=inline formatting context=] consists of

a stack of [=line boxes=].

[=Line boxes=] are stacked with no separation

(except as specified elsewhere,

e.g. for [=float=] <a href="https://www.w3.org/TR/CSS2/visuren.html#clearance">clearance</a>)

and they never overlap.

In general,

the [=line-left=] edge of a [=line box=] touches

the [=line-left=] edge of its [=containing block=]

and the [=line-right=] edge touches

the [=line-right=] edge of its [=containing block=],

and thus the [=logical width=] of a line box is equal to

the <a lt="inner size">inner</a> [=logical width=]

of its [=containing block=]

(i.e. the [=block container=]’s [=content box=]).

However, floating boxes or [=initial letter boxes=]

can come between the [=containing block=] edge and the [=line box=] edge,

reducing the space available to, and thus the [=logical width=] of,

any such impacted [=line boxes=].

(See [[CSS2/visuren#inline-formatting]]/[[CSS2/visuren#floats]]

and [[#initial-letter-styling]].)

The [=logical height=] of a [=line box=] is fitted to its contents

once they have been [[#alignment|block-axis aligned]].

This fit is controlled by 'line-height' and 'line-fit-edge'.

The first/last line boxes in a [=block container=] may additionally

be trimmed by 'text-box-trim'.

<figure>

<img src="images/box-model.png" width="500" height="258"

<figcaption>Inline Layout Box Model</figcaption>

</figure>

As described [[#model|above]],

user agents flow [=inline-level boxes=] into a stack of [=line boxes=].

Layout within each [=line box=] is performed,

sizing and positioning each [=box fragment=] and [=line box=] independently,

as follows:

1. <strong>Baseline Alignment:</strong>

All [=in-flow=] [=inline-level boxes=] in the [=line box=]

are aligned to each other in the [=block axis=]

according to 'dominant-baseline' and 'vertical-align'.

This is referred to as [[#alignment|baseline alignment]].

Those with [=line-relative values=] for 'baseline-shift'

are assumed to be aligned so as to minimize the line box height.

2. <strong>Content Size Contribution Calculation:</strong>

The [=layout bounds=] (i.e. the size contributions)

of each [=inline-level box=] in the [=line box=]

are calculated:

<ul class=switch>

<li>

For [=atomic inlines=] such as [=replaced elements=] and [=inline blocks=]:

this is their [=margin box=].

<li>

For the [=root inline box=],

and for [=inline boxes=] with ''line-fit-edge: leading'':

this derived from their used 'line-height',

ignoring any [=margin=]/[=border=]/[=padding=];

see [[#inline-height]].

<li>

For other [=inline boxes=]:

this is derived from their 'line-fit-edge' metrics,

and includes any [=margin=]/[=border=]/[=padding=];

see [[#inline-height]].

</ul>

3. <strong>Line Box Sizing:</strong>

The [=line box=]’s [=logical height=] is sized

to exactly include the aligned [=layout bounds=]

of all its [=inline-level boxes=].

4. <strong>Content Positioning:</strong>

The [=root inline box=]’s [=aligned subtree=]

and boxes [=line-relative values=] for 'baseline-shift'

are positioned within the [=line box=].

Issue: Define what to do for top/bottom/center aligned boxes that are taller than the rest of the content.

Note: Empty [=inline boxes=] still have

[=margins=], [=padding=], [=borders=], and a 'line-height',

and thus influence these calculations just like boxes with content.

[=Line boxes=] that contain no text,

no [=preserved white space=],

no [=inline boxes=] with non-zero inline-axis [=margins=], [=padding=], or [=borders=],

and no other [=in-flow=] content

(such as [=atomic inlines=] or [=ruby annotations=]),

and do not end with a [=forced line break=]

are <dfn lt="phantom line box">phantom line boxes</dfn>.

Such boxes must be treated as zero-[=logical height|height=] [=line boxes=]

for the purposes of determining the positions of any descendant content

(such as [=absolutely positioned boxes=]),

and both the [=line box=] and its [=in-flow=] content

must be treated as not existing for any other layout or rendering purpose.

<details class=note>

<summary>What’s invisible?</summary>

Such [=phantom line boxes=], which can still contain

unstyled empty [=inline boxes=], [=out-of-flow=] boxes, and/or collapsed [=document white space=],

are ignored, for example, for:

* <a href="https://www.w3.org/TR/CSS2/box.html#collapsing-margins">margin collapsing</a>

* finding the [=first formatted line=]

* applying 'text-box-trim'

* [[css-break-4#break-propagation|fragmentation break propagation]]

* etc.

</details>

ISSUE: Firefox allows the inline boxes within a [=phantom line box=]

to accept 'outline',which allows it to make focus rings visible.

As in other browsers, all other properties that could make the element visible

(e.g. 'box-shadow')

seem to be ignored.

Except as specified for [=positioned boxes=] (see [[!CSS-POSITION-3]])

[=inline-level boxes=] are painted in [=document order=];

the 'z-index' property does not generally apply.

A <dfn export>baseline</dfn> is a line along the <a>inline axis</a> of a line box

along which individual glyphs of text are aligned.

[=Baselines=] guide the design of glyphs in a font

(for example, the bottom of most alphabetic glyphs

typically align with the alphabetic baseline),

and they guide the alignment of glyphs from different fonts or font sizes

when typesetting.

<figure>

<img alt="Picture of alphabetic text in two font sizes with the baseline and em-boxes"

<figcaption>

Alphabetic text in two font sizes with the baseline and em-boxes

</figcaption>

</figure>

Different writing systems prefer different [=baselines=].

<figure>

<img alt="Latin prefers the alphabetic baseline,

<figcaption>

Preferred baselines in various writing systems

</figcaption>

</figure>

A well-constructed font contains a <dfn>baseline table</dfn>,

which indicates the position of one or more [=baselines=]

within the font's design coordinate space.

(The design coordinate space is scaled with the font size.)

<figure>

<img alt=""

<figcaption>

In a well-designed mixed-script font,

the glyphs are positioned in the coordinate space

to harmonize with one another when typeset together.

The baseline table is then constructed

to match the shape of the glyphs,

each baseline positioned to match the glyphs

from its preferred scripts.

</figcaption>

</figure>

The [=baseline table=] is a property of the font,

and the positions of the various baselines

apply to all glyphs in the font.

Different [=baseline tables=] can be provided for alignment

in horizontal and vertical text.

UAs should use the vertical tables in vertical [=typographic modes=]

and the horizontal tables otherwise.

Note: Fonts can have more than one [=baseline table=] in each axis;

the UA is responsible for choosing the appropriate table

in consideration of 'font-language-override' and the [=content language=].

CSS uses the following text-based metrics

as [=baselines=]

for [=inline layout=] functions

such as alignment, box sizing, and initial letter layout.

Issue: The CSSWG would like to know which baseline values are necessary

for each property that uses them

('dominant-baseline', 'alignment-baseline', 'text-box-edge', 'line-fit-edge', 'initial-letter-align'):

if any can be dropped, or any need to be added.

See <a href="https://github.com/w3c/csswg-drafts/issues/859">Issue 859</a>.

<dl export>

<dt><dfn lt="alphabetic baseline" local-lt="alphabetic">alphabetic</dfn>

<dd>

Used in writing

Latin, Cyrillic, Greek, and many other scripts,

corresponds to the bottom of most, but not all, their characters,

(such as “m”, “Ш”, “Δ”).

Often represented as zero in font design coordinate systems;

assigned to <code>romn</code> in OpenType

and to <code>bsln</code> value zero in TrueType AAT.

<dt><dfn lt="cap-height baseline" local-lt="cap-height">cap-height</dfn>

<dd>

Corresponds to

the top of capital letters

(such as “T”, “Б”, “Σ”)

in Latin, Cyrillic, Greek, etc.

Calculated using <code>sCapHeight</code> in OpenType.

<dt><dfn lt="x-height baseline" local-lt="x-height">x-height</dfn>

<dd>

Corresponds to

the top of short lowercase letters

(such as “m”, “л”, “α”)

in Latin, Cyrillic, Greek, etc.

Calculated using <code>sxHeight</code> in OpenType.

<dt><dfn lt="x-middle baseline" local-lt="x-middle">x-middle</dfn>

<dd>

Corresponds to halfway between

the [=alphabetic=] and [=x-height=] baselines.

<dt><dfn lt="ideographic-over baseline" local-lt="ideographic-over">ideographic-over</dfn>

<dd>

Corresponds to

the [=line-over=] design edge of CJK (Han/Hangul/Kana) text.

Assigned to <code>idtp</code> in OpenType.

<dt><dfn lt="ideographic-under baseline" local-lt="ideographic-under">ideographic-under</dfn>

<dd>

Corresponds to

the [=line-under=] design edge of CJK (Han/Hangul/Kana) text.

Assigned to <code>ideo</code> in OpenType.

<dt><dfn lt="central baseline | ideographic central baseline" local-lt="central">central</dfn>

<dd>

Corresponds to the ideographic central baseline,

halfway between the [=ideographic-under=] and [=ideographic-over=] baselines.

Assigned to <code>bsln</code> value 1 in TrueType AAT.

<dt><dfn lt="ideographic-ink-over baseline" local-lt="ideographic-ink-over">ideographic-ink-over</dfn>

<dd>

Corresponds to the [=line-over=] ink edge of CJK (Han/Hangul/Kana) text.

Assigned to <code>icft</code> in OpenType.

<dt><dfn lt="ideographic-ink-under baseline" local-lt="ideographic-ink-under">ideographic-ink-under</dfn>

<dd>

Corresponds to the line-under ink edge of CJK (Han/Hangul/Kana) text.

Assigned <code>icfb</code> in OpenType.

<dt><dfn lt="hanging baseline" local-lt="hanging">hanging</dfn>

<dd>

Corresponds to hanging baseline

from which characters in

Tibetan and similar unicameral scripts

with a strong but not absolute top edge seem to “hang”.

Assigned to <code>hang</code> in OpenType

and to <code>bsln</code> value 3 in TrueType AAT.

<dt><dfn lt="math baseline" local-lt="math">math</dfn>

<dd>

Corresponds to center baseline around which mathematical characters are designed.

Assigned to <code>math</code> in OpenType

and <code>bsln</code> value 4 in TrueType AAT.

<dt><dfn lt="text-over baseline" local-lt="text-over">text-over</dfn>

<dd>

Corresponds to the metric used as the [=line-over=] edge

of an [=inline box|inline=]’s [=content box=] per [[CSS2]].

<dt><dfn lt="text-under baseline" local-lt="text-under">text-under</dfn>

<dd>

Corresponds to the metric used as the [=line-under=] edge

of an [=inline box|inline=]’s [=content box=] per [[CSS2]].

<dt><dfn lt="em-over baseline" local-lt="em-over">em-over</dfn>

<dd>

Corresponds to a conceptual [=ascent=] normalized

to ensure 1em between [=em-over=] and [=em-under=].

See [[#baseline-synthesis-em]].

<dt><dfn lt="em-under baseline" local-lt="em-under">em-under</dfn>

<dd>

Corresponds to a conceptual [=descent=] normalized

to ensure 1em between [=em-over=] and [=em-under=].

See [[#baseline-synthesis-em]].

</dl>

Note: These metrics are optical design metrics,

and therefore do not necessarily correspond exactly

to actual glyph outlines.

In general, these metrics are taken from the appropriate font,

but if they are missing or need to be derived from a box rather than text,

they must be synthesized,

see [[#baseline-tables]] and [[#baseline-synthesis]].

CSS assumes that every font has font metrics

that specify a characteristic height above the baseline--

called the <dfn local-lt="ascent">ascent metric</dfn>--

and a characteristic depth below it--

called the <dfn local-lt="descent">descent metric</dfn>--

which CSS uses for laying out text and boxes

in an [=inline formatting context=].

Note that these are metrics of the font as a whole

and need not correspond to the ascender and descender of any individual glyph.

Note: It is recommended that implementations that use OpenType or TrueType fonts

use the metrics <code>sTypoAscender</code> and <code>sTypoDescender</code>

from the font's OS/2 table

(after scaling to the current element's font size)

to find the [=ascent metric=] and [=descent metric=] for CSS layout.

In the absence of these metrics,

the "Ascent" and "Descent" metrics from the HHEA table should be used.

<!-- Note dependency from Canvas API fontBoundingBoxAscent/Descent

https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-fontboundingboxascent

-->

Font formats can allow for a font-recommended

“line gap” or “external leading” metric.

This metric is referred to as the <dfn>line gap metric</dfn>,

and may be incorporated into the [=line box=] [=logical height=] calculations

when 'line-height' is ''line-height/normal'' as described in [[#inline-height]].

Note: In OpenType, the [=line gap metric=] can be found

as <code>sTypoLineGap</code> or <code>hhea.lineGap</code>.

UAs must floor the [=line gap metric=] at zero.

Each font, glyph, and [=inline-level box=]

is assumed to have a [=baseline=] coordinate

for each [=baseline=] type

indicating that [=baseline=]’s position on its [=block axis=].

The set of such [=baselines=] is called its <dfn>baseline set</dfn>.

The [=baseline=] from this set that is used to align

the box or glyph within its [=alignment context=]

is called its [=alignment baseline=];

the [=baseline=] used to align its content within itself

is called its [=dominant baseline=].

For an individual glyph,

the [=baseline set=] derives from the font’s [=baseline table=].

For an [=inline box=],

it derives from its [=first available font=]

regardless of whether the box actually contains any glyphs from that font.

If the requisite metrics are missing from a font,

the UA must synthesize them,

see [[#baseline-synthesis-fonts]].

For other [=boxes=],

its [=baseline set=] is nominally derived from its contents

in accordance with 'baseline-source'

and the rules of the [=formatting context=] in which it participates.

For an [=atomic inline box=] with no [=baseline set=]

in the [=inline formatting context=]’s [=inline axis=]

its [=alignment baselines=] are [=synthesize baseline|synthesized=]

from its [=margin box=],

see [[#baseline-synthesis-box]].

While most CSS [=formatting contexts=] position content

by aligning boxes with respect to their container’s edges,

[=inline layout=] positions boxes in the [=block axis=]

by aligning them with respect to each other

using their [=baselines=].

More specifically,

(unless using a [=line-relative shift value=])

each glyph or [=inline-level box=]

is aligned in the [=block axis=]

by positioning its [=alignment baseline=]

to match the <em>corresponding</em> [=baseline=] of its parent

(which is its [=alignment context=]),

and then is potentially shifted from that position

according to its [=post-alignment shift=].

Note: Baseline alignment always matches corresponding baselines:

alphabetic to alphabetic, hanging to hanging, mathematical to mathematical, etc.

When aligning a [=box=], the [=alignment baseline=] is chosen

according to its 'alignment-baseline' and 'baseline-source' values

(see shorthand 'vertical-align'),

and defaults to matching the parent’s 'dominant-baseline'.

For a glyph, the [=alignment baseline=] is always determined

by the parent’s [=dominant baseline=].

<div class="example">

<p>Given following sample markup:

<pre highlight=html>&lt;p&gt;&lt;span class="outer"&gt;Ap &lt;span class="inner"&gt;ਜੀ&lt;/span&gt;&lt;/span&gt;&lt;/p&gt;</pre>

<p>And the following style rule:

<pre highlight=css>.inner { font-size: 75%; }</pre>

<p>The [=baseline sets=] of the parent (<code>.outer</code>) and the child (<code>.inner</code>)

will not match up due to the font size difference.

The child box is aligned to its parent

by matching up their [=alphabetic baselines=].

<figure>

<img alt="In this example, the distance between each baseline in the baseline set

</figure>

<p>The [=alphabetic baseline=] is used here

because by default a box’s [=alignment baseline=] matches

the [=dominant baseline=] of its parent,

and in horizontal [=typographic mode=],

the [=dominant baseline=] itself defaults to the [=alphabetic baseline=].

<p>If we add ''vertical-align: super''

to the <code>.inner</code> element from the example above,

the same rules are used to align the <code>.inner</code> child to its parent;

but in addition to the baseline alignment,

the child is shifted to the superscript position.

<figure>

<p><img alt="In this example, the resulting alignment is equivalent to

</figure>

</div>

<pre class="propdef">

This property specifies the <dfn>dominant baseline</dfn>,

which is the default baseline type used to align content within the box.

For [=inline boxes=],

the [=dominant baseline=] is used to align the box’s text

(and, unless otherwise specified by 'vertical-align', any [=inline-level=] child boxes)

by aligning each glyph/box’s corresponding baseline to the box’s own [=dominant baseline=].

For other boxes, it indicates the default <a>alignment baseline</a>

of any boxes participating in <a>baseline alignment</a>

in the box’s <a>alignment context</a>;

see (''alignment-baseline: baseline'' and [[CSS-ALIGN-3]]).

The <dfn><<baseline-metric>></dfn> value, which identifies

specific baseline metrics, expands to

<pre class=prod>

Values have the following meanings:

<dl dfn-for="dominant-baseline,<<baseline-metric>>" dfn-type=value>

<dt><dfn>auto</dfn>

<dd>

Equivalent to ''dominant-baseline/alphabetic'' in <a>horizontal writing modes</a>

and in <a>vertical writing modes</a>

when 'text-orientation' is ''sideways''.

Equivalent to ''dominant-baseline/central'' in <a>vertical writing modes</a>

when 'text-orientation' is ''text-orientation/mixed'' or ''text-orientation/upright''.

However, in SVG text, the origin point of glyphs

(used for coordinate-based glyph positioning)

is always handled as for ''dominant-baseline/central''

in <a>vertical writing modes</a>.

<dt><dfn>text-bottom</dfn>

<dd>

Use the [=text-under baselines=].

<dt><dfn>alphabetic</dfn>

<dd>

Use the [=alphabetic baselines=].

<dt><dfn>ideographic</dfn>

<dd>

Use the [=ideographic-under baselines=].

<dt><dfn>middle</dfn>

<dd>

Use the [=x-middle baselines=];

except under ''text-orientation: upright''

(where the [=alphabetic=] and [=x-height=] baselines are essentially meaningless)

use the [=central baseline=].

<dt><dfn>central</dfn>

<dd>

Use the [=central baselines=].

<dt><dfn>mathematical</dfn>

<dd>

Use the [=math baselines=].

<dt><dfn>hanging</dfn>

<dd>

Use the [=hanging baselines=].

<dt><dfn>text-top</dfn>

<dd>

Use the [=text-over baselines=].

</dl>

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

ISSUE: Define behavior for mixed vertical orientations that isn't nonsensical

when specified baseline isn't ''dominant-baseline/central''.

<pre class="propdef shorthand">

<p>This <a>shorthand</a> property specifies

how an inline-level box is aligned within the line

by specifying its [=alignment baseline=] type ('alignment-baseline'),

[=baseline alignment preference=] ('baseline-source'),

and [=post-alignment shift=] ('baseline-shift')

in a single declaration.

If ''baseline-source/first'' or ''baseline-source/last'' is specified,

it sets 'baseline-source'

(which is otherwise reset to ''baseline-source/auto'').

Other values are as for the corresponding longhand properties, see below.

<p class="advisement">

Authors should use this shorthand ('vertical-align') instead of its longhands,

unless specifically needing to cascade its longhands independently

or (on SVG elements) to support legacy SVG implementations.

Note: 'vertical-align' can also affect the alignment of table cells

when 'align-content' is ''align-content/normal''.

Specifically, ''vertical-align/top'' (''baseline-shift: top'') maps it to ''align-content/start'',

''vertical-align/bottom'' (''baseline-shift: bottom'') to ''align-content/end'',

and otherwise ''vertical-align/middle'' (''alignment-baseline: middle'') to ''align-content/center''.

See [[css-align-3#distribution-block]].

<pre class="propdef">

When an inline-level box

has more than one possible source for baseline information

(such as for a multi-line inline block or inline flex container)

this property specifies whether the <a>first baseline set</a> or <a>last baseline set</a>

is preferred for alignment,

indicating the box’s <dfn export>baseline alignment preference</dfn>.

Values have the following meanings:

<dl dfn-for="baseline-source,vertical-align" dfn-type=value>

<dt><dfn>auto</dfn>

<dd>Specifies <a>last-baseline alignment</a> for ''inline-block'',

<a>first-baseline alignment</a> for everything else.

<dt><dfn>first</dfn>

<dd>Specifies <a>first-baseline alignment</a>.

<dt><dfn>last</dfn>

<dd>Specifies <a>last-baseline alignment</a>.

</dl>

See [[css-align-3#baseline-export]]

for how to find the baselines of boxes other than [=inline boxes=].

<pre class="propdef">

This property specifies the box’s <dfn export>alignment baseline</dfn>:

the [=baseline=] used to align the box

prior to applying its [=post-alignment shift=]

(if applicable). Values have the same meanings as for 'dominant-baseline';

the <dfn for=alignment-baseline value>baseline</dfn> keyword uses the

<a>dominant baseline</a> choice of the parent.

When performing [=baseline alignment=],

these values specify which [=baseline=] of the box is aligned

to the corresponding [=baseline=] of its [=alignment context=].

(In an [=inline formatting context=],

[=inline-level=] [=box fragments=] and glyphs

share an [=alignment context=] established by

their parent [=inline box=] [=box fragment|fragment=]

along its [=inline axis=].

For other [=formatting contexts=],

see [[css-align-3#baseline-terms]].)

In SVG text layout,

these values instead specify the [=baseline=] that is aligned

to the SVG <a>current text position</a>.

SVG implementations <em>may</em> support the following aliases

in order to support legacy content:

<ul dfn-for=alignment-baseline dfn-type=value>

* <dfn>text-before-edge</dfn> aliasing ''alignment-baseline/text-top''

* <dfn>text-after-edge</dfn> aliasing ''alignment-baseline/text-bottom''

</ul>

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

<pre class="propdef">

This property specifies the box’s <dfn>post-alignment shift</dfn>.

The <dfn local-lt="baseline-relative values" noexport>baseline-relative shift values</dfn>

<<length-percentage>>, ''baseline-shift/sub'', ''baseline-shift/super''

shift the box relative to its baseline-aligned position,

whereas the <dfn local-lt="line-relative values">line-relative shift values</dfn>

''baseline-shift/top'', ''baseline-shift/center'', and ''baseline-shift/bottom''

shift the [=inline box=] and its contents

relative to the bounds of its [=line box=].

<p class="advisement">

Authors should use the 'vertical-align' shorthand,

which has existed since CSS1,

instead of this 'baseline-shift' longhand

(except in SVG content,

where conversely 'baseline-shift' is more widely-supported in legacy user agents).

Values have the following meanings:

<dl dfn-for="baseline-shift,vertical-align" dfn-type=value>

<dt><dfn><<length>></dfn>

<dd>Raise (positive value) or lower (negative value) by the specified length.

<dt><dfn><<percentage>></dfn>

<dd>Raise (positive value) or lower (negative value) by the specified percentage of the 'line-height'.

<dt><dfn>sub</dfn>

<dd>

Lower by the offset appropriate for subscripts of the parent’s box.

The UA may use the parent’s font metrics to find this offset;

otherwise it defaults to dropping by

one fifth of the parent’s used 'font-size'.

<dt><dfn>super</dfn>

<dd>

Raise by the offset appropriate for superscripts of the parent’s box.

The UA may use the parent’s font metrics to find this offset;

otherwise it defaults to raising by

one third of the parent’s used 'font-size'.

<dt><dfn>top</dfn>

<dd>

Align the [=line-over=] edge of the [=aligned subtree=]

with the [=line-over=] edge of the [=line box=].

<dt><dfn>center</dfn>

<dd>

Align the center of the [=aligned subtree=]

with the center of the [=line box=].

<dt><dfn>bottom</dfn>

<dd>

Align the [=line-under=] edge of the [=aligned subtree=]

with the [=line-under=] edge of the [=line box=].

</dl>

The <dfn>aligned subtree</dfn> of an [=inline box=] contains

the [=layout bounds=] of that box

and the [=aligned subtrees=] of all child [=inline boxes=]

whose computed 'alignment-baseline' value

is not itself a [=line-relative shift value=].

The [=line-over=] edge of the [=aligned subtree=]

is the highest [=over=] edge of the [=layout bounds=] in the subtree,

and the [=line-under=] edge is analogously the lowest.

ISSUE: The [=line-relative shift values=] don't fit perfectly

in the dichotomy between 'alignment-baseline' and 'baseline-shift'.

There's <a href="https://github.com/w3c/csswg-drafts/issues/5180">decent</a> <a href="https://github.com/w3c/csswg-drafts/issues/5234">arguments</a>

for either option.

They're currently drafted here,

but if there's a strong argument to move them,

please file an issue for consideration.

<p>User agents <em>may</em> additionally support

the keyword <dfn value for=baseline-shift>baseline</dfn> as computing to ''0''

if is necessary for them to support legacy SVG content.

This value is not allowed in the 'vertical-align' shorthand.

Issue: We would prefer to remove the ''baseline-shift/baseline'' value, and are looking for feedback from SVG user agents as to whether it's necessary.

The [=block-axis=] sizing of a [=line box=]

depends on the sizes and [[#alignment|alignment]] of its [=inline-level=] contents.

This sizing is controlled by

the 'line-height' and 'line-fit-edge' properties.

<pre class="propdef">

This property specifies the box’s <dfn>preferred line height</dfn>,

which is used in calculating its “[=layout bounds=]”,

i.e. its contribution to the [=logical height=] of its [=line box=].

(See [[#inline-height]].)

Note: Because it applies to the [=root inline box=]

when specified on a [=block container=],

'line-height' effectively establishes

the minimum height of the block’s [=line boxes=].

Values for this property have the following meanings:

<dl dfn-for=line-height dfn-type=value>

<dt><dfn>normal</dfn>

<dd>

Determine the [=preferred line height=]

automatically based on the metrics of the used font.

<dt><dfn><<length [0,∞]>></dfn>

<dd>

The specified length is used as the [=preferred line height=].

Negative values are illegal.

<dt><dfn><<number [0,∞]>></dfn>

<dd>

The [=preferred line height=] is this number

multiplied by the element's used 'font-size'.

Negative values are illegal.

The [=computed value=] is the same as the [=specified value=].

<dt><dfn><<percentage [0,∞]>></dfn>

<dd>

The [=preferred line height=]

and [=computed value=] of the property

is this percentage of the element's computed 'font-size'.

Negative values are illegal.

</dl>

Note: Metrics from fonts other than the [=first available font=]

only impact the [=layout bounds=]

of an [=inline box=] with ''line-height: normal''.