Overview.bs

<style media="print" type="text/css">
	img#edge { width: 80%; height: 70%;}
	dt.label { display: run-in; }
</style>

<pre class='metadata'>
Title: CSS Inline Layout Module Level 3
Shortname: css-inline
Level: 3
Status: ED
Work Status: Revising
Group: csswg
TR: https://www.w3.org/TR/css-inline-3/
ED: https://drafts.csswg.org/css-inline-3/
Previous version: https://www.w3.org/TR/2020/WD-css-inline-3-20200827/
Previous version: https://www.w3.org/TR/2020/WD-css-inline-3-20200618/
!Issues list: <a href="https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Acss-inline-3">CSS3 Line Layout issues in GitHub</a>
Editor: Elika J. Etemad / fantasai, Apple, http://fantasai.inkedblade.net/contact, w3cid 35400
Former Editor: Dave Cramer, Hachette Livre, dauwhe@gmail.com, w3cid 65283
Former Editor: Steve Zilles, Adobe, szilles@adobe.com, w3cid 3129
Abstract: The CSS formatting model provides for a flow of elements and text inside of a container to be wrapped into lines. This module describes box model for this inline layout model and defines the block-axis alignment and sizing of inline-level content, extending the model in [[CSS2]]. It also adds a special layout mode for drop-caps.
Ignored Terms: line-height-shift-adjustment, text-script, after, before, alignment subtree
Link Defaults: css-fonts-3 (property) font-family, css-color-3 (property) color
At Risk: the 'initial-letter-wrap' property
</pre>

<pre class="link-defaults">
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

</pre>

<h2 id="intro">
Introduction</h2>

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

<h3 id="placement">
Module Interactions</h3>

	This module
	replaces and extends the CSS inline layout model and features defined in
	[[!CSS2]] section 10.8.

<h3 id="values">
Value Definitions</h3>

	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.

<h2 id="model">
Inline Layout Model</h2>

	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.

<h3 id="line-boxes">
Layout of Line Boxes</h3>

	[=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"
		     alt="diagram showing inline boxes split across line boxes as described above">
		<figcaption>Inline Layout Box Model</figcaption>
	</figure>

<h3 id="line-layout">
Layout Within Line Boxes</h3>

	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.

<h3 id="invisible-line-boxes">
Phantom Line Boxes</h3>

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

<h3 id="paint-order">
Painting Order</h3>

	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.

<h2 id="css-metrics">
Baselines and Alignment Metrics</h2>

<h3 id="baseline-intro">
Introduction to Baselines</h3>

	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"
		     width="480"
		     src="images/alphabetic-baseline-in-two-font-sizes.svg"></p>
		<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,
		          on top of which most letters rest,
		          though some letters have descenders that dangle below it.
		          Indic scripts are sometimes typeset with a hanging baseline,
		          since their glyph shapes appear to be hanging from a horizontal line.
		          Han-based systems, whose glyphs are designed to fill a square,
		          tend to align on their bottoms or through their centers."
		     src="images/script-preferred-baselines.gif"></p>
		<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=""
		        src="images/baselines.gif"></p>
		<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=].

<h3 id="baseline-types">
Baselines and Metrics</h3>

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

<h4 id="ascent-descent">
Ascent and Descent Metrics</h4>

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

<h4 id="font-line-gap">
Line Gap Metrics</h4>

	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.

<h3 id="baseline-tables">
Baselines of Glyphs and Boxes</h3>

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

<h2 id="alignment">
Baseline Alignment</h2>

	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
			          is compacted 75% in the span with a 75% font size.
			          Their alphabetic baselines, however, line up."
			     src="images/baseline-align-sizes.gif">
		</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
			             shifting the parent baseline table upwards by its superscript offset,
			             and then aligning the child's alphabetic baseline
			             to the shifted position of the parent's alphabetic baseline."
			        src="images/baseline-align-super.gif">
		</figure>
	</div>

<h3 id="dominant-baseline-property">
Dominant Baselines: the 'dominant-baseline' property</h3>

	<pre class="propdef">
	Name: dominant-baseline
	Value: auto | text-bottom | alphabetic | ideographic | middle | central | mathematical | hanging | text-top
	Initial: auto
	Applies to: block containers, inline boxes, table rows, grid containers, flex containers, and SVG <a>text content elements</a>
	Inherited: yes
	Percentages: N/A
	Computed value: specified keyword
	Animation type: discrete
	</pre>

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

	Values have the following meanings:

	<dl dfn-for=dominant-baseline 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''.

<h3 id="transverse-alignment">
Transverse Box Alignment: the 'vertical-align' property</h3>

	<pre class="propdef shorthand">
	Name: vertical-align
	Value: [ first | last] || <<'alignment-baseline'>> || <<'baseline-shift'>>
	Initial: baseline
	Applies to: see individual properties
	Inherited: no
	Percentages: N/A
	Animation type: see individual properties
	</pre>

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

<h4 id="baseline-source">
Alignment Baseline Source: the 'baseline-source' longhand</h4>

	<pre class="propdef">
	Name: baseline-source
	Value: auto | first | last
	Initial: auto
	Applies to: inline-level boxes
	Inherited: no
	Percentages: N/A
	Computed value: specified keyword
	Animation type: discrete
	</pre>

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

<h4 id="alignment-baseline-property">
Alignment Baseline Type: the 'alignment-baseline' longhand</h4>

	<pre class="propdef">
	Name: alignment-baseline
	Value: baseline | text-bottom | alphabetic | ideographic | middle | central | mathematical | text-top
	Initial: baseline
	Applies to: inline-level boxes, flex items, grid items, table cells, and SVG <a>text content elements</a>
	Inherited: no
	Percentages: N/A
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	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 are defined as follows:

	<dl dfn-for="alignment-baseline,vertical-align" dfn-type=value>
		<dt><dfn>baseline</dfn>
		<dd>
			Use the <a>dominant baseline</a> choice of the parent.

		<dt><dfn>text-bottom</dfn>
		<dd>
			Use the [=text-under baseline=].

		<dt><dfn>alphabetic</dfn>
		<dd>
			Use the [=alphabetic baseline=].

		<dt><dfn>ideographic</dfn>
		<dd>
			Use the [=ideographic-under baseline=].

		<dt><dfn>middle</dfn>
		<dd>
			In general, use the [=x-middle baselines=];
			except under ''text-orientation: upright''
			(where the [=alphabetic=] and [=x-height=] baselines are essentially meaningless)
			use the [=central baseline=] instead.

		<dt><dfn>central</dfn>
		<dd>
			Use the [=central baseline=].

		<dt><dfn>mathematical</dfn>
		<dd>
			Use the [=math baseline=].

		<dt><dfn>text-top</dfn>
		<dd>
			Use the [=text-over baseline=].
	</dl>

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

<h5 class="no-toc" id="alignment-baseline-svg-legacy">
Legacy Values for SVG</h5>

	SVG implementations <em>may</em> support the following aliases
	in order to support legacy content:
	<pre dfn-for=alignment-baseline dfn-type=value>
		<dfn>text-before-edge</dfn> = ''alignment-baseline/text-top''
		<dfn>text-after-edge</dfn> = ''alignment-baseline/text-bottom''
	</pre>
	These values are not allowed in the 'vertical-align' shorthand.

<h4 id="baseline-shift-property">
Post-Alignment Shift: the 'baseline-shift' longhand</h4>

	<pre class="propdef">
	Name: baseline-shift
	Value: <<length-percentage>> | sub | super | top | center | bottom
	Initial: 0
	Applies to: inline-level boxes and SVG <a>text content elements</a>
	Inherited: no
	Percentages: refer to the used value of 'line-height'
	Computed value: the specified keyword or a computed <<length-percentage>> value
	Animation type: by computed value type
	</pre>

	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.

<h5 class="no-toc" id="baseline-shift-svg-legacy">
Legacy Values for SVG</h5>

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

<h2 id="line-height">
Logical Heights and Inter-line Spacing</h2>

	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.

<h3 id="line-height-property">
Line Spacing: the 'line-height' property</h3>

	<pre class="propdef">
	Name: line-height
	Value: normal | <<number [0,∞]>> | <<length-percentage [0,∞]>>
	Initial: normal
	Applies to: non-replaced inline boxes and SVG <a>text content elements</a>
	Inherited: yes
	Percentages: computed relative to ''1em''
	Computed value: the specified keyword, a number, or a computed <<length>> value
	Animation type: by computed value type
	</pre>

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

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

	<div class="example">
		The three rules in the example below have the same used line height:

		<pre><code highlight=css>
			div { line-height: 1.2; font-size: 10pt }     /* number */
			div { line-height: 1.2em; font-size: 10pt }   /* length */
			div { line-height: 120%; font-size: 10pt }    /* percentage */
		</code></pre>

		However, they inherit differently:
		the first one inherits as a number,
		which will lead to different line heights if descendants have different font sizes;
		the last two as inherit as absolute lengths,
		which will not be influenced by the font size on descendants.
	</div>

	ISSUE: The fact that percentages compute to lengths is annoying.
	See also <a href="https://github.com/w3c/csswg-drafts/issues/3118">Issue 3118</a>
	and <a href="https://github.com/w3c/csswg-drafts/issues/2165">Issue 2165</a>.

	Note: When 'line-fit-edge' is ''line-fit-edge/leading'',
	the margins, borders, and padding of [=inline boxes=]
	do not affect the line box’s height calculation.
	However, they are still rendered around these boxes.
	This means that if the size specified by 'line-height'
	is less than the size of the box,
	backgrounds and borders can “bleed” into adjoining line boxes,
	potentially obscuring earlier content.

