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/2018/WD-css-inline-3-20180808/
Previous version: https://www.w3.org/TR/2016/WD-css-inline-3-20160524/
Previous version: https://www.w3.org/TR/2015/WD-css-inline-3-20150917/
Previous version: https://www.w3.org/TR/2014/WD-css-inline-3-20141218/
Previous version: https://www.w3.org/TR/2002/WD-css3-linebox-20020515/
!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: Dave Cramer, Hachette Livre, dauwhe@gmail.com, w3cid 65283
Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact, w3cid 35400
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.  The formatting of elements and text within a line, its positioning in the inline progression direction, and the breaking of lines are described in [[CSS-TEXT-3]].  This module describes the positioning in the block progression direction both of elements and text within lines and of the lines themselves.  This positioning is often relative to a baseline.  It also describes special features for formatting of first lines and drop caps.  It extends on the model in [[CSS2]].
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-letters-wrap' property
</pre>

<pre class="link-defaults">
spec:css-align-3; type:dfn; text:alignment baseline
spec:css-box; type:dfn; text:content area
spec:css-break-3; type:dfn; text:fragment
</pre>

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

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

	ISSUE: Many aspects of layout here depend on font metrics.
	While the relevant metrics exist in OpenType for Latin/Cyrillic/Greek and for CJK,
	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.