<h3 id="text-edges">
Text Edge Metrics: the 'line-fit-edge' property</h3>

	<pre class="propdef">
	Name: line-fit-edge
	Value: leading | <<text-edge>>
	Initial: leading
	Applies to: [=inline boxes=]
	Inherited: yes
	Percentages: N/A
	Computed value: the specified keyword
	Animation type: discrete
	</pre>

	ISSUE: This is an early draft of a proposal,
	and might change significantly
	as design critiques and use cases are registered
	and various details and interactions with other properties are worked out.
	<strong>Do not ship (yet).</strong>

	[=Inline boxes=], whose primary purpose is to contain text,
	are sized in the [=block axis=] based on their font metrics.
	The 'line-fit-edge' property controls which metrics are used.
	These chosen metrics are used as the basis
	for the [=layout bounds=] of the [=inline box=]
	(if it is not the [=root inline box=]);
	and also, by default, are the metrics used for 'text-box-trim'.

	The <dfn><<text-edge>></dfn> value,
	which identifies specific font metrics,
	expands to

	<pre class=prod>
		<<text-edge>> = [ text | cap | ex | ideographic | ideographic-ink ]
		              [ text | alphabetic | ideographic | ideographic-ink ]?
	</pre>

	The first value specifies the text [=over=] edge;
	the second value specifies the text [=under=] edge.
	If only one value is specified,
	both edges are assigned that same keyword if possible;
	else ''<<text-edge>>/text'' is assumed as the missing value.

	ISSUE(5236): Do we need [=longhands=] or is this shorthand enough?

	Values have the following meanings:

	<dl dfn-for="line-fit-edge,<<text-edge>>" dfn-type=value>
		<dt><dfn>leading</dfn>
		<dd>
			Use the [=ascent=]/[=descent=] plus any positive [=half-leading=].
			Margin/padding/border is ignored
			for the purpose of sizing the [=line box=].

		<dt><dfn>text</dfn>
		<dd>
			Use the [=text-over baseline=]/[=text-under baseline=]
			as the [=over=]/[=under=] edge.

		<dt><dfn>cap</dfn>
		<dd>
			Use the [=cap-height baseline=] as the [=over=] edge.

		<dt><dfn>ex</dfn>
		<dd>
			Use the [=x-height baseline=] as the [=over=] edge.

		<dt><dfn>ideographic</dfn>
		<dd>
			Use the [=ideographic-over baseline=]/[=ideographic-under baseline=]
			as the [=over=]/[=under=] edge.

		<dt><dfn>ideographic-ink</dfn>
		<dd>
			Use the [=ideographic-ink-over baseline=]/[=ideographic-ink-under baseline=]
			as the [=over=]/[=under=] edge.

		<dt><dfn>alphabetic</dfn>
		<dd>
			Use the [=alphabetic baseline=] as the [=under=] edge.
	</dl>

	ISSUE(8067): Is ''line-fit-edge/text'' a reasonable name for the ascent/descent metrics,
	or can we think of something better?
	Ditto ''line-fit-edge/leading'' as a keyword.

	Unless 'line-fit-edge' is ''line-fit-edge/leading''--
	in which case the box’s own 'line-height' is used to add spacing--
	the box’s margin, padding, and border also contribute
	to the [=layout bounds=].

	Note: The ''line-fit-edge/leading'' and ''line-fit-edge/text'' values
	rely on the font [=ascent=] and [=descent=] to make sure the text fits.
	Other values are more likely to result in overlap or overflow
	caused by ascents above the specified metrics
	(such as for diacritics),
	so authors using these values need to be careful
	to provide sufficient spacing for the text,
	particularly in multi-lingual contexts.

	<figure>
		<img src="images/text-edge.png" width="480"
		     alt="Three different values of the line-fit-edge property."  >
		<figcaption>
			The 'line-fit-edge' property, showing values for ''line-fit-edge/leading'',
			''line-fit-edge/cap'', and ''line-fit-edge/ex''.
			The red lines indicate the layout bounds of the inline box.
		</figcaption>
	</figure>

	<div class="note">
	<p>When 'line-fit-edge' is ''line-fit-edge/leading'',
	vertical rhythm can be broken any time there is a change
	in font metrics or vertical alignment within a paragraph.

	<p>Other values are more likely to give consistent line spacing--
	as long as there is enough leading added
	that the half-leading on the root inline
	is large enough to accommodate the specified metrics of any descendants.
	The line box will still grow, however, to accommodate
	content that would otherwise overflow,
	to avoid overlap between lines.
	</div>

	Note: Although only ''line-fit-edge/leading'' applies positive [=half-leading=],
	in order to allow text to be set tightly,
	all values apply negative [=half-leading=],
	see [[#inline-height]].
	Half-leading is applied equally to both sides of the text;
	for more precise overlap control authors can use
	''line-fit-edge: text'' together with negative [=margins=]
	on the affected text.

<h3 id="inline-height">
Calculating the Logical Height Contributions (“Layout Bounds”) of Inline Boxes</h3>

	The contribution of an [=inline box=] to the [=logical height=] of its [=line box=],
	here referred to as its <dfn>layout bounds</dfn>,
	is always calculated with respect to its own text metrics,
	as described below,
	and is controlled by 'line-fit-edge' and 'line-height'.
	The sizes and positions of child boxes do not influence
	its [=layout bounds=]
	(nor its own [=logical height=], for that matter,
	see 'inline-sizing').

	Note: The [=layout bounds=] need not correspond
	to the box’s [=box/edges=].

	To find the [=layout bounds=] of an [=inline box=],
	the UA must first align
	all the glyphs <em>directly</em> contained in the [=inline box=]
	to each other by their [=dominant baselines=].
	(See [[#baseline-tables]].)
	If the [=inline box=] contains no glyphs at all,
	or if it contains only glyphs from fallback fonts,
	it is considered to contain a “strut” (an invisible glyph of zero width)
	with the metrics of the box's [=first available font=].

	For each glyph (including the “strut”),
	<var>A</var> represents its ascent above the [=baseline=];
	<var>D</var> represents its descent below.
	Unless 'line-fit-edge' specifies a different metric to use,
	<var>A</var> refers to the [=ascent metric=]
	(for the given font at its given size)
	and <var>D</var> to the [=descent metric=],
	each adjusted to account for the [=dominant baseline=]’s offset from zero.
	If 'line-height' computes to ''line-height/normal''
	and either 'line-fit-edge' is ''line-fit-edge/leading''
	or this is the [=root inline box=],
	the font’s [=line gap metric=]
	may also be incorporated into <var>A</var> and <var>D</var>
	by adding half to each side as [=half-leading=].

	<strong>When its computed 'line-height' is ''line-height/normal''</strong>,
	the [=layout bounds=] of an inline box encloses all its glyphs,
	going from the highest <var>A</var> to the deepest <var>D</var>.
	(Note that glyphs in a single box
	can come from different fonts
	and thus might not all have the same <var>A</var> and <var>D</var>.)

	<strong>When its computed 'line-height' is not ''line-height/normal''</strong>,
	its [=layout bounds=] are derived solely from
	metrics of its [=first available font=]
	(ignoring glyphs from other fonts),
	and <dfn>leading</dfn> is used
	to adjust the effective <var>A</var> and <var>D</var>
	to add up to the used 'line-height'.
	Calculate the [=leading=] <var>L</var>
	as <var>L</var> = 'line-height' - (<var>A</var> + <var>D</var>).
	Half the [=leading=] (its <dfn>half-leading</dfn>)
	is added above <var>A</var> of the first available font,
	and the other half below <var>D</var> of the first available font,
	giving an effective ascent above the baseline of
	<var>A′</var> = <var>A</var> + <var>L</var>/2,
	and an effective descent of <var>D′</var> = <var>D</var> + <var>L</var>/2.
	However, if 'line-fit-edge' is not ''line-fit-edge/leading''
	and this is not the [=root inline box=],
	if the [=half-leading=] is positive, treat it as zero.
	The [=layout bounds=] exactly encloses
	this effective <var>A′</var> and <var>D′</var>.

	Note: <var>L</var> may be negative.

	Additionally,
	when 'line-fit-edge' is not ''line-fit-edge/leading'',
	the [=layout bounds=] are inflated
	by the sum of the [=margin=], [=border=], and [=padding=]
	on each side.
	In order to allow negative [=margin=] values to have an actual effect,
	negative [=margins=] are also accumulated onto
	the [=layout bounds=] of any descendant [=inline boxes=]
	participating in the same [=inline formatting context=].

	In Quirks Mode [[!QUIRKS]],
	any [=inline box=] [=box fragment|fragment=]
	that has zero borders and padding and
	that does not directly contain text or <a>preserved white space</a> [[!CSS-TEXT-3]]
	is ignored when sizing the [=line box=].

<h2 id="leading-trim">
Trimming Leading Over/Under Text</h2>

	ISSUE: This is a draft of a proposal,
	and may change significantly
	as design critiques and use cases are registered.
	Values and property names may be added, dropped, and/or renamed,
	and the overall syntax or behavior may change,
	particularly in response to authoring and robustness considerations
	for handling descendant boxes.
	<strong>Do not ship (yet).</strong>

	To ensure consistent spacing in the basic case of running text,
	CSS line layout introduces leading both above and below
	the text content of each line
	as needed to ensure its 'line-height'.
	In addition, the ascent and descent font metrics themselves
	often include extra space above and below the most typical glyph shapes
	in order to accommodate occasional characters and diacritics
	that ascend or descend beyond the typical bounds.
	This prevents adjacent lines of text from overlapping each other.
	However, all this extra spacing interferes with visual alignment
	and with control over effective (visually-apparent) spacing.

	The 'text-box' property allows trimming
	this additional space above and below
	the first and last lines of a block,
	allowing more precise control over spacing around the glyphs.
	By relying on font metrics rather than hard-coded lengths,
	this feature allows content to be resized, rewrapped, and rendered in a variety of fonts
	while maintaining that precise spacing.

	<div class="example">
		<!-- Example from Weston Thayer in https://github.com/w3c/csswg-drafts/issues/3240#issuecomment-432375650 -->

		A common problem is vertical centering.
		It's easy to vertically center the text container to an icon,
		but because the visual boundaries of Latin text
		are the cap height and the alphabetic baseline,
		rather than the ascent and descent,
		this often doesn't yield the intended visual effect.

		<figure>
			<img src="images/leading-trim-centering-fail.png"
			     alt="Consider some Latin text placed to the right of an image,
			          to be centered between its top and bottom.
			          Measuring from the top of the image to the top of the text box yields 13px;
			          likewise measuring from the bottom of the image to the bottom of the text box yields 13px,
			          theoretically perfectly centering the text.
			          However, measuring from the top of the image to the cap-height yields 21px;
			          and measuring from the bottom to the alphabetic baseline yields 19px,
			          showing that visually the text is not actually centered.">
			<figcaption>
				Measuring to the top/bottom of the text may yield equal results,
				but measuring to the visual bounds shows that it is not visually centered.
			</figcaption>
		</figure>

		To center the text visually,
		it's necessary to assume the cap height and alphabetic baseline
		as the top and bottom edges of the text,
		respectively.

		<figure>
			<img src="images/leading-trim-centering-goal.png"
			     alt="If the text were visually centered,
			          the distance between the top of the image and the cap height would be 20px,
			          and the distance between the bottom of the image and the alphabetic baseline would be equally 20px."
			     style="width: 50%">
			<figcaption>
				Measuring to the cap height / alphabetic baseline
				instead of the ascent / descent
				and equalizing those distances
				visually centers the text.
		</figure>

		By using 'text-box-trim' to strip out the spacing above the cap height
		and below the alphabetic baseline,
		centering the box actually centers the text;
		and does so reliably, regardless of what font is used to render it.

		<figure>
			<img src="images/leading-trim-centering-variants.gif"
			     alt="">
			<figcaption>
				Even though different fonts have different cap heights,
				by using the font's metric rather than a magic number,
				the layout intention is met even as the font is changed.
			</figcaption>
		</figure>
	</div>

<h3 id="text-box-shorthand">
Shorthand for Text Box Trimming: the 'text-box' property</h3>

	<pre class="propdef">
	Name: text-box
	Value: normal | <<'text-box-trim'>> || <<'text-box-edge'>>
	Initial: normal
	Applies to: [=block containers=] and [=inline boxes=]
	Inherited: no
	Percentages: N/A
	Computed value: the specified keyword
	Animation type: discrete
	</pre>

	This property is a [=shorthand=] for setting the 'text-box-trim' and 'text-box-edge' properties
	in a single declaration.

	If the single keyword <dfn for=text-box value>normal</dfn> is specified,
	it sets 'text-box-trim' to ''text-box-trim/none''
	and 'text-box-edge' to ''text-box-edge/auto''.
	Otherwise, omitting the 'text-box-trim' value sets it to ''text-box-trim/both'' (not the initial value),
	while omitting the 'text-box-edge' value sets it to ''text-box-edge/auto'' (the initial value).

	ISSUE: Add examples.

<h3 id="text-box-trim">
Trimming Over/Under Text: the 'text-box-trim' property</h3>

	<pre class="propdef">
	Name: text-box-trim
	Value: none | trim-start | trim-end | trim-both
	Initial: none
	Applies to: block containers and [=inline boxes=]
	Inherited: no
	Percentages: N/A
	Computed value: the specified keyword
	Animation type: discrete
	</pre>

	On [=inline boxes=],
	specifies whether to trim the [=content box=]
	to match the specified 'text-box-edge' metric.

	On [=block containers=],
	as well as on each column of a [=multi-column container=],
	specifies whether to trim [=half-leading=]
	at the start/end of its content
	to the specified 'text-box-edge' metric
	to better match the box’s [=content edge=] to its text content.

	Values have the following meanings:

	<dl dfn-for=text-box-trim dfn-type=value>
		<dt><dfn>none</dfn>
		<dd>
			No special handling of the first/last [=line box=]
			when applied to a [=block container=].

			When applied to an [=inline box=],
			specifies that the over/under [=content edges=] coincide
			with the [=text-over=]/[=text-under=] baselines
			regardless of 'text-box-edge'.

		<dt><dfn>trim-start</dfn>
		<dd>
			For [=block containers=] and [=column boxes=]:
			trim the [=block-start=] side of the <a>first formatted line</a>
			to the specified metric of its [=root inline box=].
			If there is no such line,
			or if there is intervening non-zero padding or borders,
			there is no effect.

			For [=inline boxes=]:
			trims the [=block-start=] side of the box
			to match its [=content edge=] to the metric specified by 'text-box-edge'.

		<dt><dfn>trim-end</dfn>
		<dd>
			For [=block containers=] and [=column boxes=]:
			trim the [=block-end=] side of the last formatted line
			to the specified metric of its [=root inline box=].
			If there is no such line,
			or if there is intervening non-zero padding or borders,
			there is no effect.

			For [=inline boxes=]:
			trims the [=block-end=] side of the box
			to match its [=content edge=] to the metric specified by 'text-box-edge'.

		<dt><dfn>trim-both</dfn>
		<dd>
			Specifies the behavior of ''text-box-trim/trim-start'' and ''text-box-trim/trim-end''
			simultaneously.
	</dl>

	Note: The [=block-end=] side does not coincide with the [=line-under=] side
	when 'writing-mode' is ''vertical-lr''.

	If multiple ancestors specify trimming on the same [=line box=],
	the metric used is that of the innermost [=block container=]
	that requests trimming on that side of the [=line box=].

	Note: Content and ink overflowing a box
	due to non-initial values of 'text-box-trim'
	is handled the same as content that would overflow the box or line box otherwise.

<h3 id="text-box-edge">
Text Trimming Metrics: the 'text-box-edge' property</h3>

	<pre class="propdef">
	Name: text-box-edge
	Value: auto | <<text-edge>>
	Initial: auto
	Applies to: [=block containers=] and [=inline boxes=]
	Inherited: no
	Percentages: N/A
	Computed value: the specified keyword
	Animation type: discrete
	</pre>

	This property specifies the metrics to use for 'text-box-trim' effects.
	Values have the same meanings as for 'line-fit-edge';
	the <dfn for=text-box-edge value>auto</dfn> keyword
	uses the value of 'line-fit-edge' on the [=root inline box=] of the the affected [=line box=],
	interpreting ''line-fit-edge/leading'' (the [=initial value=]) as ''line-fit-edge/text''.

	Note: This property can be set together with 'text-box-trim'
	in the 'text-box' [=shorthand=].
	Unlike 'line-fit-edge', it does not inherit;
	however its [=initial value=] copies from 'line-fit-edge',
	which does inherit.

<h3 id="line-fill">
Inline Box Drawing Height: the 'inline-sizing' property</h3>

	<pre class="propdef">
	Name: inline-sizing
	Value: normal | stretch
	Initial: normal
	Applies to: <a>inline boxes</a>, but not [=ruby container boxes=] nor [=internal ruby boxes=]
	Inherited: yes
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	ISSUE(5189): This has a confusing name. We need a new name.
	Alternatively, incorporate this into 'text-box-trim'?

	This property specifies how the <a>logical height</a>
	of the <a>content area</a> of an <a>inline box</a>
	is measured in relation to its contents.
	It has no effect on the size or position of the box’s contents,
	the line box, or any other content.

	Values have the following meanings:

	<dl dfn-for="inline-sizing" dfn-type=value>
		<dt><dfn>normal</dfn>
		<dd>
			The <a>content area</a> of the <a>inline box</a>
			is sized and positioned to fit (possibly hypothetical) text
			from its [=first available font=].
			This specification does not specify how.
			A UA may, e.g., use the maximum ascender and descender of the font.
			(This would ensure that glyphs with parts above or below the em-box
			still fall within the content area,
			but leads to differently sized boxes for different fonts.)

			Note: If more than one font is used
			(which happen when glyphs are found in different fonts),
			the [=logical height=] of the [=content area=] is not affected
			by the glyphs from the fallback fonts,
			and only depends on the [=first available font=].
			However, these fallback glyphs can still affect the [=line box=] size
			when 'line-height' is ''line-height/normal'';
			see [[#inline-height]].

		<dt><dfn>stretch</dfn>
		<dd>
			Once the [=line box=] has been sized and its contents positioned
			as for ''inline-sizing/normal'',
			the [=inline box=]’s [=box edges=] are shifted
			such that its [=over=]/[=under=] [=margin edges=] coincide
			with the corresponding [=line box=]’s edges,
			stretching the [=inline box=]’s [=inner size|inner=] [=logical height=]
			so that its [=block-axis=] [=outer size=] fills the [=line box=].
			(The sizes and positions of its [=in-flow=] contents are not affected.)
	</dl>

	Note: The 'height' property does not apply to [=inline boxes=].

	Note: The 'line-height' has no impact on the size of an [=inline box=],
	it only [[#inline-height|affects its contribution]]
	to the [=logical height=] of its [=line box=].

<h2 id="initial-letter-styling">
<!--<a name="Initial"></a>-->
Initial Letters</h2>

	<p class="issue">The editors would appreciate any examples of drop initials in non-western scripts, especially Indic scripts.</p>

<h3 id="initial-letter-intro">
<!--<a name="DropInitial"></a>-->
An Introduction to Initial Letters</h3>

	<em>This section is non-normative.</em>

	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.

<h4 id="drop-initial">
Drop Initial</h4>

	A <dfn>dropped initial</dfn> (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.

	<figure>
		<img src="images/Dropcap-E-acute-3line.png" width="480"
		     alt="3-line drop cap with E Acute"  >
		<figcaption>
			Three-line drop initial with E acute.
			Since the cap-height of the drop initial aligns with the cap-height of the main text,
			the accent extends above the paragraph.
		</figcaption>
	</figure>

	The exact size and position of a <a>dropped initial</a>
	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.
	The figure below shows a simple two-line drop cap, with the relevant reference lines marked.

	<figure>
		<img src="images/Dropcap-lines.png" width="600"
		     alt="drop cap showing alignment">
		<figcaption>Two-line drop cap showing baselines (green lines), cap-height (red line), and ascender (cyan line).</figcaption>
	</figure>

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

	<figure>
		<img src="images/Initial-2line-JapaneseVertical.png" width="480"
		     alt="Japanese Vertical Initial">
		<figcaption>Two-line drop initial in vertical writing mode</figcaption>
	</figure>

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

	<figure>
		<img src="images/Devangari-Initial.png" width="480"
		     alt="Devanagari initial letter">
		<figcaption>Devanagari <a>initial letter</a> aligned with hanging baseline. Alignment points shown in red.</figcaption>
	</figure>


<h4 id="sunk-initial">
Sunken Initial Letters</h4>

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

	<figure>
		<img src="images/SunkenCapA.png" width="480"
		     alt="sunken drop initial">
		<figcaption>Sunken cap. The letter drops two lines, but is the size of a three-line initial letter.</figcaption>
	</figure>

<h4 id="raise-initial">
Raised Initial Letters</h4>

	A <dfn>raised initial</dfn> (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.

	<figure>
		<img src="images/RaisedCap.png" width="480"
		     alt="raised cap">
		<figcaption>Raised cap. The initial letter is the size of a 3-line initial, but does not drop.</figcaption>
	</figure>

<h3 id="selecting-drop-initials">
Selecting Initial Letters</h3>

	<em>This section is non-normative.</em>

	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,
	defined in [[SELECT]] and [[CSS-PSEUDO-4]],
	can be used to select the character(s) to be formatted as <a>initial letters</a>.

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

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

	<pre>
		::first-letter, /* style first paragraph's T */
		img, /* style illuminated H */
		span /* style phrase inside span */
		{ initial-letter: 2; }
	</pre>
	</div>

	Note that
	since ''::first-letter'' selects punctuation before or after the first letter,
	these characters are included in the [=initial letter=] when ''::first-letter'' is used.

	<figure>
		<img src="images/initial-letter-punctuation-quote.png" width="604"
		     alt="Paragraph showing both opening quote and first letter set as three-line drop cap">
		<figcaption>The ''::first-letter'' pseudo-element selects the quotation mark as well as the “M”.</figcaption>
	</figure>

	Issue: Should there be a way to opt out of this behavior? See <a href="https://github.com/w3c/csswg-drafts/issues/310">GitHub Issue 310</a>.

<h3 id="sizing-drop-initials">
Creating Initial Letters: the 'initial-letter' property</h3>

	<pre class="propdef">
	Name: initial-letter
	Value: normal | <<number [1,∞]>> <<integer [1,∞]>> | <<number [1,∞]>> && [ drop | raise ]?
	Initial: normal
	Applies to: certain inline-level boxes and <css>::first-letter</css> and inside <css>::marker</css> boxes (<a href="#first-most-inline-level">see prose</a>)
	Inherited: no
	Percentages: N/A
	Computed value: the keyword ''initial-letter/normal'' or a number paired with an integer
	Animation type: by computed value type
	</pre>

	This property specifies
	the <a lt="initial letter size">size</a> and <a lt="initial letter sink">sink</a>
	for dropped, raised, and sunken initial letters
	as the number of lines spanned.

	<div class="example">
		For example, the following code will create
		a 2-line dropped initial letter
		at the beginning of each paragraph
		that immediately follows a second-level heading:
		<pre>h2 + p::first-letter { initial-letter: 2; }</pre>
	</div>

	It takes the following values:

	<dl dfn-for=initial-letter dfn-type=value>
		<dt><dfn>normal</dfn>
		<dd>
			No special initial letter effect. Text behaves as normal.

		<dt><dfn><<number [1,∞]>></dfn>
		<dd>
			This first argument defines the <dfn dfn lt="initial letter size">size</dfn>
			of the initial letter
			in terms of how many lines it occupies.
			Values less than one are invalid.

		<dt><dfn><<integer [1,∞]>></dfn>
		<dd>
			This optional second argument
			defines the number of lines the initial letter should
			<dfn dfn lt="initial letter sink" local-lt="sink">sink</dfn>.
			A value of ''1'' indicates a <a>raised initial</a>;
			values greater than ''1'' indicate a <a>sunken initial</a>.
			Values less than one are invalid.

		<dt><dfn>raise</dfn>
		<dd>
			Computes to an <a>initial letter sink</a> of ''1''.

		<dt><dfn>drop</dfn>
		<dd>
			Computes to an <a>initial letter sink</a>
			equal to the <a>initial letter size</a>
			floored to the nearest positive whole number.
	</dl>

	If the <a>initial letter sink</a> value is omitted,
	''drop'' is assumed.

	Values other than ''initial-letter/normal''
	cause the affected box to become an
	<dfn lt="initial letter | initial letter box">initial letter box</dfn>,
	which is an <a>in-flow</a> <a>inline-level box</a>
	with special layout behavior.

	<div class="example">
		Here are some examples of 'initial-letter' usage:

		<dl>
			<dt>''initial-letter: 3''
			<dt>''initial-letter: 3 3''
			<dt>''initial-letter: 3 drop''
			<dt>''initial-letter: drop 3''
			<dd>
				Represents a <a>dropped initial</a> 3 lines high, 3 lines deep.

				<img src="images/InitialLetter33.png" width="360"
				     alt="3 lines high, 3 lines deep">

			<dt>''initial-letter: 3 2''
			<dd>
				Represents a <a>sunken initial</a> 3 lines high, 2 lines deep.

				<img src="images/InitialLetter32.png" width="360"
					alt="3 lines high, 2 lines deep">

			<dt>''initial-letter: 3 1''
			<dt>''initial-letter: 3 raise''
			<dt>''initial-letter: raise 3''
			<dd>
				Represents a <a>raised initial</a> 3 lines high, 1 line deep.

				<img src="images/InitialLetter31.png" width="360"
				     alt="3 lines high, 1 line deep">

			<dt>''initial-letter: 2.51 3''
			<dd>
				The size of the initial letter does not have to be an integral number of lines.
				In this case only the top aligns.

				<img src="images/non-integer-initial.png" width="360"
				     alt="Non-integral initial letter that only aligns at base">
		</dl>
	</div>

	<div class="example">
		In conjunction with other CSS properties, ''initial-letter'' can be used to create
		“adjacent initial letters,” where the initial letter is adjacent to the text:

		<pre>
			p::first-letter {
				initial-letter: 3;
				color: red;
				width: 5em;
				text-align: right;
				margin-left: -5em;
			}

			p {
				margin-left: 5em;
			}
		</pre>

		<figure>
			<img src="images/adjacent-initial-letter.png"
			     alt="Initial letter adjacent to text" width="360">
		</figure>

	</div>

<h4 id="first-most-inline-level">
Applicability</h4>

	To give authors more control over which characters can be styled as an <a>initial letter</a>
	and to allow the possibility of multi-character <a>initial letters</a>
	(such as for first word or first phrase styling),
	the 'initial-letter' property applies not just
	to the CSS-defined ''::first-letter'' pseudo-element,
	but also to
	''list-style-position/inside''-positioned ''::marker'' pseudo-elements and
	to [=inline-level boxes=]
	that are placed at the start of the first line.
	Specifically, 'initial-letter' applies to
	any <a>inline-level box</a>--
	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 <a>containing block</a>
	are all first-child <a>inline boxes</a>
	that have a <a lt="computed value">computed</a> 'initial-letter' value
	of ''initial-letter/normal''.

	<div class="example">
		For example,
		the <code>&lt;span></code>, <code>&lt;em></code>, and <code>&lt;b></code> elements
		in the following example are
		"first-most inline-level descendants" of the <code>&lt;p></code>,
		but the <code>&lt;strong></code> element
		is not:

		<xmp>
			<p><span><em><b>This</b> phrase</em> is styled
			<strong>specially</strong>.</span> …
		</xmp>

		If we apply the following rules:

		<pre>
			em { initial-letter: 2; }
			b, strong { initial-letter: 3; }
		</pre>

		The 'initial-letter' property will take effect only on the <code>&lt;em></code>.
		The styling on <code>&lt;b></code>
		is ignored,
		as it has an ancestor already styled as an <a>initial letter</a>;
		and the styling on <code>&lt;strong></code> is ignored
		because it is a second sibling.

		The result might be rendered as

		<figure>
			<img src="images/firstmost-inline.png"
			     alt="“This phrase” becomes the dropped text spanning two lines, the remainder of the text wrapping alongside.">
		</figure>
	</div>

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

	The effect of the 'initial-letter' property is undefined
	on children of [=ruby base container boxes=]
	and on [=ruby container boxes=].

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

<h3 id="aligning-initial-letter">
Alignment of Initial Letters: the 'initial-letter-align' property</h3>

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

	<pre class="propdef" id="initial-letter-align">
	Name: initial-letter-align
	Value: [ border-box? [ alphabetic | ideographic | hanging | leading ]? ]!
	Initial: alphabetic
	Applies to: certain inline-level boxes and <css>::first-letter</css> and inside <css>::marker</css> boxes (<a href="#first-most-inline-level">see prose</a>)
	Inherited: yes
	Percentages: N/A
	Computed value: specified keyword(s)
	Animation type: discrete
	</pre>

	This property specifies the alignment points
	used to size and position an <a>initial letter</a>.
	Two sets of alignment points are necessary:
	the <a>over</a> and <a>under</a> alignment points of the <a>initial letter</a>
	are matched to corresponding <a>over</a> and <a>under</a> points
	of the [=root inline box=].

	Values have the following meanings:

	<dl dfn-type="value" dfn-for="initial-letter-align">
		<dt><dfn>alphabetic</dfn>
		<dd>
			Use the [=cap-height=] and [=alphabetic=] baselines
			of the surrounding text
			to align the <a>initial letter</a>.

		<dt><dfn>ideographic</dfn>
		<dd>
			Use the [=ideographic-ink-over=] and [=ideographic-ink-under=] baselines
			of the surrounding text
			to align the <a>initial letter</a>.

		<dt><dfn>hanging</dfn>
		<dd>
			Use the [=hanging=] and [=alphabetic=] baselines
			of the surrounding text
			to align the <a>initial letter</a>.

		<dt><dfn>leading</dfn>
		<dd>
			Use the over/under half-leading edges
			(i.e. [=ascent=]/[=descent=] + [=half-leading=])
			of the surrounding text
			to align the <a>initial letter</a>.

			Note: This will essentially match the edges of the [=initial letter=]
			to middle of the line gap above/below the first/last impacted lines,
			which is an effect sometimes used in certain types of
			<a href="https://www.w3.org/TR/ilreq/#h_scripts_without_hanging_baseline">Indic typesetting</a> [[ILREQ]].

		<dt><dfn>border-box</dfn>
		<dd>
			Use the [=initial letter box=]’s [=line-under=] and [=line-over=] [=border edges=]
			as the [=over=] and [=under=] alignment points, respectively.
	</dl>

	<div class="example">
		The vertical writing mode example earlier
		(in [[#initial-letter-intro]])
		could be coded as:

		<pre>
			span.initial {
			  initial-letter: 2;
			  initial-letter-align: ideographic;
			}
		</pre>
	</div>

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

		<ol>
			<li>If the <a>initial letter</a>
			is an atomic inline,
			use its <a>over</a> and <a>under</a> content-box edges.

			<li>Else if the <a>initial letter</a>
			contains any character having the Han, Hangul, Kana, or Yi [=Unicode script=] property,
			use the [=ideographic-ink-over=] and [=ideographic-ink-under=] baselines.

			<li>Else if the <a>initial letter</a>
			contains any character having the Han, Hangul, Kana, or Yi [=Unicode script=] property,
			use the [=hanging=] and [=alphabetic=] baselines.

			<li>Else use the [=cap-height=] and [=alphabetic=] baselines.
		</ol>

	<div class="issue">
		Correct alignment of initial letter in scripts such as Hebrew and Thai
		is currently not possible because OpenType lacks corresponding metrics.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5244">Issue 5244</a>)
		<figure>
			<img src="images/hebrew-initial-letter.png" width="480"
			     alt="Hebrew 2-line drop-letter alignment using the hebrew-top and alphabetic baselines">
		</figure>
	</div>

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

<h4 id="initial-letter-align-defaults">
UA Default Stylesheet for 'initial-letter-align'</h4>

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

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

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

<h3 id="initial-letter-layout">
Initial Letter Layout</h3>

	There are two types of <a>initial letter boxes</a>:
	those that arise from non-replaced <a>inline boxes</a>
	and those that arise from <a>atomic inlines</a>.

	For the non-atomic <dfn lt="inline initial letter | inline initial letter box">inline initial letter</dfn>,
	the box and its contents
	participate in the same <a>inline formatting context</a>
	as the line on which it occurs,
	and a lot of special rules apply
	to give the expected sizing and alignment.

	For an <dfn lt="atomic initial letter | atomic initial letter box">atomic initial letter</dfn>,
	however,
	which is either a <a>replaced element</a>
	or which establishes an <a>independent formatting context</a> for its contents,
	the sizing of the box
	(aside from its <a>automatic size</a> in the <a>block axis</a>)
	and layout of the contents within the box
	follows the usual rules:
	it is primarily the positioning of the box
	which is special.

<h4 id="initial-letter-properties">
Properties Applying to Initial Letters</h4>

	All properties that apply to an <a>inline box</a>
	also apply to an <a>inline initial letter</a>
	except for 'vertical-align' and its <a>sub-properties</a>,
	'font-size', 'line-height', 'line-fit-edge', and 'inline-sizing'.
	<!-- Basically, any properties defined in css-inline
	except those specific to initial letters,
	so keep this list updated as we add things to this spec. -->
	Additionally, all of the <a>sizing properties</a>
	and 'box-sizing' also apply to <a>initial letters</a>
	(see [[!css-sizing-3]]).

	All properties that apply to an <a>atomic inline</a>
	also apply to the <a>atomic inline</a> when styled as an <a>initial letter</a>,
	except for 'vertical-align' and its <a>sub-properties</a>.

<h4 id="initial-letter-box">
Margins, Borders, and Padding</h4>

	Initial letters can be styled with [=margins=], [=padding=], and [=borders=]
	just like any other box.
	Unless 'initial-letter-align' is ''initial-letter-align/border-box'',
	its vertical alignment and [[#sizing-initial-letter|font sizing]]
	are not affected.
	However the effective exclusion area,
	which is typically the [=initial letter=]’s [=margin box=]
	(see 'initial-letter-wrap')
	is affected.

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

<h4 id="sizing-initial-letter">
Font Sizing of Initial Letters</h4>

	For an <a>inline initial letter</a>,
	the font size used for sizing the <a>initial letter</a> contents
	is calculated to fulfill its specified <a lt="initial letter size">size</a> (see 'initial-letter')
	as anchored by its specified alignment points (see 'initial-letter-align').
	Note that no layout is required in this calculation:
	it is based only on computed values and font metrics.
	These <a lt="used value">used</a> font size calculations
	<em>do not</em> affect the <a lt="computed value">computed</a> 'font-size',
	and therefore have no effect on the computation of ''em'' length values, etc.

	ISSUE(4988): What about inheritance to descendants?

	The line height used in these calculations
	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 [[CSS-LINE-GRID-1]]).
	The contents of the lines spanned,
	and therefore any variation in their heights and positions,
	is not accounted for.

	<figure>
		<img src="images/infinite-text.png" width="300"
		     alt="Text underlay shows how initial letter alignment
		          is not affected by the content of the spanned lines.">
	</figure>

	For an <var>N</var>-line drop initial in a Western script,
	the cap-height of the letter needs to be (<var>N</var> – 1) times the line-height,
	plus the cap-height of the surrounding text.
	Note this height is <em>not</em> the font size of the drop initial.

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

	<figure>
		<img src="images/InitialCapEquation.png" width="604"
		     alt="Font size of drop cap = ((N-1) * line-height + [cap-height of para] * [font size of paragraph])/[cap-height ratio of drop initial font]">
	</figure>

	<!--
	<div>
		<math display="block"><mrow><mi>Font size of drop initial</mi><mo>=</mo></mrow><mfrac><mrow><mo>(</mo><mi>N</mi><mo>-</mo><mn>1</mn><mo>)</mo><mo>&#x00D7;</mo><mi>line-height</mi><mo>+</mo><mo>(</mo><mi>cap-height ratio of para font</mi><mo>&#x00D7;</mo><mi>font size of para</mi><mo>)</mo></mrow><mrow><mi>cap-height ratio of drop initial font</mi></mrow></mfrac></math>
	</div>
	-->

	ISSUE: Update this calculation to be a) generic across writing systems / alignment points and b) handle non-integer sizes.

	<div class="example">
		A three-line drop initial in Adobe Minion Pro
		would have a font size of 61.2pt given
		12pt text, 16pt line-height, and a cap-height of 651/1000 (from the font’s OS/2 table).
	</div>

	For an <a>atomic initial letter</a>,
	the used font size is the computed font size as usual.

<h4 id="initial-letter-shaping">
Shaping and Glyph Selection</h4>

	When 'initial-letter' is not ''initial-letter/normal'',
	an [=inline initial letter=] is isolated for glyph shaping;
	however the text after it <em>should</em> shape across
	the <a>inline initial letter box</a>'s boundaries,
	assuming its presence as part of the first line’s text content.
	(See [[css-text-3#boundary-shaping]].)
	For example, if the first letter of the word “يحق”
	were styled with ''initial-letter: 2 1'',
	the first letter would be styled in its isolated form “ي”,
	as the <a>initial letter</a>,
	followed by the medial/final-form “ﺤﻖ”,
	which assumes it is preceded by the initial letter’s contents
	as normal text.

	<figure>
		<img src="images/arabic-drop-cap.png"
		     alt="Two-line Arabic drop-cap showing isolated form of the first letter, connected form of the rest of the word.">
		<figcaption>Two-line Arabic “Drop-cap”</figcaption>
	</figure>

<h4 id="initial-letter-box-size">
Sizing the Initial Letter Box</h4>

	For an <a>inline initial letter</a>,
	if the <a>initial letter</a>’s <a>preferred width</a>/<a>preferred height</a>
	is <a>definite</a>,
	use that value
	(clamped as required by the <a>min size</a> and <a>max size</a> properties,
	and handling 'box-sizing' as required)
	for that dimension of the box.

	Otherwise
	it is considered to have an <a>automatic size</a> in that dimension
	and its [=content box=] is sized to fit both:
	<ul>
		<li>
			The specified [=sink=]
			(i.e the space between the over alignment point and the under alignment point).
		<li>
			The glyph outlines of all the glyphs it contains--
			excluding any that <a spec="css-text-3">hang</a>
			(see 'hanging-punctuation')--
			as well as the [=margin boxes=] of any [=atomic inlines=] it contains.

			<div class="example" id="initial-letter-exclusions">
				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.

				<figure>
					<img src="images/Dropcap-J-3line-crash.png" width="480"
					     alt="3-line drop cap with J, with descender crashing into fourth line of text">
					<figcaption>Incorrect: three-line initial letter
					(''initial-letter: drop 3'') with descender.
					In this font, the capital “J” extends well below the baseline (shown in red).</figcaption>
				</figure>

				Therefore all [=line boxes=] impacted by the glyph outlines
				of an <a>initial letter</a> need to be excluded,
				not just those within range of the <a>initial letter sink</a>.

				<figure>
					<img src="images/Dropcap-J-3line-exclude.png" width="480"
					     alt="3-line drop cap with J, but four-line exclusion">
					<figcaption>Correct: text excluded around glyph bounding box</figcaption>
				</figure>
			</div>
	</ul>

	However, if its [=block-start=] [=padding=] and [=border=] are both zero,
	then its [=block-start=] [=content edge=] instead coincides
	with its [=over=] alignment point exactly,
	and any content overflowing above that point is ignored for the purpose of layout.

	Note: If an [=inline initial letter=] has ascenders above its [=over=] alignment point,
	and the author has not provided sufficient [=margin=]
	on either the [=initial letter=] itself or its [=containing block=],
	then those ascenders might collide with preceding content.

	Note: It might be nice to automatically provide the necessary spacing
	by treating such ascenders as a margin that can collapse
	with the margin of the containing block,
	and thus guarantee the requisite spacing without imposing any additional space
	unless it becomes actually necessary.
	Depending on implementation complexity,
	this option may be explored in the future;
	but in the meantime,
	authors need to be careful to provide the requisite spacing explicitly.

	ISSUE: 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 <a href="https://github.com/w3c/csswg-drafts/issues/310">discussion</a>.

	For <a>atomic initial letters</a>,
	sizing follows the usual rules for that type of <a>atomic inline</a>.
	However, if the box has an [=automatic size|automatic=] [=block size=] (''height/auto''),
	then its <a>block size</a> is determined
	as for an <a>inline initial letter</a>
	with ''initial-letter-align/border-box'' alignment,
	and is <a>definite</a>.

<h4 id="initial-letter-content-align">
Alignment Within an Initial Letter Box</h4>

	By default (i.e. under <a>automatic sizing</a>),
	the content box of an <a>inline initial letter</a>
	is fitted exactly to its content,
	and alignment properties like 'text-align' or 'align-content' do not apply.
	However, if the box is <em>not</em> sized automatically:

	<ul>
		<li>
			If the <a>inline size</a> is <a>definite</a>,
			'text-align' is honored
			for aligning the contents of the <a>initial letter</a>
			within its box in the <a>inline axis</a>
			(using its <a>inline-axis</a> bearings as usual,
			not the bounding box of its glyph outlines).

		<li>
			If the <a>block size</a> is <a>definite</a>,
			'align-content' is honored
			for aligning its contents in the <a>block axis</a>
			(using its <a>block-axis</a> bearings,
			synthesizing them if needed).
	</ul>

<h3 id="initial-letter-position">
Initial Letter Positioning and Spacing</h3>

<h4 id="initial-letter-block-position">
Block-axis Positioning</h4>

	In the <a>block axis</a>, the <a>initial letter</a> is positioned
	with respect to the [=line box=] in which it [=originates=]
	as required to satisfy its alignment ('initial-letter-align')
	and specified [=initial letter sink|sink=] ('initial-letter'):

	* If its [=initial letter size|size=] is greater than or equal to
		its [=initial letter sink|sink=],
		the [=initial letter=] is positioned
		to satisfy its <a>under</a> alignment,
		and then shifted by
		([=initial letter sink|sink=] - 1) &times; 'line-height' of [=containing block=]
		towards the [=containing block=]’s [=block end=].

	* If its [=initial letter size|size=] is less than
		its [=initial letter sink|sink=],
		the [=initial letter=] is positioned
		to satisfy its <a>over</a> alignment.

	Note: An [=initial letter=] is essentially positioned
	such that it would sink the number of lines
	specified by 'initial-letter'’s second argument
	and align to the requisite <a>under</a> alignment point
	if it was assumed that its containing block held only
	the <a>initial letter</a> itself
	followed by an infinite sequence of plain text
	as the direct contents of its <a>root inline box</a>.
	Its position is not affected by line height inconsistencies
	introduced by the contents of the impacted line boxes.

	<figure>
		<img src="images/infinite-text.png" width="300"
		     alt="Constant-sized text underlay shows how initial letter alignment
		          is not affected by the content of the spanned lines.">
	</figure>

	The [=initial letter=] does not increase the [=logical height=]
	of the [=line box=] in which it participates:
	it can protrude above or below it.
	It must be positioned such that its own [=block-start=] [=margin edge=]
	is below its [=containing block=]’s [=block-start=] [=content edge=],
	and thus can force its [=originating line box=] (and subsequent content)
	to shift further away from that edge.

<h4 id="initial-letter-inline-position">
Inline Kerning</h4>

	If the <a>initial letter</a> is a non-atomic inline
	with an [=automatic size|automatic=] [=inline size=] and
	zero padding and borders,
	its [=margin box=] is kerned (negatively inset)
	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 [=line box=]
	if it were not an <a>initial letter</a>
	(i.e. the distance between its glyph bounding box
	and its start side bearing).
	This inset is effectively
	an additional [=inline-start=] [=margin=] on the box.

<h3 id="initial-letter-wrapping">
Initial Letter Wrapping: the 'initial-letter-wrap' property</h3>

	Note: 'initial-letter-wrap' is at risk.

	<pre class="propdef">
	Name: initial-letter-wrap
	Value: none | first | all | grid | <<length-percentage>>
	Initial: none
	Applies to: certain inline-level boxes and <css>::first-letter</css> and inside <css>::marker</css> boxes (<a href="#first-most-inline-level">see prose</a>)
	Inherited: yes
	Percentages: relative to <a>logical width</a> of (last fragment of) initial letter
	Computed value: specified keyword or computed <<length-percentage>> value
	Animation type: by computed value type
	</pre>

	This property specifies whether lines impacted by an <a>initial letter</a>
	are shortened to fit the rectangular shape of the <a>initial letter</a> box
	or the contour of its glyph outline.

	<dl dfn-for=initial-letter-wrap dfn-type=value>
		<dt><dfn>none</dfn>
		<dd>
			No contour-fitting is performed:
			each impacted line is aligned flush to
			the [=inline-end=] [=margin edge=] of the [=initial letter=].

		<dt><dfn>first</dfn>
		<dd>
			Behaves as ''initial-letter-wrap/none''
			if the first <a>typographic character unit</a> after the <a>initial letter</a>
			belongs to Unicode General Category Zs.
			Otherwise behaves as for ''initial-letter-wrap/all''
			on the first line of the block containing the initial letter
			and as ''initial-letter-wrap/none'' on the rest.

			<div class="example">
				This example shows why contour-fitting the first line is necessary,
				and why it is dropped when the <a>initial letter</a> is followed by a space:
				<figure>
					<img src="images/OpticalKerning.png" width="200"
					     alt="optical kerning in the presence or absence of a space after the initial letter">
					<figcaption>
						In the top paragraph, the initial letter "A" has a word space after it:
						the gap between the top of the "A" and the next letter
						provides the necessary word separation.
						In the next paragraph, the initial letter "A"
						is part of the first word,
						and leaving a gap between the top of the "A" and the next letter
						would create a jarring visual break within the word.
						In this case, the first line of text
						should be kerned into the initial letter's area,
						as shown in the bottom paragraph.
					</figcaption>
				</figure>
			</div>

			Issue: Do we need an unconditional ''initial-letter-wrap/first''?
			(I.e. Should we rename this value to ''initial-letter-wrap/auto'' and add a ''initial-letter-wrap/first'' value
			that does not check for spaces?) See GitHub issue
			<a href="https://github.com/w3c/csswg-drafts/issues/410">410</a>

		<dt><dfn>all</dfn></dt>
		<dd>
			For each line of text impacted by the [=initial letter=],
			the [=line box=] adjacent to the [=initial letter=] starts
			at the [=start=]-most point that does not overlap
			the [=initial letter=]’s glyph outline.

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

			In both cases, 'shape-margin' is applied to expand the outline,
			and the resulting outline is clipped
			by the [=initial letter=]’s [=margin edges=].

			Note: This value is at-risk.

		<dt><dfn>grid</dfn>
		<dd>
			This value is the same as ''initial-letter-wrap/none'',
			except that the exclusion area of the impacted lines
			is increased as necessary for its end-edge to land on the character grid,
			i.e. to be a multiple of (''1ic'' + 'letter-spacing')
			as computed on the containing block.
			The 'justify-self' property can then be used to align
			the initial letter box within the exclusion area.

			<figure>
				<img src="images/CJK-Initial.001.png" width="480"
				     alt="Diagram of Japanese initial letter in vertical writing mode">
				<figcaption>Diagram of Japanese initial letter in vertical writing mode</figcaption>
			</figure>

			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.


		<dt><dfn><<length>></dfn>
		<dt><dfn><<percentage>></dfn>
		<dd>
			This value behaves the same as ''initial-letter-wrap/first''
			except that the adjustment to the first line is given explicitly
			instead of being inferred from the glyph shape.

			Issue: 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 ''initial-letter-wrap/first'' value
			and to set margins to control spacing,
			and to use this as a fallback for glyph detection if necessary.

			<div class="example">
				In the following example, UAs that support ''initial-letter-wrap/first''
				will use the glyph outline
				plus the specified margin in order to place the first line,
				whereas UAs that only support <<length>> or <<percentage>> values
				will pull in the first line by 40% of the initial letter's width
				(and then add the margin to that point).
				<pre>
					h1 + p:first-letter {
						initial-letter: 3; /* 3-line drop-cap */
						initial-letter-wrap: first;
						margin-right: 0.1em;
					}
					@supports (not (initial-letter-wrap: first)) {
						/* Classes auto-generated on paragraphs to match first letter. */
						p.A:first-letter {
							initial-letter-wrap: -40%; /* Start of glyph outline, assuming correct font. */
						}
					}
				</pre>
			</div>

			Issue: These values and related annoyance is likely unnecessary if someone submits a patch to Blink to support ''initial-letter-wrap/first''.
	</dl>

	Issue: Edit figure to show how auto behaves in varying contexts

	<div class="example">
		<pre>
			p::first-letter {
			  initial-letter: 3;
			  initial-letter-wrap: none;
			}
		</pre>

		<figure>
			<img src="images/A-wraparound-none.png" width="600"
			     alt="regular dropcap A">
			<figcaption>Ordinary initial letter with no wrapping.</figcaption>
		</figure>
	</div>


	<div class="example">
		<pre>
			p::first-letter {
			  initial-letter: 3;
			  initial-letter-wrap: all;
			}
		</pre>

		<img src="images/A-wraparound.png" width="600"
		     alt="text wrapping around dropcap A" >

		Text follows shape of initial letter.
		Each line box should just touch the ink of the letter,
		with some offset (represented by the shaded box).
	</div>

	<div class="example">
		<pre>
			p::first-letter {
			  initial-letter: 3;
			  initial-letter-wrap: first;
			}
		</pre>

		<img src="images/A-wraparound-first.png" width="600"
		     alt="text wrapping around dropcap A but only on first line">

		Only the first line is moved up against the ink of the initial letter.
	</div>

	<div class="example">
		<pre>
			p::first-letter {
			  initial-letter: 3;
			  initial-letter-wrap: all;
			}
		</pre>

		<img src="images/V-wraparound.png" width="600"
			alt="text wrapping around dropcap V">

		<img src="images/P-wraparound.png" width="600"
		     alt="text wrapping around dropcap P">

		<img src="images/W-wraparound.png" width="600"
		     alt="text wrapping around dropcap W">
	</div>

<h3 id="initial-letter-line-layout">
Line Layout</h3>

	An <a>initial letter box</a> is considered [=in-flow=] in its <a>block formatting context</a>,
	and is part of the contents of the <a>line box</a> in which it originates
	(its <dfn lt="originating line | originating line box" local-lt="originate">originating line box</dfn>).
	Aside from the vertical axis
	(see [[#initial-letter-block-position]]),
	its interaction with the rest of the contents of the line
	is as normal for [=inline-level content=],
	except in a few specific details&hellip;

<h4 id="initial-letter-inline-flow">
Inline Flow Layout: Alignment, Justification, and White Space</h4>

	An [=initial letter box=] is handled similar to any other
	[=inline-level=] content participating in its [=originating line box=],
	including participation in alignment, justification,
	and white space processing.

	However, to ensure consistent alignment of all the impacted lines,
	[=collapsible white space=]
	between a [=sunken initial=] and subsequent content on its [=originating line=]
	is collapsed away,
	and any 'letter-spacing' or <a>justification opportunity</a>
	that would normally be introduced by
	the juxtaposition of the contents of a <a>sunken initial</a>
	and the subsequent contents of the line
	is suppressed.
	(Note that this does not affect 'word-spacing' or
	the <a>justification opportunity</a> introduced by a <a spec=css-text>word separator</a>
	because that space is provided by the <a>typographic character unit</a> alone
	and not by its juxtaposition with an adjacent character.)

<h4 id="initial-letter-indentation">
Edge Effects: Indentation and Hanging Punctuation</h4>

	'text-indent' and 'hanging-punctuation'
	apply to an [=initial letter=]’s [=originating line box=] as usual,
	and cause a shift in the start of the line’s contents
	including the [=initial letter=] itself.
	Subsequent lines affected by the exclusion are shortened as usual,
	possibly more or less than otherwise depending on the resulting position
	of the [=initial letter=].

	<figure>
		<img src="images/InitialLetterWithTextIndent.png" width="300"
		     alt="initial letter with text indent">
		<figcaption>Initial letter with text indent. </figcaption>
	</figure>

	ISSUE: The interaction of 'initial-letter' and 'hanging-punctuation'
	is <a href="https://github.com/w3c/csswg-drafts/issues/310#issuecomment-396765893">under discussion</a>.

<h4 id="initial-letter-ancestors">
Ancestor Inlines</h4>

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

<h4 id="initial-letter-multi-line">
Multi-line Initial Letters</h4>

	If an initial letter is too long to fit on one line,
	it wraps (according to the usual text-wrapping rules),
	each line filled and formatted exactly as if it were the first line
	and the initial letter too long to fit any subsequent normal text.
	Any normal text after the initial letter starts on its last line,
	affected exactly as if that line were the first line.

	<figure>
		<img src="images/Multi-line-initial.png" width="300"
		     alt="multi-line drop cap">
		<figcaption>Drop cap extends to two lines.</figcaption>
	</figure>

<h3 id="initial-letter-paragraphs">
Clearing Initial Letters</h3>

<h4 id="raised-sunken-caps">
Raised and sunken caps</h4>
<!--old text
	An initial letter does not affect the position of its containing element.
	For “raised caps” or “sunken caps,”
	the effect is created as if the text around the initial letter was pushed down,
	rather than the letter extending up into previous elements.

-->

	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.



	<figure>
		<img src="images/initial-letter-drop-para-compare.png" width="600"
		     alt="raised cap para after normal para">
		<figcaption>
			Raised cap (<code>initial-letter: 3 1</code>) on right;
			note that the position of the “C” is the same in both cases,
			but on the right all text is moved down relative to the initial letter.
		</figcaption>
	</figure>

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

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


<h4 id="short-para-initial-letter">
Short paragraphs with initial letters</h4>

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

	<figure>
		<img src="images/initial-letter-short-para.png" width="600"
			 alt="short para with initial letter">
		<figcaption>
			The red text is a short paragraph with an initial letter.
			Note the subsequent paragraph wraps around the initial letter
			just as text in the paragraph with the initial letter does.
		</figcaption>
	</figure>

	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.

	<figure>
		<img src="images/initial-letter-short-para-initial.png" width="600"
		     alt="short para with initial letter followed by para with initial">
		<figcaption>
			The red text is a short paragraph with an initial letter.
			The subsequent paragraph clears because it also has an initial letter.
		</figcaption>
	</figure>

<h4 id="initial-letter-floats">
Interaction with floats</h4>

	<a>Initial letters</a> are not <a href="https://www.w3.org/TR/CSS21/visuren.html#floats">floats</a>:
	they are <a>in-flow</a> <a>inline-level</a> content
	that belongs to a <a>line box</a>.
	Therefore:

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

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

		<figure>
		<img src="images/float-interaction.png" width="480"
		     alt="initial letter interacting with floats">
		<figcaption>
			In the absence of an initial letter, the first line of text could abut the blue float.
			But the presence of the initial letter requires that the text move over.
		</figcaption>
	</figure>


	See <a href="https://www.w3.org/TR/CSS21/visuren.html#floats">CSS2&sect;9.5</a>
	for more information about the layout of floats
	and adjacent content.
	[[!CSS2]]

	ISSUE: Whether an inline-end float originating in subsequent lines
	must clear the initial letter (as inline-start floats do)
	is <a href="https://lists.w3.org/Archives/Public/www-style/2018Jul/0019.html">still under discussion</a>.
	There is no aesthetic reason to require it;
	however it’s yet unclear how the underlying layout model
	would distinguish between the two cases.

<h4 id="initial-letter-breaking">
Interaction with Fragmentation (Pagination)</h4>

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

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

<h2 class="no-num" id="baseline-synthesis">
Appendix A: Synthesizing Alignment Metrics</h2>

<h3 class="no-num" id="baseline-synthesis-em">
A.1: Calculating [=Em-over=] and [=Em-under=]</h3>

	Note: The [=em-over=] and [=em-under=] baselines are not used by CSS.
	Their definitions are included in this module
	for consistency with the other metrics used by
	<a href="https://html.spec.whatwg.org/multipage/canvas.html#textmetrics">Canvas TextMetrics API</a>.

	The [=em-over=] and [=em-under=] metrics are calculated as follows:

	* If any one of
		[=central=], [=ideographic-over=], or [=ideographic-under=]
		is defined by the font,
		then [=em-over=] is 0.5em over the [=central=] baseline,
		and [=em-under=] is 0.5em under it,
		with the [=central=] baseline derived from the others
		if missing or undefined
		(see below).

	* Otherwise, the [=ascent=] and [=descent=]
		are both proportionally augmented or reduced
		to add up to exactly 1em,
		and these normalized metrics are taken
		as the [=em-over=] and [=em-under=] metrics, respectively.

	Note: This calculation ensures that [=em-over=] and [=em-under=]
	are always exactly 1em apart
	while trying to center the glyph outlines’ “center of gravity” between them.

<h3 class="no-num" id="baseline-synthesis-fonts">
A.2: Synthesizing Baselines (and Other Font Metrics) for Text</h3>

	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:

	<dl>
		<dt>Use related metrics
		<dd>
			Certain metrics are typically related,
			and this relationship can be used
			to at least heuristically derive the missing metric.
			If the font format itself does not define any specific calculations,
			the following rules may be used:

			<ol>
				<li>
					The [=central baseline=] is defined to be
					halfway between the [=ideographic-over=] and [=ideographic-under=] baselines,
					so any two of these determines the third.
				<li>
					The [=ideographic-over=] and [=ideographic-under=] baselines
					are typically ''1em'' apart,
					so if only one of the
					[=ideographic-over=]/[=ideographic-under=]/[=central=]
					baselines are provided,
					this relation can be used to calculate the other two.
				<li>
					In CJK fonts the [=ascent=] and [=descent=] typically match
					the [=ideographic-over=] and [=ideographic-under=] baselines,
					so can be used as a fallback when both are missing.
			</ol>

		<dt>Measure the font
		<dd>
			Metrics may be derived from the glyph shapes.
			For example,
			<ol>
				<li>
					The center of the minus sign (U+2212)
					can be taken as the mathematical baseline.

				<li>
					The amount by which the lowercase “o”
					descends below the alphabetic baseline
					can be subtracted from its highest point
					to <a href="https://drafts.csswg.org/css-values/#ex">measure the x-height</a>.

					<figure>
						<img src="images/measuring-x-height-o.png" width="240"
						alt="measuring the x height of the letter o"  >
						<figcaption>
							Measuring the x height.
						</figcaption>
					</figure>

				<li>
					The amount by which the uppercase “O”
					descends below the alphabetic baseline
					can be subtracted from its highest point
					to measure the cap-height.

				<li>
					The bounding box of 永 (U+6C38) can be used to find
					the ideographic character face edges.

				<li>
					The top edge of the center of the Hebrew He (U+05D4 “ה”)
					can be taken as the Hebrew hanging baseline.

				<li>
					The top edge of the center of the letter Ka
					can be taken as the hanging baseline.
					Which Ka is used should depend on the <a>content language</a>:

					<table class="data">
						<thead>
							<tr>
								<th>Language
								<th>Script
								<th>Letter
						<tbody>
							<tr>
								<td>
								<td>Devanagari
								<td>क U+0915 KA
							<tr>
								<td>
								<td>Bengali
								<td>ক U+0995
							<tr>
								<td>
								<td>Gurmukhi
								<td>ਕ U+0A15
							<tr>
								<td>
								<td>Tibetan
								<td>ཀ U+0F40
					</table>

					Issue: Pick a default.

					<figure>
						<img src="images/measuring-hanging-baseline-ka.png" width="240"
						alt="finding the position of the hanging baseline of the letter ka"  >
						<figcaption>
							The hanging baseline is at the top edge of the character ink.
						</figcaption>
					</figure>

				<li>Issue: Add more notes here?
			</ol>

			Issue: Somebody sanity-check these heuristics please.

		<dt>Use fallback values
		<dd>
			The following fallback values are suggested:

			<ul>
				<li>x-height: .5em;
				<li>cap-height: .66em;
				<li>hanging baseline: .6em;
			</ul>
	</dl>

<h3 class="no-num" id="baseline-synthesis-box">
A.3: Synthesizing Baselines for Atomic Inlines</h3>

	If an [=atomic inline=]
	(such as an inline-block, inline-table, or [=replaced element=])
	does not have a content-derived [=baseline set=]
	in the [=inline axis=] of the [=inline formatting context=] in which it participates,
	then the UA must synthesize its [=baselines=] as follows
	in order to align it.

	These [=baselines=] are assumed to be
	<strong>at its [=line-under=] [=margin edge=]</strong>:
	<ul>
		<li>[=text-under baseline=]
		<li>[=ideographic-under baseline=]
		<li>[=ideographic-ink-under baseline=]
		<li>[=alphabetic baseline=]
	</ul>

	These [=baselines=] are assumed to be <strong>halfway between
	its [=line-under=] and [=line-over=] [=margin edges=]</strong>:
	<ul>
		<li>[=central baseline=]
		<li>[=math baseline=]
		<li>[=x-middle baseline=]
	</ul>

	These [=baselines=] are assumed to be
	<strong>at its [=line-over=] [=margin edge=]</strong>:
	<ul>
		<li>[=text-over baseline=]
		<li>[=ideographic-over baseline=]
		<li>[=ideographic-ink-over baseline=]
		<li>[=cap-height baseline=]
		<li>[=hanging baseline=]
		<li>[=x-height baseline=]
	</ul>

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

	<div class="example">
		In this example, the author is using a set of images
		to display characters that don't exist.

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

	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 <css>baseline-table</css> property
	that accepts ''[&lt;baseline-keyword> <<percentage>>]+''.)

<h2 class="no-num" id="changes">
Changes</h2>

	Changes since the <a href="https://www.w3.org/TR/2024/WD-css-inline-3-20240812/">12 August 2024 Working Draft</a>:
	<ul>
		<li>Defined behavior of 'text-box-trim' on [=multi-column containers=].
			(<a href="https://github.com/w3c/csswg-drafts/issues/5335">Issue 5335</a>)
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2024/WD-css-inline-3-20240808/">8 August 2024 Working Draft</a>:
	<ul>
		<li>Some minor clean-up of references to 'text-box-edge' left over from when it also represented 'line-fit-edge'.
		<li>Adjusted ''text-box-edge: auto'' to reference 'line-fit-edge' on the affected [=line box=]
			rather than computing to the 'line-fit-edge' of the specifying element.
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2023/WD-css-inline-3-20230401/">1 April 2023 Working Draft</a>:
	<ul>
		<li>Split 'text-box-edge' into two properties--
			'text-box-edge' for controlling the 'text-box-trim' edge
			and 'line-fit-edge' for controlling line box sizing--
			and added the 'text-box' [=shorthand=].
			(Issues <a href="https://github.com/w3c/csswg-drafts/issues/8829">8829</a>
			and <a href="https://github.com/w3c/csswg-drafts/issues/8696">8696</a>)
		<li>Added ''trim-*'' prefix to 'text-box-trim' keywords
			so that they make sense in the context of the 'text-box' shorthand.
			(<a href="https://github.com/w3c/csswg-drafts/issues/10675">Issue 10675</a>)
		<li>Use the innermost trim edge for 'text-box-trim'
			when multiple ancestors request trimming.
			(<a href="https://github.com/w3c/csswg-drafts/issues/5426">Issue 5426</a>)
		<li>Apply negative [=block-axis=] margins to descendants of [=inline boxes=]
			when calculating their [=layout bounds=]
			so that they can actually have the specified effect.
			(<a href="https://github.com/w3c/csswg-drafts/issues/8182">Issue 8182</a>)
		<li>Corrected [=phantom line boxes=] to only account for [=inline-axis=] box decorations.
			(<a href="https://github.com/w3c/csswg-drafts/issues/9344">Issue 9344</a>)
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2022/WD-css-inline-3-20221114/">14 November 2022 Working Draft</a>:
	<ul>
		<li>Renamed <css>text-edge</css> to 'text-box-edge' and <css>leading-trim</css> to 'text-box-trim',
			and also renamed their initial values.
			(<a href="https://github.com/w3c/csswg-drafts/issues/8067">Issue 8067</a>)
		<li>Floor the [=line gap metric=] at zero.
			(<a href="https://github.com/w3c/csswg-drafts/issues/5064">Issue 5064</a>)
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2020/WD-css-inline-3-20200827/">28 August 2020 Working Draft</a>:
	<ul>
		<li>Fixed 'inline-sizing' to be [=CSS/inherited=], as was originally intended.
			(<a href="https://github.com/w3c/csswg-drafts/issues/1974">Issue 1974</a>)
		<li>Update 'inline-sizing' “Applies to” to exclude ruby boxes.
		<li>Editorial fixes, including missing images.
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2020/WD-css-inline-3-20200618/">18 June 2020 Working Draft</a>
	include:
	<ul>
		<li>Added ''initial-letter-align/leading'' value to 'initial-letter-align'
		to handle common practices for certain Indic scripts.
		See <a href="https://www.w3.org/TR/ilreq/#h_scripts_without_hanging_baseline">Indic Layout Requirements</a>.
		(<a href="https://github.com/w3c/csswg-drafts/issues/864">Issue 864</a>)

		<li>Make non-zero padding and border block effects of <css>leading-trim</css> from ancestors.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5237">Issue 5237</a>)

		<li>Remove ''hebrew'' value from 'initial-letter-align'.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5208">Issue 5208</a>)

		<li>Use the under alignment point for initial letters whose size is less than the sink.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5329">Issue 5329</a>)

		<li>Collapse white space adjacent to [=dropped initials=].
		(<a href="https://github.com/w3c/csswg-drafts/issues/5120">Issue 5120</a>)

		<li>Make [=dropped initials=] behave the same as [=raised initials=] for the purpose of 'text-align'.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5207">Issue 5207</a>)

		<li>Altered interaction of 'shape-margin', 'margin', and 'shape-outside' to match floats (see 'initial-letter-wrap').
		(<a href="https://github.com/w3c/csswg-drafts/issues/5119">Issue 5119</a>)

		<li>Added definitions for [=em-over=] and [=em-under=] baselines
		for reference by Canvas 2D.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5312">Issue 5312</a>)

		<li>Slight refinements to the (new) syntax of 'vertical-align'.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5235">Issue 5235</a>)

		<li>Define fallback shift for ''baseline-shift: sub | super''.
		(<a href="https://github.com/w3c/csswg-drafts/issues/5225">Issue 5225</a>)
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2020/WD-css-inline-3-20200604/">4 June 2020 Working Draft</a>
	include:

	<ul>
		<li>
			Reworked the relationship of the earlier <css>line-sizing</css> and <css>text-box-trim</css> proposals
			to create <css>text-edge</css> and a differently-structured <css>leading-trim</css>.
			(<a href="https://github.com/w3c/csswg-drafts/issues/5168">Issue 5168</a>)

		<li>
			Shifted the [=line-relative shift values=] of 'vertical-align'
			from the 'alignment-baseline' longhand to the 'baseline-shift' longhand.
			(<a href="https://github.com/w3c/csswg-drafts/issues/5180">Issue 5180</a>)

		<li>
			Integrated <css>text-edge</css> into [[#inline-height|line box height calculations]].

		<li>
			Refactored definitions of various baselines into [[#css-metrics|their own section]]
			and imported introduction and core terminology from [[CSS-WRITING-MODES-3]].

		<li>
			Imported and updated / integrated remaining baseline alignment and line box sizing prose from [[CSS2]].

		<li>
			Defined atomic inline baseline synthesis rules for all baselines.

		<li>
			Defined the [=central baseline=] definitively as the <em>ideographic</em> central baseline.

		<li>
			Defined white space collapsing between an [=initial letter box=] and subsequent text.
			(<a href="https://github.com/w3c/csswg-drafts/issues/5120">Issue 5120</a>)

		<li>
			Tightened up box model definitions for [=initial letter boxes=],
			including interaction with its [=containing block=].
			(<a href="https://github.com/w3c/csswg-drafts/issues/719">Issue 719</a>)

		<li>
			Miscellaneous small fixes, clarifications, and editorial improvements.
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2018/WD-css-inline-3-20180808/">8 August 2018 Working Draft</a>
	include:

	<ul>
		<li>
			Added <css>line-sizing</css> property to control how inter-line spacing is calculated.
			(<a href="https://github.com/w3c/csswg-drafts/issues/3199">Issue 3199</a>)
		<li>
			Added 'baseline-source' property to control whether first or last baseline
			is used for alignment.
			(<a href='https://github.com/w3c/csswg-drafts/issues/861'>Issue 861</a>)
		<li>
			Added <css>leading-trim</css> proposal to control the metrics used for the
			line-over/line-under edge in line box layout.
			(<a href="https://github.com/w3c/csswg-drafts/issues/3240">Issue 3240</a>
			and <a href="https://github.com/w3c/csswg-drafts/issues/3955">3955</a>)
		<li>
			Imported 'line-height' definition and related normative prose from [[CSS2]].
		<li>
			Improved high-level description of inline layout in [[#model]].
		<li>
			Renamed <css>initial-letters</css> back to 'initial-letter'.
			(<a href="https://github.com/w3c/csswg-drafts/issues/862">Issue 862</a>)
		<li>
			Added the ''initial-letter/raise'' and ''initial-letter/sink'' keywords for syntactic convenience.
			(<a href="https://github.com/w3c/csswg-drafts/issues/2955">Issue 2955</a>)
		<li>
			Specified synthesis of baselines for [=atomic inlines=] that have no baseline set.
		<li>
			Clarified interpretation of ''vertical-align/middle'', ''vertical-align/text-top'', and ''vertical-align/text-bottom'' in [=vertical writing modes=].
			(<a href="https://github.com/w3c/csswg-drafts/issues/4495">Issue 4495</a>)
		<li>
			Clarified that ''vertical-align/text-top''/''vertical-align/text-bottom''/''text-box-trim/text'' values should be consistently interpreted across 'vertical-align', 'dominant-baseline', <css>leading-trim</css>, and drawing the content box of an inline box.
			(<a href="https://github.com/w3c/csswg-drafts/issues/3978">Issue 3978</a>)
		<li>
			Corrected initial value of 'dominant-baseline' to ''dominant-baseline/auto''.
			(<a href="https://github.com/w3c/csswg-drafts/issues/4115">Issue 4115</a>)
		<li>
			Improved some nuances in authoring advice regarding 'vertical-align' longhands vs. shorthands.
		<li>
			Clarified interaction of 'initial-letter' and 'float'/'position'.
		<li>
			Reorganized the [[#initial-letter-layout]] section for better readability,
			and tweaked some wording for clarity.
		<li>
			Defined that 'shape-margin' applies to the glyph outline.
		<li>
			Switched baseline synthesis rules to use 永 (U+6C38) for ideographic face edges.
		<li>
			Specified that an [=initial letter=] is isolated wrt shaping,
			even though text after it remains in its connecting form.
			(<a href="https://github.com/w3c/csswg-drafts/issues/2399#issuecomment-635630662">Issue 2399</a>)
	</ul>

	See also earlier
	<a href="https://www.w3.org/TR/2018/WD-css-inline-3-20180808/">changes since the 24 May 2016 Working Draft</a>.

<h2 class="no-num" id="ack">
Acknowledgments</h2>

	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,
	Mike Bremford,
	David M Brown,
	Oriol Brufau,
	John Daggett,
	Stephen Deach,
	Sylvain Galineau,
	David Hyatt,
	Myles Maxfield,
	Shinyu Murakami,
	Jan Nicklas,
	Tess O’Connor,
	Sujal Parikh,
	Florian Rivoal,
	Alan Stearns,
	Weston Thayer,
	Bobby Tung,
	Chris Wilson,
	Grzegorz Zygmunt.

<h2 class=no-num id=privacy>Privacy Considerations</h2>

No new privacy considerations have been reported on this specification.

<h2 class=no-num id=security>Security Considerations</h2>

No new security considerations have been reported on this specification.