<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> keywords as their property value.
	For readability they have not been repeated explicitly.

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

	A [=block container=] element that directly contains
	[=inline-level=] content--
	such as [=inline boxes=], [=atomic inlines=], and [=text runs=]--
	establishes an [=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.
	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 rectangular area that contains the boxes
	that form a line of [=inline-level content=]
	is called a <dfn>line box</dfn>.

	Note: <a>Line boxes</a> and <a>inline boxes</a> and <a>inline-level boxes</a>
	are each different things!
	See [[CSS-DISPLAY-3]] for an in-depth discussion of box types and related terminology.

	[=Line boxes=] are created as needed
	to hold inline-level content
	within an inline formatting context.
	When an [=inline box=] exceeds the [=logical width=] of a [=line box=],
	or contains a <a spec="css-text-3">forced line break</a>,
	it is split (see [[css-text-3#line-breaking]])
	into several [=fragments=] [[css-break-3]],
	which are distributed 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 the [=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 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]].)

	Within the line box,
	inline-level boxes can be aligned
	along the [=block axis=]
	in different ways:
	their over or under edges can be aligned,
	or the baselines of text within them can be aligned.
	See 'vertical-align' and its longhands.
	The [=logical height=] of a line box is fitted to its contents
	by the rules given in [[#line-sizing-property]].

	Line boxes that contain no text,
	no [=preserved white space=],
	no [=inline boxes=] with non-zero [=margins=], [=padding=], or [=borders=],
	and no other [=in-flow=] content
	(such as [=atomic inlines=] or [=ruby annotations=]),
	and do not end with a preserved newline
	must be treated as zero-<a lt="logical height">height</a> line boxes
	for the purposes of determining the positions of any elements inside of them
	(such as [=absolutely positioned boxes=]),
	and must be treated as not existing for any other purpose
	(such as <a href="https://www.w3.org/TR/CSS2/box.html#collapsing-margins">collapsing margins</a>).

<h2 id="line-height">
Line Heights and Baseline Alignment</h2>

	<p class="issue">This section is being rewritten. Refer to <a href="https://www.w3.org/TR/CSS2/visudet.html#line-height">section 10.8</a> of [[CSS2]] for the normative CSS definition or the <a href="https://www.w3.org/TR/2002/WD-css3-linebox-20020515/">2002 Working Draft</a> if you want pretty pictures. (But ignore the old text, half of it's wrong. We're not specifying which half, that's to be determined.)
	<strong>The CSS2 specification should be used as the guideline for implementation.</strong></p>

	Issue: The CSSWG would like to know which baseline values are necessary: if any can be dropped, or any need to be added. See GitHub issue <a href="https://github.com/w3c/csswg-drafts/issues/859">859</a>.

<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, table columns, grid containers, and flex containers
	Inherited: yes
	Percentages: N/A
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	This property specifies the <dfn>dominant baseline</dfn>,
	which is the baseline used to align the box's text and inline-level contents.
	It is also indicates the default <a>alignment baseline</a>
	of any boxes participating in <a>baseline alignment</a>
	in the box’s <a>alignment context</a>.
	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'', or ''sideways-right''.
			Equivalent to ''dominant-baseline/central'' in <a>vertical writing modes</a>
			when 'text-orientation' is ''mixed'' or ''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 bottom of the em box as the baseline.

		<dt><dfn>alphabetic</dfn>
		<dd>
			Use the alphabetic baseline.

		<dt><dfn>ideographic</dfn>
		<dd>
			Match the box's ideographic under-side baseline to that of its parent.
			This corresponds to the <code>ideo</code> baseline in OpenType.

		<dt><dfn>middle</dfn>
		<dd>
			Use the “middle” baseline: halfway between the alphabetic baseline and the ex-height.

		<dt><dfn>central</dfn>
		<dd>
			Use the central baseline
			(halfway between the ascent and descent).

		<dt><dfn>mathematical</dfn>
		<dd>
			Use the mathematical baseline.

		<dt><dfn>hanging</dfn>
		<dd>
			Use the hanging baseline.

		<dt><dfn>text-top</dfn>
		<dd>
			Use the top of the em box as the baseline.
	</dl>

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

	Issue: Should be text-over and text-under instead of text-top and text-bottom,
	but maybe it's better not to use those terms for consistency with legacy 'vertical-align'.
	See GitHub issue <a href="https://github.com/w3c/csswg-drafts/issues/860">860</a>.

	Issue: Add <css>first</css> and <css>last</css> values.
	Note, in this property, these are combinatorial,
	whereas in the <css>align/justify-self/content</css> properties, it's singular.
	Do we want to align the syntaxes wrt hyphens vs. spaces or what?
	See GitHub issue <a href="https://github.com/w3c/csswg-drafts/issues/861">861</a>.

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

	<pre class="propdef shorthand">
	Name: vertical-align
	Value: <<'baseline-source'>> || <<'baseline-shift'>> || <<'alignment-baseline'>>
	Initial: baseline
	Applies to: inline-level boxes
	Inherited: no
	Percentages: N/A
	</pre>

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

	<p class="advisement">
		Authors should use this property ('vertical-align') instead of its longhands
		(unless it is specifically needed to cascade its longhands independently).

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

	ISSUE: This is a rough draft, not ready for implementation. Also might rename stuff.

	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.
	Values have the following meanings:

	<dl dfn-for=alignment-baseline 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>

<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 | bottom | center | top
	Initial: baseline
	Applies to: inline-level boxes, flex items, grid items, table cells
	Inherited: no
	Percentages: N/A
	Computed value: specified keyword
	Animation type: discrete
	</pre>

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

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

	Values are defined below:

	For the following definitions,
	the margin box is used for atomic inlines,
	the leading box for non-replaced inlines,
	and the baselines of the box are <a lt="synthesized baseline">synthesized</a> if missing in the line-box's inline axis:

	<dl dfn-for=alignment-baseline dfn-type=value>
		<dt><dfn>baseline</dfn>
		<dd>
			Use the <a>dominant baseline</a> choice of the parent.
			Match the box's corresponding baseline to that of its parent.

		<dt><dfn>text-bottom</dfn>
		<dd>
			Match the bottom of the box to the bottom of the parent's content area.

		<dt><dfn>alphabetic</dfn>
		<dd>
			Match the box's alphabetic baseline to that of its parent.

		<dt><dfn>ideographic</dfn>
		<dd>
			Match the box's ideographic character face under-side baseline to that of its parent.

		<dt><dfn>middle</dfn>
		<dd>
			Align the vertical midpoint of the box with
			the baseline of the parent box plus half the x-height of the parent.

		<dt><dfn>central</dfn>
		<dd>
			Match the box's central baseline to the central baseline of its parent.

		<dt><dfn>mathematical</dfn>
		<dd>
			Match the box's mathematical baseline to that of its parent.

		<dt><dfn>text-top</dfn>
		<dd>
			Match the top of the box to the top of the parent's content area.
	</dl>

	For the purposes of transverse alignment within a line box,
	an [=atomic inline=] that has no [=baseline sets=]
	uses baselines [=synthesize baseline|synthesized=]
	from its [=margin box=].

	For the following definitions, the <a>alignment subtree</a>
	is as defined in [[!CSS2]].

	<dl dfn-for=alignment-baseline dfn-type=value>
		<dt><dfn>top</dfn>
		<dd>
			Align the top of the aligned subtree with the top 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 bottom of the aligned subtree with the bottom of the line box.
	</dl>

	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">
Alignment Shift: the 'baseline-shift' longhand</h4>

	<pre class="propdef">
	Name: baseline-shift
	Value: <<length-percentage>> | sub | super
	Initial: 0
	Applies to: inline-level boxes, flex items, grid items
	<!-- table cells left out b/c CSS2.1 vertical-align values must have no effect... -->
	Inherited: no
	Percentages: refer to the used value of 'line-height'
	Computed value: the specified keyword and/or a computed <<length-percentage>> value
	</pre>

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

	<p class="advisement">
		Authors should use the 'vertical-align' shorthand instead of this property.

	Values have the following meanings:

	<dl dfn-for="baseline-shift" 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 should use the parent’s font data to find this offset whenever possible.)

		<dt><dfn>super</dfn>
		<dd>Raise by the offset appropriate for superscripts of the parent’s box.
		(The UA should use the parent’s font data to find this offset whenever possible.)
	</dl>

	<p>User agents <em>may</em> additionally support the keyword <dfn for=baseline-shift>baseline</dfn>
	as computing to ''0''
	if is necessary for them to support legacy SVG content.

	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.

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


	As described in the section on <a href="https://www.w3.org/TR/CSS2/visuren.html#inline-formatting">inline formatting contexts</a> [[CSS2/visuren#inline-formatting]],
	user agents flow inline-level boxes into a vertical stack of [=line boxes=].
	The height of a line box is determined as follows:

	<ol>
		<li>
			The height of each [=inline-level box=] in the line box is calculated.
			For replaced elements, inline-block elements, and inline-table elements,
			this is the height of their [=margin box=];
			for [=inline boxes=], this is their 'line-height'.

		<li>
			The inline-level boxes are aligned vertically
			according to their 'vertical-align' property.

			In case they are aligned ''top'' or ''bottom'',
			they must be aligned so as to minimize the line box height.
			If such boxes are tall enough,
			there are multiple solutions
			and CSS&nbsp;2 does not define the position of the line box's baseline
			(i.e., the position of the [=strut=]).

		<li>
			The line box height is the distance between
			the uppermost box top and the lowermost box bottom.
			(This includes the [=strut=],
			as explained under 'line-height' below.)
	</ol>

	Empty inline elements generate empty inline boxes,
	but these boxes still have margins, padding, borders, and a line height,
	and thus influence these calculations just like elements with content.

<h4 id="leading">Leading and half-leading</h4>

	CSS assumes that every font has font metrics
	that specify a characteristic height above the baseline and a depth below it.
	In this section we use <var>A</var> to mean that height
	(for a given font at a given size)
	and <var>D</var> the depth.
	We also define <var>AD</var> = <var>A</var> + <var>D</var>,
	the distance from the top to the bottom.
	(See the note below for <a href="#sTypoAscender">how to find <var>A</var> and <var>D</var> for TrueType and OpenType fonts.</a>)
	Note that these are metrics of the font as a whole
	and need not correspond to the ascender and descender of any individual glyph.

	The User Agent must align the glyphs in a non-replaced inline box
	to each other by their relevant baselines.
	Then, for each glyph,
	determine the <var>A</var> and <var>D</var>.
	Note that glyphs in a single element
	may come from different fonts
	and thus need not all have the same <var>A</var> and <var>D</var>.
	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 <var>A</var> and <var>D</var> of the element's first available font.

	<p id="inline-box-height">When the value of the 'line-height' property
	is something other than ''line-height/normal'',
	determine the leading <var>L</var> to add,
	where <var>L</var> = 'line-height' - <var>AD</var> of the first available font.
	Half the leading 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 a total height above the baseline of
	<var>A'</var> = <var>A</var> + <var>L</var>/2,
	and a total depth of <var>D'</var> = <var>D</var> + <var>L</var>/2.
	Glyphs from fonts other than the first available font
	do not impact the height or baseline of the inline box
	for 'line-height' values other than ''line-height/normal''.

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

	Boxes of child elements do not influence this height.

	When the value of the 'line-height' property is ''line-height/normal'',
	the height of the inline box encloses all glyphs,
	going from the highest <var>A</var> to the deepest <var>D</var>.

	User Agents may use different sets of font metrics
	when determining <var>A</var> and <var>D</var>
	depending on whether the 'line-height' property is
	''line-height/normal'' or some other value,
	for instance taking external leading metrics into account
	only in the ''line-height/normal'' case.

	Although margins, borders, and padding of non-replaced elements
	do not enter into the line box calculation,
	they are still rendered around inline boxes.
	This means that if the height specified by 'line-height'
	is less than the content height of contained boxes,
	backgrounds and colors of padding and borders may "bleed" into adjoining line boxes.
	User agents should render the boxes in document order.
	This will cause the borders on subsequent lines
	to paint over the borders and text of previous lines.

	Note: CSS&nbsp;2 does not define what the content area of an inline box is
	(see [[#line-fill]])
	and thus different UAs may draw the backgrounds and borders in different places.

	<p class=note id=sTypoAscender>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
	for <var>A</var> and <var>D</var>
	(after scaling to the current element's font size).
	In the absence of these metrics,
	the "Ascent" and "Descent" metrics from the HHEA table should be used.

	<pre class="propdef">
	Name: line-height
	Value: normal | <<number>> | <<length-percentage>>
	Initial: normal
	Applies to: inline boxes
	Inherited: yes
	Percentages: computed relative to ''1em''
	Computed value: the specified keyword, a number, or a computed <<length>> value
	</pre>

	On a [=block container=] whose content is composed of [=inline-level boxes=],
	'line-height' specifies the <em>minimal</em> height of line boxes within the element.
	The minimum height consists of
	a minimum height above the baseline
	and a minimum depth below it,
	exactly as if each line box starts with a zero-width inline box
	with the element's font and line height properties.
	We call that imaginary box a <dfn>strut</dfn>.
	(The name is inspired by TeX.).

	The height and depth of the font
	above and below the baseline
	are assumed to be metrics that are contained in the font.

	On a non-replaced [=inline box=],
	'line-height' specifies the height that is used
	in the calculation of the [=line box=] height.

	Values for this property have the following meanings:

	<dl dfn-for=line-height dfn-type=value>
		<dt><dfn>normal</dfn>
		<dd>
			Tells user agents to determine the height of the inline box automatically
			based on font metrics.
			See above for details.

		<dt><dfn><<length>></dfn>
		<dd>
			The specified length is used in the calculation of the line box height.
			Negative values are illegal.

		<dt><dfn><<number>></dfn>
		<dd>
			The used value of the property is this number
			multiplied by the element's font size.
			Negative values are illegal.
			The [=computed value=] is the same as the [=specified value=].

		<dt><dfn><<percentage>></dfn>
		<dd>
			The [=computed value=] of the property
			is this percentage multiplied by the element's computed 'font-size'.
			Negative values are illegal.
	</dl>

	<div class="example">
		The three rules in the example below have the same resultant 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>
	</div>

	Note: When there is only one value of 'line-height'
	(other than ''line-height/normal'')
	for all inline boxes in a block container box
	and they all use the same first available font
	(and there are no replaced elements, inline-block elements, etc.),
	the above will ensure that baselines of successive lines
	are exactly 'line-height' apart.
	This is important when columns of text in different fonts have to be aligned,
	for example in a table.

	ISSUE: The fact that percentages compute to lengths is annoying.
	See also 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>.

<h3 id="line-sizing-property">
Line Sizing Containment: the 'line-sizing' property</h3>

	<pre class="propdef">
	Name: line-sizing
	Value: legacy | normal
	Initial: legacy
	Applies to: inline boxes
	Inherited: yes
	Percentages: N/A
	Computed value: the specified keyword
	</pre>

	ISSUE: This is a rough draft of a proposal, and has not yet been approved by the CSSWG.
	See discussion in <a href="https://github.com/w3c/csswg-drafts/issues/3199">Issue 3199</a>, <a href="https://lists.w3.org/Archives/Public/www-style/2011Mar/0364.html">Hyatt's message</a>, and <a href="https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking">dbaron's proposal</a>.

	This property controls the method by which line boxes are sized,
	and thus the spacing between lines of text.

	Values have the following meanings:

	<dl dfn-for=line-sizing dfn-type=value>
		<dt><dfn>legacy</dfn>
		<dd>
			The inline box contributes to the sizing of its line box
			based on its 'line-height',
			rather than based on its box edges,
			as defined in [[!CSS2]].
			In Quirks Mode [[!QUIRKS]],
			any <a>inline box</a> <a lt="box fragment">fragment</a>
			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.

			Note: In this model, vertical rhythm is broken
			any time there is a change in font metrics within a paragraph.

		<dt><dfn>normal</dfn>
		<dd>
			The inline box contributes to the sizing of its line box
			based on its <a>margin box</a>,
			rather than its 'line-height'.
			Half-leading is inserted inside the <a>content box</a> edges,
			rather than overlapping the padding/border/margin areas.
			However, positive half-leading is only applied to the <a>root inline box</a>.
			Negative half-leading is applied to all inline boxes,-
			reducing the size of the <a>content box</a> as needed.

			Note: This will give consistent line spacing
			as long as there is some amount of leading added,
			such that the half-leading on the root inline
			is large enough to accommodate the unleaded ascent/descent of its descendants.
			The line box will grow, however, to accommodate
			content that would otherwise overflow,
			to avoid overlap between lines.
	</dl>

	ISSUE: Should this property apply to block containers or to inline boxes?
	In the latter case, an individual inline could say "pay attention to me"
	or "don't pay attention to me".

<h3 id="leading-trim-property">
Leading Control: the 'leading-trim-over' and 'leading-trim-under' properties and 'leading-trim' shorthand</h3>

	ISSUE: This is a rough draft of a proposal,
	and is likely to 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.
	Do not implement (yet).
	The CSSWG particularly invites feedback on
	which font metrics need corresponding keyword values.

	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.
	In addition, the ascend and descent font metrics themselves
	include extra space above and below the most common glyph sizes
	in order to accommodate occasional characters and diacritics
	which ascend or descend beyond the typical bounds.
	This prevents subsequent 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 'leading-trim' properties allow controlling the spacing above and below
	the first and last lines of a block.
	It allows precise control over spacing;
	moreover, by relying on font metrics rather than hard-coded lengths,
	it allows content to be resized, rewrapped, and rendered in a variety of fonts
	while maintaining that 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 'leading-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>

	<pre class="propdef">
	Name: leading-trim-over
	Value: normal | text | cap | ex | ideographic | ideographic-ink
	Initial: normal
	Applies to: block containers
	Inherited: no
	Percentages: N/A
	Computed value: the specified keyword
	</pre>

	The 'leading-trim-over' property trims
	the <a>line-over</a> side of the first line box in the block container
	to better match the box’s content edge to its text content.
	The property affects only the <a>first formatted line</a> of the block container;
	if there is no such line, it has no effect.
	Values have the following meanings:

	<dl dfn-for="leading-trim-over, leading-trim" dfn-type=value>
		<dt><dfn>normal</dfn>
		<dd>
			Half-leading is applied over the first line,
			just as for every other line.

		<dt><dfn>text</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the text-top metric
			of the root inline box.

		<dt><dfn>cap</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the cap-height metric
			of the root inline box.

		<dt><dfn>ex</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the ex-height metric
			of the root inline box.

		<dt><dfn>ideographic</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the ideographic top (<code>idtp</code>) metric
			of the root inline box.

		<dt><dfn>ideographic-ink</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the ideographic character face top (<code>icft</code>) metric
			of the root inline box.
	</dl>

	<pre class="propdef">
	Name: leading-trim-under
	Value: normal | text | alphabetic | ideographic | ideographic-ink
	Initial: normal
	Applies to: block containers
	Inherited: yes
	Percentages: N/A
	Computed value: the specified keyword
	</pre>

	The 'leading-trim-over' property trims
	the <a>line-over</a> side of the first line box in the block container
	to better match the box’s content edge to its text content.
	The property affects only the <a>first formatted line</a> of the block container;
	if there is no such line, it has no effect.
	Values have the following meanings:

	<dl dfn-for="leading-trim-under" dfn-type=value>
		<dt><dfn>normal</dfn>
		<dd>
			Half-leading is applied over the first line,
			just as for every other line.

		<dt><dfn>text</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the text-top metric
			of the root inline box.

		<dt><dfn>alphabetic</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the alphabetic baseline metric
			of the root inline box.

		<dt><dfn>ideographic</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the ideographic bottom (<code>ideo</code>) metric
			of the root inline box.

		<dt><dfn>ideographic-ink</dfn>
		<dd>
			Half-leading is not applied over the first line;
			the top of the line box is set to
			the ideographic character face top (<code>icfb</code>) metric
			of the root inline box.
	</dl>

	<pre class="propdef">
	Name: leading-trim
	Value: normal | text | cap | ex | ideographic | ideographic-ink
	Initial: normal
	Applies to: block containers
	Inherited: no
	Percentages: N/A
	Computed value: the specified keyword
	</pre>

	This property is a <a>shorthand</a> of 'leading-trim-over' and 'leading-trim-under'.
	If ''leading-trim/cap'' or ''leading-trim/ex'' is specified,
	'leading-trim-over' is set to that value
	and 'leading-trim-under' is set to ''leading-trim-under/alphabetic'';
	otherwise both <a>longhands</a> are set to the specified keyword.

<h2 id="inline-box-dimensions">
Drawing Inline Boxes</h2>

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

	<pre class="propdef">
	Name: inline-sizing
	Value: normal | stretch
	Initial: normal
	Applies to: <a>inline boxes</a>
	Inherited: no
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

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

	<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 position to fit its (possibly hypothetical) text
			as specified in <a href="https://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced">CSS2&sect;10.6.1</a>.

		<dt><dfn>stretch</dfn>
		<dd>
			Once the line box has been sized,
			the final <a>logical height</a> of the <a>inline box</a>’s <a>content area</a>
			is calculated as the <a>stretch fit</a>
			into the line box,
			and it is positioned such that its <a>margin edges</a>
			coincide with the line box’s edges.
	</dl>

	Issue: We might want to use this opportunity to more precisely define ''inline-sizing/normal'',
	rename it to match,
	and possibly introduce any other values that may seem necessary.

	The 'height' property does not apply.
	The height of the content area should be based on the font,
	but this specification does not specify how.
	A UA may, e.g., use the 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.)

	The vertical padding, border and margin of an inline, non-replaced box
	start at the top and bottom of the content area,
	and has nothing to do with the 'line-height'.
	But only the 'line-height' is used when calculating
	the height of the line box.

	If more than one font is used
	(this could happen when glyphs are found in different fonts),
	the height of the content area is not affected
	by the glyphs from the fallback fonts,
	and only depends on the first available font.

<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 Arabic and 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-letters formatting to replaced elements or multiple words
	can alternately apply the 'initial-letters' property to the first inline-level child of a block container.

	<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-letters: 2; }
	</pre>
	</div>

	Note that
	since ''::first-letter'' selects punctuation before or after the first letter,
	these characters are included in the initial-letters 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-letters' property</h3>

	<pre class="propdef">
	Name: <dfn id="propdef-initial-letters">initial-letters</dfn>
	Value: normal | <<number>> <<integer>> | <<number>> && [ 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-letters/normal'' or a number paired with an integer
	Animation type: by computed value type
	</pre>

	ISSUE: Renaming this property (and the others in this section)
	is currently <a href="https://github.com/w3c/csswg-drafts/issues/2950">under discussion</a>.

	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-letters: 2; }</pre>
	</div>

	It takes the following values:

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

		<dt><dfn><<number>></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>></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-letters/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-letters' usage:

		<dl>
			<dt>''initial-letters: 3''
			<dt>''initial-letters: 3 3''
			<dt>''initial-letters: 3 drop''
			<dt>''initial-letters: 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-letters: 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-letters: 3 1''
			<dt>''initial-letters: 3 raise''
			<dt>''initial-letters: 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-letters: 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 bottom 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-letters'' can be used to create
		“adjacent initial letters,” where the initial letter is adjacent to the text:

		<pre>
			p::first-letter {
				initial-letters: 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-letters' property applies not just
	to the CSS-defined ''::first-letter'' pseudo-element,
	but also to
	''list-style-position/inside''-positioned ''::marker'' pseudo-elements and
	inline-level boxes
	that are placed at the start of the first line.
	Specifically, 'initial-letters' applies to
	any <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-letters' value
	of ''initial-letters/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-letters: 2; }
			b, strong { initial-letters: 3; }
		</pre>

		The 'initial-letters' 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-letters' 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-letters/normal'',
	and it is not formatted as an <a>initial letter</a>.

	The effect of the 'initial-letters' property is undefined
	on children of <a>ruby</a> base container boxes
	and on <a>ruby</a> container boxes.

	Note: The 'initial-letters' 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-letters-align' property</h3>

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

	<pre class="propdef" id="initial-letters-align">
	Name: <dfn id="propdef-initial-letters-align">initial-letters-align</dfn>
	Value: border-box? [ alphabetic | ideographic | hebrew | hanging ] | border-box
	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 surrounding text.

	Values have the following meanings:

	<dl dfn-type="value" dfn-for="initial-letters-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 character face top and bottom edge baselines of the surrounding text
			to align the <a>initial letter</a>.

		<dt><dfn>hebrew</dfn>
		<dd>
			Use the Hebrew top and alphabetic baseline 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>border-box</dfn>
		<dd>
			Use the <a>initial letter box</a>’s <a>line-under</a> and <a>line-over</a> border edges
			as the <a>over</a> and <a>under</a> alignment points, respectively.
	</dl>

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

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

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



	<div class="example">
		Initial letter in Hebrew
		<pre>
			span.initial {
			initial-letters: 2;
			initial-letters-align: hebrew;
			}
		</pre>
		<img src="images/hebrew-initial-letter.png" width="480"
		     alt="optical kerning in the presence or absence of a space after the initial letter">
	</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 from the Han, Hangul, Kana, or Yi <a>Unicode scripts</a>,
			use the ideographic character face top and bottom edge baselines.

			<li>Else if the <a>initial letter</a>
			contains any character from the Devanagari, Bengali, and Gurmukhi <a>Unicode scripts</a>,
			use the hanging and alphabetic baselines.

			<li>Else if the <a>initial letter</a>
			contains any character from the Hebrew <a>Unicode scripts</a>,
			use the Hebrew top and alphabetic baselines.

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

	Issue: What is the proper alignment for South Asian scripts
	that do not have the explicit hanging baseline, such as Tamil or Telugu?
	See GitHub issue <a href="https://github.com/w3c/csswg-drafts/issues/864">864</a>

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

<h4 id="initial-letter-align-defaults">
UA Default Stylesheet for 'initial-letters-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-letters-align: ideographic;
		}
		[lang]:lang(iw, yi, lad, jrb) {
		  initial-letters-align: hebrew;
		}
		[lang]:lang(hi, mr, ne, pi, kok, brx, mai, sd, sa) {
		  initial-letters-align: hanging;
		}
		/* Script tags override language tags */
		[lang]:lang('*-Latn', '*-Cyrl') {
		  initial-letters-align: alphabetic;
		}
		[lang]:lang('*-Hani', '*-Hant', '*-Hans') {
		  initial-letters-align: ideographic;
		}
	</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-sizing', 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-letters-align' is ''initial-letters-align/border-box'',
	its vertical alignment and sizing are not affected;
	however the effective exclusion area is
	(and corresponds to the margin area).

	ISSUE: Reword that to handle 'box-sizing' correctly.

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

<h3 id="sizing-initial-letters">
Font Sizing of Initial Letters</h3>

	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-letters')
	as anchored by its specified alignment points (see 'initial-letters-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: What about inheritance to descendants?

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

	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>

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

	When 'initial-letters' is not ''initial-letters/normal'',
	shaping <em>should</em> still occur across
	an <a>inline initial letter box</a>'s boundaries.
	(See [[css-text-3#boundary-shaping]].)
	For example, if the first letter of the Farsi word “پس”
	were styled with ''initial-letters: 2 1'',
	both letters would be styled in their joined forms,
	with initial-form “ﭘ” as the <a>initial letter</a>,
	followed by the normally-styled final-form “ﺲ”.
	Note that the two letters might not always graphically connect,
	even when shaped in their joining forms.

	Issue: Are there other things we need to consider here?

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

	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 is sized and positioned to coincide with
	the smallest rectangle that would include
	the bounding boxes of all its glyphs--
	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.

	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-exclusions">
Space Below Initial Letters</h4>

	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 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 bounding boxes
	of an <a>initial letter</a> are excluded,
	not just those within range of the <a>initial letter sink</a>.
	Specifically, for non-atomic initial letters,
	the content box of the element is sized to fit:

	<ul>
		<li>The specified amount of sink
		(i.e the distance from the top alignment point to the bottom alignment point).

		<li>The actual ascent and descent and side bearings of all the glyphs it contains
		that are part of its inline formatting context,
		even if they leak outside their em boxes.

		<li>The margin boxes of all the atomic inlines it contains
		that are part of its inline formatting context,
		even if they leak outside its own line-height.
	</ul>

	The initial letter is then made an exclusion area,
	the same as if it were a float.
	See 'initial-letters-wrap' for details.

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

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

	In the <a>block axis</a>, the <a>initial letter</a> is positioned
	as required to satisfy its <a>under</a> alignment point ('initial-letters-align')
	at its specified [=initial letter sink|sink=] ('initial-letters'),
	i.e. it is positioned
	such that it would sink the number of lines
	specified by 'initial-letters'’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>.

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

	Its position is anchored with respect to the line on which it occurs.

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

	In the <a>inline axis</a>, the position of the inline letter
	is given by matching its <a>inline-start</a> <a>margin edge</a>
	with the <a>inline-start</a> edge of the line box.

	However, if the <a>initial letter</a> is a non-atomic inline
	with an [=automatic size|automatic=] [=inline size=] and
	zero padding and borders,
	it is negatively offset
	by the distance from the start edge of its content box
	to the point in the content that would have been placed
	at the start edge of the containing block
	if it were not an <a>initial letter</a>
	(i.e. the distance between its glyph bounding box
	and its start side bearing).

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

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

	<pre class="propdef">
	Name: <dfn id="propdef-initial-letters-wrap">initial-letters-wrap</dfn>
	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 follow the contour of its end-edge glyph outline.

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

		<dt><dfn>first</dfn>
		<dd>
			Behaves as ''initial-letters-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 ''all''
			on the first line of the block containing the initial letter
			and as ''initial-letters-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-letters-wrap/first''?
			(I.e. Should we rename this value to ''initial-letters-wrap/auto'' and add a ''initial-letters-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 touches the ink of the initial letter,
			plus the amount of the <a>initial letter</a>’s end-side border+padding+margin.

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

			Note: This value is at-risk.

		<dt><dfn>grid</dfn>
		<dd>
			This value is the same as ''initial-letters-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-letters-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-letters-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-letters-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-letters: 3; /* 3-line drop-cap */
						initial-letters-wrap: first;
						margin-right: 0.1em;
					}
					@supports (not (initial-letters-wrap: first)) {
						/* Classes auto-generated on paragraphs to match first letter. */
						p.A:first-letter {
							initial-letters-wrap: -40%; /* Start of glyph outline, assuming correct font. */
						}
					}
				</pre>
			</div>

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

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

	<div class="example">
		<pre>
			p::first-letter {
			  initial-letters: 3;
			  initial-letters-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-letters: 3;
			  initial-letters-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-letters: 3;
			  initial-letters-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-letters: 3;
			  initial-letters-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.
	Aside from vertical alignment,
	its interaction with the rest of the contents of the line is as normal,
	except in a few specific circumstances&hellip;

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

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

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

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

	In addition, to ensure consistent alignment of all the impacted lines,
	any 'letter-spacing' or <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 the first line of text as normal in the presence of initial letters.
	Lines affected by the exclusion are shortened, as in the presence of floats,
	and are affected the same way.

	<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-letters' and 'hanging-punctuation'
	is <a href="hhttps://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-letters: 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="intial-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-fonts">
	A.1: 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>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 maqaf (U+05B3 “־”)
					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 a heuristic for the script
		<dd>
			Issue: What does this mean?

		<dt>Use fallback values
		<dd>
			The following fallback values
			<ul>
				<li>x-height: .5em;
				<li>cap-height: .66em;
				<li>hanging baseline: .6em;
				<li>Hebrew hanging baseline: ???
			</ul>
	</ol>

<h3 class="no-num" id="baseline-synthesis-replaced">
A.2: Synthesizing Baselines for Replaced Content</h3>

	Issue: Copy over text from <a href="https://www.w3.org/TR/css-writing-modes-3/#replaced-baselines">CSS Writing Modes</a>
	and expand for additional baseline values.

	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/2018/WD-css-inline-3-20180808/">8 August 2018 Working Draft</a>
	include:

	<ul>
		<li>
			Added 'line-sizing' property to control how inter-line spacing is calculated.
			(<a href="https://github.com/w3c/csswg-drafts/issues/3199">Issue 3199</a>)
	</ul>

	Changes since the
	<a href="https://www.w3.org/TR/2016/WD-css-inline-3-20160524/">24 May 2016 Working Draft</a>
	include:

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

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