CSSインラインレイアウトモジュール レベル3

1. はじめに

このモジュールは、インラインレイアウトを定義します。 これはCSSにおける、テキストとインラインレベルボックスの混在ストリームをレイアウトするモデルです。 また、この内容を各行内でブロック軸に沿って整列・サイズ指定するための制御方法も定義します。 さらに、ドロップキャップや類似の頭文字スタイリング用の特別なレイアウトモードも追加しています。

注: 行分割、均等割付、その他インライン軸でのインラインレベルコンテンツの位置決めは、CSS Text Moduleで扱われます。

ここでのレイアウトの多くはフォントメトリクスに依存しています。 関連するメトリクスはOpenTypeではラテン・キリル・ギリシャ文字やCJK向けには存在しますが、他の多くの書記体系では不足しています。 例えば、ヘブライ語の視覚的な上端メトリクスはOpenTypeテーブルに存在しません。 このモジュールが世界中で適切に機能するには、すべての書記体系について適切なメトリクスをフォントが提供する必要があります。そのためにはOpenTypeがそのようなメトリクスを許容する必要があり、フォントデザイナーが正確な数値を提供しなければなりません。 詳細は課題やリエゾン声明を参照してください。

1.1. モジュール間の関係

このモジュールは、[CSS2] の10.8節で定義されているCSSインラインレイアウトモデルと機能を置き換え・拡張します。

1.2. 値の定義

本仕様はCSSプロパティ定義の慣例を[CSS2]から継承し、値定義構文は[CSS-VALUES-3]に従っています。 この仕様で定義されていない値型はCSS Values & Units [CSS-VALUES-3]で定義されます。 他のCSSモジュールとの組み合わせによって、これらの値型の定義が拡張される場合もあります。

各プロパティ定義に記載された値以外にも、本仕様で定義されるすべてのプロパティは、 CSS全域キーワードを値として受け付けます。 可読性のため、明示的には繰り返していません。

2. インライン レイアウトモデル

インラインレイアウトでは、 テキストとインラインレベルボックスが混在し再帰的に流れるストリームが、インライン整形コンテキストを形成し、ブロックコンテナー内で、 断片化によって行ボックスのスタックへとレイアウトされます。 各行ボックス内では、インラインレベルボックスが互いに整列され、ブロック軸に沿って配置されます。 通常はそのテキストのベースラインに基づいて整列されます。

任意のブロックコンテナーが直接インラインレベルコンテンツ （たとえばインラインボックス、アトミックインライン、テキストシーケンスなど）を含む場合、 インライン整形コンテキストを確立し、 インラインレイアウトで内容をレイアウトします。 ブロックコンテナーの内容エッジは、 そのインラインレベルボックスの包含ブロックとなります。

ブロックコンテナーは、 ルートインラインボックスも生成します。 これは匿名のインラインボックスで、 すべてのインラインレベルコンテンツを保持します。 （つまり、インライン整形コンテキスト内の全テキストは、 インラインボックスによって直接保持されます。 それがルートインラインボックスか、子孫ボックスかは問いません。） ルートインラインボックスは親のブロックコンテナーから継承しますが、それ以外のスタイルは適用できません。

インライン整形コンテキストでは、 コンテンツはインライン軸に沿ってレイアウトされ、 Unicode双方向アルゴリズムとその制御 [CSS-WRITING-MODES-3] に従って順序付けされ、[CSS-TEXT-3]の組版制御に従って分配されます。 インライン軸のマージン、ボーダー、パディングは、 インラインレベルボックス間で尊重され、そのマージンは折り畳みされません。 こうして、インラインレベルコンテンツの1行分のボックスを含む矩形領域が行ボックスと呼ばれます。

注: 行ボックス、インラインボックス、インラインレベルボックスはそれぞれ異なる概念です！ 詳しくは[CSS-DISPLAY-3]でボックス型と関連用語について解説しています。

2.1. 行ボックスのレイアウト

行ボックスは、 インラインレベルコンテンツを インライン整形コンテキスト内で保持するために必要に応じて作成されます。 インラインボックスが行ボックスの論理幅を超える場合や、 強制改行を含む場合は、 （CSS Text 3 § 5 行分割と単語境界参照） 複数の断片 [CSS-BREAK-3]に分割され、 複数の行ボックスに分配されます。 マルチカラムレイアウト [CSS-MULTICOL-1]のカラムボックスのように、 行ボックスは断片化コンテナーとして、 整形コンテキストによって生成され、 CSSのボックスツリーの一部ではありません。

注: インラインボックスは、双方向テキスト処理により同じ行ボックス内で複数の断片に分割されることもあります。 [CSS-WRITING-MODES-3]参照。

行ボックスは、 ブロックコンテナーボックスの直接内容として ブロックフロー方向に積み重ねられ、 align-content [CSS-ALIGN-3]で指定された方法でコンテナー内に整列されます。 したがって、インライン整形コンテキストは、 行ボックスのスタックで構成されます。 行ボックスは原則として分離なしに積み重ねられます （他の場所で指定された場合を除く、 例：フロートやクリアランスなど） また、決して重なりません。

一般的に、 line-left端は、行ボックスの line-left端がその包含ブロックの端に接し、 line-right端が line-right端に接します。 したがって、行ボックスの論理幅は、 内側の論理幅と等しくなります（包含ブロック、すなわちブロックコンテナーの内容ボックス）。 ただし、フロートボックスや頭文字ボックスが 包含ブロック端と行ボックス端の間に来る場合は、 その分だけ利用可能なスペース、つまり論理幅が減少します。 （CSS2.1 § visuren#inline-formattingやCSS2.1 § visuren#floats、§ 7 頭文字も参照。）

論理高さは、行ボックスの内容がブロック軸整列された後に合わせて決定されます。 この調整はline-heightやline-fit-edgeで制御されます。 ブロックコンテナーの最初／最後の行ボックスは、さらにtext-box-trimでトリムされる場合があります。

2.2. 行ボックス内のレイアウト

上記参照の通り、 ユーザーエージェントはインラインレベルボックスを行ボックスのスタックに流し込みます。 各行ボックス内のレイアウトは、 各ボックス断片と行ボックスごとに個別にサイズ指定・位置決めされ、以下の通りです：

1. ベースライン整列: インフローのインラインレベルボックスは、行ボックス内でブロック軸に沿って互いに整列されます。 dominant-baselineやvertical-alignによって整列されます。 これをベースライン整列と呼びます。 line-relative値でbaseline-shiftを指定したものは、行ボックスの高さが最小になるように整列されるものとします。

2. コンテンツサイズ寄与の計算: 各インラインレベルボックスのレイアウト境界（サイズ寄与）を計算します：

   • アトミックインライン（置換要素やインラインブロックなど）の場合： これはそのmargin boxです。
   • ルートインラインボックスや、 line-fit-edge: leadingを持つインラインボックスの場合： 使用されたline-heightから導出されます（margin/border/paddingは無視）。 詳しくは§ 5.3 インラインボックスの論理高さ（レイアウト境界）の計算参照。
   • その他のインラインボックスの場合： line-fit-edgeメトリクスから導出され、margin/border/paddingを含みます。 詳しくは§ 5.3 インラインボックスの論理高さ（レイアウト境界）の計算参照。

3. 行ボックスのサイズ指定: 行ボックスの論理高さは、 すべての整列されたレイアウト境界を正確に含むようにサイズ指定されます。

4. コンテンツの位置決め: ルートインラインボックスの整列サブツリーとline-relative値でbaseline-shiftを指定したボックスは、行ボックス内で位置決めされます。

   他のコンテンツより高いtop/bottom/center整列ボックスの扱いを定義する必要があります。

注: 空のインラインボックスも margin、padding、border、line-heightを持ち、 内容があるボックス同様にこれらの計算に影響します。

2.3. 幻想行ボックス

行ボックスにテキストが無く、 保存された空白も無く、 インライン軸に非ゼロのmargin、padding、borderを持つインラインボックスも無く、 他のインフローコンテンツ （アトミックインラインやルビ注釈など）も無く、 最後が強制改行で終わらないものは、 幻想行ボックスです。 これらのボックスは、子孫コンテンツ（例：絶対位置指定ボックスなど）の位置決定用途ではゼロ高さの行ボックスとして扱い、 それ以外のレイアウトや描画用途では、行ボックスおよびそのインフローコンテンツは存在しないものとして扱います。

Firefoxでは幻想行ボックス内のインラインボックスにoutlineを適用でき、フォーカスリングを表示できます。 他のブラウザ同様、要素を可視化する他のプロパティ（例：box-shadow） は無視されるようです。

2.4. 描画順序

positioned box（詳細は[CSS-POSITION-3]）に特別な指定がある場合を除き、インラインレベルボックスは文書順で描画されます。 z-indexプロパティは一般的には適用されません。

3. ベースラインと整列メトリクス

3.1. ベースラインの概要

ベースラインは、インライン軸に沿った行ボックス上の線であり、テキストの個々のグリフがこの線に整列されます。ベースラインはフォントのグリフデザインの基準となります （例えば、ほとんどのアルファベットグリフの下端はアルファベットベースラインに揃えられます）、 また、異なるフォントやフォントサイズのグリフを組版する際の整列にも利用されます。

書記体系によって、好まれるベースラインは異なります。

よく設計されたフォントには、ベースラインテーブルが含まれ、 フォント設計座標空間における1つ以上のベースラインの位置を示します。 （設計座標空間はフォントサイズに合わせてスケールされます。）

ベースラインテーブルはフォントのプロパティであり、 複数のベースラインの位置はフォント内のすべてのグリフに適用されます。

異なるベースラインテーブルは、 横書き・縦書きそれぞれの整列用に提供できます。 UAは縦書き組版モードでは縦用テーブルを、 それ以外では横用テーブルを使うべきです。

注: フォントは各軸ごとに複数のベースラインテーブルを持つことができます。 UAはfont-language-overrideやコンテンツの言語を考慮して適切なテーブルを選択する責任があります。

3.2. ベースラインとメトリクス

CSSは、整列・ボックスサイズ指定・頭文字レイアウトなど、インラインレイアウトの機能において、以下のテキストベースのメトリクスをベースラインとして使用します。

CSSWGは、各プロパティ（dominant-baseline、alignment-baseline、text-box-edge、line-fit-edge、initial-letter-align）ごとに、どのベースライン値が必要か、不要なもの・追加すべきものがあるか知りたいと考えています。 Issue 859参照。

alphabetic

ラテン・キリル・ギリシャなど多くの書記体系で使われる。 多くの（すべてではない）文字の下端（“m”, “Ш”, “Δ”など）に対応。 フォント設計座標系でゼロとして表されることが多い。 OpenTypeではromn、TrueType AATではbsln値ゼロとして割り当て。

cap-height

ラテン・キリル・ギリシャなどの大文字（“T”、 “Б”、 “Σ”など）の上端に対応。 OpenTypeのsCapHeightで算出。

x-height

ラテン・キリル・ギリシャなどの小文字（“m”、 “л”、 “α”など）の上端に対応。 OpenTypeのsxHeightで算出。

x-middle

alphabeticとx-heightベースラインの中間。

ideographic-over

CJK（漢字・ハングル・かな）テキストのline-over設計端に対応。 OpenTypeではidtpに割り当て。

ideographic-under

CJK（漢字・ハングル・かな）テキストのline-under設計端に対応。 OpenTypeではideoに割り当て。

central

表意文字の中央ベースライン。ideographic-underとideographic-overの中間。 TrueType AATではbsln値1。

ideographic-ink-over

CJK（漢字・ハングル・かな）テキストのline-overインク端に対応。 OpenTypeではicftに割り当て。

ideographic-ink-under

CJK（漢字・ハングル・かな）テキストのline-underインク端に対応。 OpenTypeではicfbに割り当て。

hanging

チベットや類似の単一ケース書記体系で、文字が「ぶら下がっている」ように見える上端の基準線。 OpenTypeではhang、TrueType AATではbsln値3に割り当て。

math

数式文字の設計中心ベースライン。 OpenTypeではmath、TrueType AATではbsln値4。

text-over

line-over端として使われるメトリクス。インラインの内容ボックスに対応。[CSS2]参照。

text-under

line-under端として使われるメトリクス。インラインの内容ボックスに対応。[CSS2]参照。

em-over

1em の距離となるよう正規化された理論的ascentに対応。 A.1: Em-overとEm-underの計算参照。

em-under

1em の距離となるよう正規化された理論的descentに対応。 A.1: Em-overとEm-underの計算参照。

注: これらのメトリクスは光学設計メトリクスであり、必ずしもグリフのアウトラインと完全に一致するわけではありません。

一般的に、これらのメトリクスは適切なフォントから取得しますが、欠落している場合やボックスから導出する必要がある場合は、合成する必要があります。 § 3.3 グリフとボックスのベースラインや付録A：整列メトリクスの合成参照。

3.2.1. アセント・ディセントメトリクス

CSSは、すべてのフォントにベースライン上の特徴的な高さ（アセントメトリクス）と、下側の特徴的な深さ（ディセントメトリクス）があることを仮定し、インライン整形コンテキストにおけるテキストやボックスのレイアウトに使用します。 これらはフォント全体のメトリクスであり、個々のグリフのアセンダーやディセンダーと一致する必要はありません。

注: OpenTypeやTrueTypeフォントを使用する実装では、OS/2テーブルのsTypoAscenderとsTypoDescenderを（現在の要素のフォントサイズにスケール後）CSSレイアウト用のアセントメトリクスとディセントメトリクスとして使うことを推奨します。これらがない場合は、HHEAテーブルの"Ascent"および"Descent"メトリクスを使うべきです。

3.2.2. ラインギャップメトリクス

フォント形式には、フォント推奨の「ラインギャップ」または「外部リーディング」メトリクスを持つ場合があります。 このメトリクスはラインギャップメトリクスと呼び、 行ボックスの論理高さ計算時 line-heightがnormalの場合に組み込まれることがあります（§ 5.3 インラインボックスの論理高さ（レイアウト境界）の計算参照）。

注: OpenTypeではラインギャップメトリクスはsTypoLineGapまたはhhea.lineGapとして見つかります。

UAはラインギャップメトリクスをゼロ以上で切り捨てる必要があります。

3.3. グリフとボックスのベースライン

各フォント・グリフ・インラインレベルボックスは、各ベースラインタイプのベースライン座標を持つと仮定され、そのベースラインが該当するブロック軸上での位置を示します。 それらのベースラインの集合をベースラインセットと呼びます。 このセットから、ボックスまたはグリフを自身の整列コンテキスト内で整列するために使うものが整列ベースライン、 自身の内容を自身内で整列するために使うものが優先ベースラインです。

個々のグリフの場合、 ベースラインセットはフォントのベースラインテーブルから導出されます。 インラインボックスの場合は、 最初に利用可能なフォントから導出され、実際にそのフォントのグリフを含むか否かに関係ありません。 必要なメトリクスがフォントにない場合は、UAが合成する必要があります。 A.2: テキストのベースライン（および他のフォントメトリクス）の合成参照。

その他のボックスについては、 そのベースラインセットは、内容物に従い、 baseline-sourceや、参加している整形コンテキストのルールに従って導出されます。 また、アトミックインラインボックスがインライン整形コンテキストのインライン軸にベースラインセットを持たない場合、 その整列ベースラインは margin boxから合成されます。 詳しくはA.3: アトミックインラインのベースライン合成を参照してください。

4. ベースライン整列

ほとんどのCSS整形コンテキストでは、ボックスをコンテナーの端基準で整列しますが、インラインレイアウトでは、ブロック軸にて、 ボックス同士を互いのベースライン基準で整列します。

より具体的には、 （line-relativeシフト値を使わない場合） 各グリフやインラインレベルボックスは、ブロック軸で 自身の整列ベースラインが 親の対応するベースラインと一致するように位置決めされます （親は整列コンテキスト）。 その後、必要に応じてpost-alignment shift値で位置が調整されます。

注: ベースライン整列は必ず対応するベースライン同士で行います。 alphabeticはalphabetic、hangingはhanging、mathematicalはmathematicalなど。

ボックスを整列する場合、整列ベースラインは alignment-baselineやbaseline-source値（ショートハンドvertical-align参照）によって選択され、 デフォルトでは親のdominant-baselineに一致します。 グリフの場合、整列ベースラインは常に親の優先ベースラインで決定されます。

以下のサンプルマークアップ：

<p><span class="outer">Ap <span class="inner">ਜੀ</span></span></p>

および以下のスタイルルール：

.inner { font-size: 75%; }

親（.outer）と子（.inner）のベースラインセットはフォントサイズの違いにより一致しません。 子ボックスは親とalphabeticベースラインを揃えることで整列されます。

ここではalphabeticベースラインが使われています。 なぜなら、デフォルトでボックスの整列ベースラインは親の優先ベースラインと一致し、 横書きtypographic modeでは 優先ベースライン自体がalphabeticベースラインにデフォルト設定されるためです。

もし上記の.inner要素にvertical-align: superを追加すると、 同じ規則で.inner子要素が親と整列されますが、ベースライン整列に加えて子が上付き位置にシフトされます。

4.1. 支配的ベースライン： dominant-baseline プロパティ

このプロパティは、支配的ベースライン（dominant baseline）を指定します。 これはボックス内のコンテンツを整列する際のデフォルトのベースラインタイプです。

インラインボックスの場合、 支配的ベースラインはボックス内のテキストの整列 （および、vertical-alignで特に指定がなければ、すべてのインラインレベル子ボックス） の整列時に、各グリフ／ボックスの対応するベースラインをボックス自身の支配的ベースラインに揃えるために使われます。 その他のボックスでは、ボックス内で整列ベースラインを用いてベースライン整列に参加するボックスのデフォルト整列ベースラインとなります。 詳しくは（alignment-baseline: baselineや[CSS-ALIGN-3]）を参照してください。

各値の意味は以下の通りです：

auto

alphabetic（横書きモードおよびtext-orientationがsidewaysの縦書きモード）と同等。 縦書きモードでtext-orientationがmixedまたはuprightの場合はcentralと同等。

ただし、SVGテキストの場合は、グリフの原点座標（座標ベース配置に使用）は縦書きモードで常にcentralとして扱います。

text-bottom

text-underベースラインを使用します。

alphabetic

alphabeticベースラインを使用します。

ideographic

ideographic-underベースラインを使用します。

middle

x-middleベースラインを使用します。 ただし、text-orientation: uprightの下では（alphabeticやx-heightベースラインが意味を持たない場合） centralベースラインを使用します。

central

centralベースラインを使用します。

mathematical

mathベースラインを使用します。

hanging

hangingベースラインを使用します。

text-top

text-overベースラインを使用します。

支配的ベースラインの説明は [CSS-WRITING-MODES-3] を参照してください。

指定ベースラインがcentralでない場合に意味不明にならないような混在縦方向の挙動を定義する必要があります。

4.2. 横方向ボックス整列： vertical-align プロパティ

このショートハンドプロパティは、 インラインレベルボックスが行内でどのように整列されるかを 整列ベースラインタイプ（alignment-baseline）、ベースライン整列優先（baseline-source）、 および整列後シフト（baseline-shift） を一括して指定します。

firstやlastが指定された場合は、 baseline-sourceを設定します（それ以外はautoにリセット）。 その他の値は対応するロングハンドプロパティと同様です。詳細は下記参照。

著者はこのショートハンド（vertical-align）を利用し、 ロングハンドを個別にカスケードする必要がある場合や（SVG要素で）レガシーSVG実装をサポートしたい場合以外は、ロングハンドより本プロパティを使うべきです。

注: vertical-alignは align-contentがnormalの場合、テーブルセルの整列にも影響します。 具体的には、top（baseline-shift: top）は start、bottom（baseline-shift: bottom）は end、 その他middle（alignment-baseline: middle） は centerに対応します。 詳しくは CSS Box Alignment 3 § 5.1.1 ブロックコンテナー（テーブルセル含む） を参照してください。

4.2.1. 整列ベースラインソース： baseline-source ロングハンド

インラインレベルボックスが複数のベースライン情報ソースを持つ場合 （たとえば複数行のインラインブロックやインラインフレックスコンテナーなど）、 このプロパティでfirst baseline setかlast baseline setのどちらを整列に優先するかを指定します。 これによりボックスのベースライン整列優先が決まります。 各値の意味は以下の通りです：

auto

last-baseline整列はinline-blockに、その他はfirst-baseline整列に指定します。

first

first-baseline整列を指定します。

last

last-baseline整列を指定します。

インラインボックス以外のボックスのベースラインの求め方は CSS Box Alignment 3 § 9.1 ボックスのベースラインの決定 を参照してください。

4.2.2. 整列ベースラインタイプ： alignment-baseline ロングハンド

このプロパティはボックスの整列ベースラインを指定します。 ベースラインは、（必要なら）整列後シフトを適用する前にボックスを整列する際に利用されます。

値の定義は以下の通りです：

baseline

親の支配的ベースラインの選択を使用します。

text-bottom

text-underベースラインを使用します。

alphabetic

alphabeticベースラインを使用します。

ideographic

ideographic-underベースラインを使用します。

middle

通常はx-middleベースラインを使用します。 ただし、text-orientation: upright（alphabeticやx-heightベースラインが本質的に意味を持たない場合）は、 centralベースラインを使用します。

central

centralベースラインを使用します。

mathematical

mathベースラインを使用します。

text-top

text-overベースラインを使用します。

ベースライン整列を行う際、 これらの値は、ボックスのどのベースラインを 親の対応するベースラインに揃えるかを指定します。 （インライン整形コンテキストでは、インラインレベルボックス断片やグリフは 親インラインボックス断片のインライン軸で確立された整列コンテキストを共有します。 他の整形コンテキストについては CSS Box Alignment 3 § 9.2 ベースライン整列グループ化を参照してください。) SVGテキストレイアウトでは、 これらの値はSVGの現在のテキスト位置に揃えるベースラインを指定します。

4.2.2.1. SVG向けのレガシー値

SVG実装はレガシーコンテンツへの対応のため、次のエイリアスをサポートしてもよいmayです：

• text-before-edgeはtext-topのエイリアス

• text-after-edgeはtext-bottomのエイリアス

4.2.3. 整列後シフト： baseline-shift ロングハンド

このプロパティはボックスの整列後シフト（post-alignment shift）を指定します。 ベースライン相対シフト値である<length-percentage>、sub、superは、ベースライン整列位置から相対的にシフトします。 一方、行相対シフト値であるtop、center、bottomは、 インラインボックスおよびその内容を 行ボックスの境界に対してシフトします。

著者はCSS1以来存在するvertical-alignショートハンドを利用し、 SVGコンテンツ以外ではこのbaseline-shiftロングハンドよりショートハンドを推奨します。 （SVGでは逆にbaseline-shiftの方がレガシーユーザーエージェントで広くサポートされています。）

各値の意味は下記の通りです：

<length>

指定された長さ分だけ上昇（正値）または下降（負値）します。

<percentage>

指定されたパーセンテージ分、line-heightに対して上昇（正値）または下降（負値）します。

sub

親ボックスの下付き文字として適切なオフセット分下降します。 UAは親のフォントメトリクスからこのオフセットを算出してもよいですが、 そうでない場合は親の使用font-sizeの1/5だけ下降します。

super

親ボックスの上付き文字として適切なオフセット分上昇します。 UAは親のフォントメトリクスから算出してもよいですが、 そうでない場合は親の使用font-sizeの1/3だけ上昇します。

top

line-over端に整列サブツリーのline-over端を揃えます。

center

整列サブツリーの中心を行ボックスの中心に揃えます。

bottom

line-under端に整列サブツリーのline-under端を揃えます。

整列サブツリー（aligned subtree）は、 インラインボックスの レイアウト境界と、 すべての子インラインボックスの算出alignment-baseline値が 行相対シフト値でないものの整列サブツリーを含みます。 整列サブツリーのline-over端はサブツリー内のover端の最上部、 line-under端は最下部になります。

行相対シフト値は alignment-baselineとbaseline-shiftの二分法に完全には収まりません。 妥当な議論がどちらにもあります。 現状はここでドラフトされていますが、強い移動提案があれば課題提出をお願いします。

4.2.3.1. SVG向けのレガシー値

ユーザーエージェントは、レガシーSVGコンテンツ対応のため、キーワードbaselineを0に算出することを追加サポートしてもよいmayです。 この値はvertical-alignショートハンドでは許可されません。

baseline値は削除したいと考えており、SVGユーザーエージェントから必要性についてフィードバックを募集しています。

5. 論理的高さと行間隔

ブロック軸での行ボックスのサイズ指定は、その整列やインラインレベル内容のサイズに依存します。 このサイズ指定はline-heightとline-fit-edgeプロパティで制御されます。

5.1. 行間隔： line-heightプロパティ

このプロパティはボックスの希望行間（preferred line height）を指定します。 これは「レイアウト境界」の計算、 つまりボックスが行ボックスの論理的高さに寄与する値の計算に使われます。 （詳細は§ 5.3 インラインボックスの論理高さ（レイアウト境界）の計算を参照。）

注: ルートインラインボックスに対してブロックコンテナーで指定した場合、line-heightはブロックの行ボックスの最小高さを事実上決定します。

このプロパティの各値の意味は以下の通りです：

normal

フォントメトリクスに基づき希望行間を自動決定します。

<length [0,∞]>

指定された長さを希望行間として用います。 負値は不正です。

<number [0,∞]>

希望行間はこの数値に 要素の算出font-sizeを掛けたもの。 負値は不正です。 算出値は指定値と同じ。

<percentage [0,∞]>

このプロパティの希望行間および算出値は 要素の算出font-sizeにこのパーセンテージを掛けた値。 負値は不正です。

注: 最初に利用可能なフォント以外のフォントのメトリクスは、レイアウト境界にのみ影響し、 インラインボックスのline-height: normalの場合のみ考慮されます。

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

パーセンテージが長さに算出されるのは悩ましい。 Issue 3118やIssue 2165も参照。

注: line-fit-edgeがleadingの時、 インラインボックスのmargin、border、paddingは 行ボックスの高さ計算に影響しません。 ただし、これらはボックス周囲にレンダリングされます。 したがってline-heightで指定したサイズがボックスのサイズより小さい場合、 背景や枠線が隣接する行ボックスに「はみ出し」、前の内容が隠れる可能性があります。

5.2. テキスト端メトリクス: line-fit-edge プロパティ

これは初期ドラフトの提案です。 設計レビューやユースケースの登録によって大きく変更される可能性があります。 他プロパティとの詳細や相互作用も今後調整されます。まだ出荷しないでください。

インラインボックス（主目的がテキストを含むもの）は、 ブロック軸のサイズがフォントメトリクスに基づき決定されます。 line-fit-edgeプロパティはどのメトリクスを使うかを制御します。 選ばれたメトリクスは、インラインボックス（ルートインラインボックスでない場合）に対するレイアウト境界の根拠として使われます。 またデフォルトでは、text-box-trimにも使われます。

<text-edge>値は 特定のフォントメトリクスを指定し、 以下に展開されます：

<text-edge> = [ text | ideographic | ideographic-ink ]
              | [ text | ideographic | ideographic-ink | cap | ex ]
                [ text | ideographic | ideographic-ink | alphabetic ]

最初の値はテキストのover端を指定します。 二番目の値はテキストのunder端を指定します。 1つだけ指定された場合、両端に同じキーワードが可能なら割り当てます。不可の場合は不足値にtextを使います。

ロングハンドが必要か、このショートハンドだけで十分か？ [Issue #5236]

各値の意味：

leading

ascent/descentに加え、正のhalf-leadingを用いる。 サイズ計算時、margin/padding/borderは無視される（行ボックスのサイズ指定に関して）。

text

text-overベースライン/text-underベースラインをover/under端として用いる。

cap

cap-heightベースラインをover端として用いる。

ex

x-heightベースラインをover端として用いる。

ideographic

ideographic-overベースライン/ideographic-underベースラインをover/under端として用いる。

ideographic-ink

ideographic-ink-overベースライン/ideographic-ink-underベースラインをover/under端として用いる。

alphabetic

alphabeticベースラインをunder端として用いる。

textはascent/descentメトリクス名として妥当か？ もっと良い名前は？同様にleadingキーワードも。 [Issue #8067]

line-fit-edgeがleadingの場合（ボックス自身のline-heightでスペーシング追加）を除き、ボックスのmargin/padding/borderもレイアウト境界に加算されます。

注: leadingとtext値は フォントのascentとdescentに頼ってテキストが収まるようにしています。 その他の値は、指定メトリクスを超えるアセント（例：ダイアクリティカルマーク）による重なりやオーバーフローが起きやすいので、 これらの値を使う場合は、特に多言語コンテキストでは十分なスペースを確保するよう注意が必要です。

注: 正のleading値のみがpositivehalf-leadingを追加しますが、 テキストをタイトに配置するため、 どの値も負のhalf-leadingを適用します。 詳細は§ 5.3 インラインボックスの論理高さ（レイアウト境界）の計算参照。 half-leadingはテキスト両端に均等に適用されます。 より精密な重なり制御にはline-fit-edge: textと 負のmarginを併用してください。

5.3. インラインボックスの論理的高さ寄与（「レイアウト境界」）の算出

インラインボックスが自身の論理高さに対して行ボックスに 寄与する値（本節ではレイアウト境界という）、 は常に自身のテキストメトリクスに基づき算出されます（以下参照）。 算定はline-fit-edgeおよびline-heightプロパティで制御されます。 子ボックスのサイズや位置は、 自身のレイアウト境界（および自身の論理高さ）には影響しません。 詳しくはinline-sizing参照。

注: レイアウト境界は必ずしもボックスの端と一致する必要はありません。

レイアウト境界を算出するには、 UAはまずインラインボックスが直接含む全てのグリフを 互いにその支配的ベースラインで整列させます。 （§3.3 グリフとボックスのベースライン参照。） インラインボックスに全くグリフが含まれない場合や、フォールバックフォントのグリフのみ含む場合は、 そのボックスのfirst available fontのメトリクスを持つ「strut」（幅0の不可視グリフ）が含まれているとみなします。

各グリフ（strutも含む）について、Aはベースライン上の上昇（ascent）、Dはベースライン下の下降（descent）を表します。 line-fit-edgeで他のメトリクス指定がなければ、Aは フォント・サイズに応じたアセントメトリクス、 Dはディセントメトリクスとなり、 それぞれ支配的ベースラインのゼロからのオフセットを考慮して調整されます。 line-heightがnormalで、 line-fit-edgeがleadingまたはルートインラインボックスの場合は、 フォントのline gap metricも AとDにhalf-leadingとして半分ずつ加算できます。

算出line-heightがnormalの場合、 インラインボックスのレイアウト境界は全グリフを囲み、 一番高いAから一番深いDまでが範囲となります。 （1つのボックス内のグリフが異なるフォント由来の場合、AやDが全て同じではないこともあります。）

算出line-heightがnormalでない場合、 レイアウト境界は first available fontのメトリクスのみから導出され（他のフォント由来グリフは無視）、 使用line-height値と合計するよう リーディングでAとDを調整します。 leading Lは L = line-height - (A + D) で算出。 leadingの半分（half-leading）を first available fontのAの上側とDの下側にそれぞれ加算し、 有効な上昇値A′ = A + L/2、 有効な下降値D′ = D + L/2 となります。 ただしline-fit-edgeがleadingでない場合かつルートインラインボックスでない場合、 half-leadingが正値ならゼロ扱い。 レイアウト境界はこの有効A′・D′を正確に囲みます。

注: Lは負値になる場合もあります。

さらに、 line-fit-edgeがleadingでない場合、 レイアウト境界は 各辺のmargin、border、paddingの合計で水増しされます。 負のmargin値も有効に機能するよう、 負のmarginも同じインライン整形コンテキストに参加する 子孫インラインボックスの レイアウト境界にも加算されます。

Quirksモード [QUIRKS]では、 インラインボックス 断片が border/paddingがゼロかつ直接テキストや保存空白 [CSS-TEXT-3]を含まない場合、 行ボックスline boxのサイズ計算で無視されます。

6. テキスト上下のトリム

通常の流しテキストで一貫したスペースを確保するために、 CSS行レイアウトは各行のテキスト内容の上下に必要に応じてリーディング（行間）を導入し、 line-heightを確保します。 さらに、フォントのアセント・ディセントメトリクス自体も、 典型的なグリフ形状よりも上下に余分なスペースを含むことが多く、 これは時折現れる文字やダイアクリティカルマーク（記号）が通常の範囲を超えて上下に伸びるのに対応するためです。 これにより隣接するテキスト行が重なり合うのを防ぎます。 しかし、これらの余分なスペースは視覚的な揃えや見た目上のスペース制御を妨げます。

text-boxプロパティにより、 ブロックの最初と最後の行の上下の余分なスペースをトリム（削除）し、 グリフ周囲のスペースをより精密に制御できます。 フォントメトリクスに依拠することで、ハードコードの長さに頼らず、 コンテンツのリサイズ・改行・様々なフォントでの描画でも精密なスペースを維持できます。

よくある問題が垂直方向の中央揃えです。 テキストコンテナをアイコンに縦方向で中央揃えするのは簡単ですが、 ラテン文字の見た目の境界はcap-heightとalphabeticベースラインであり、 アセント・ディセントではないため、 視覚的な意図と異なる結果になることが多いです。

視覚的にテキストを中央揃えするには、 上端をcap-height、下端をalphabeticベースラインとみなす必要があります。

text-box-trimでcap-height上部とalphabeticベースライン下部の余白を除去すると、 ボックス中央揃えが実際にテキスト中央揃えとなり、 どんなフォントでも確実に期待通りの結果が得られます。

6.1. テキストボックストリム用ショートハンド: text-box プロパティ

このプロパティはショートハンドであり、 text-box-trimおよびtext-box-edgeプロパティを 一括して設定できます。

単一キーワードnormalを指定した場合、 text-box-trimはnone、 text-box-edgeはautoに設定されます。 それ以外の場合、text-box-trim値を省略するとboth（初期値ではない）、 text-box-edge値を省略するとauto（初期値）となります。

例を追加すること。

6.2. テキスト上下トリム: text-box-trim プロパティ

インラインボックスに適用した場合、 内容ボックスを指定したtext-box-edgeメトリクスに揃えてトリムするかどうか指定します。 詳細は§5.3 インラインボックスの論理高さ（レイアウト境界）の計算参照。

ブロックコンテナーや、 マルチカラムコンテナーの各カラムにも適用した場合、 ボックス内容の開始／終了時（start/end）のhalf-leadingをトリムし、 内容エッジとテキスト内容をより近づけます。 この場合のトリム端は、 該当text-box-edge値で決まります（該当行ボックスの包含ブロックのstart/end text-box-edge値）。

各値の意味：

none

行ボックスがブロックコンテナーに適用された場合、特別な処理はなし。

インラインボックスに適用した場合は、 上下の内容エッジが text-over/text-underベースラインと一致し、 text-box-edge値によらず固定されます。

trim-start

ブロックコンテナーやカラムボックスの場合： block-start側で、 最初の整形行を ルートインラインボックスの指定メトリクスにトリム。 そのような行がなければ、あるいは間に非ゼロのpaddingやborderがあれば、効果なし。

インラインボックスの場合： ボックスのblock-start側をトリムし、 内容エッジをtext-box-edgeで指定されたメトリクスに一致させる。

trim-end

ブロックコンテナーやカラムボックスの場合： 最後の整形行のblock-end側を指定メトリクスにトリム。 そのような行がなければ、あるいは間に非ゼロのpaddingやborderがあれば、効果なし。

インラインボックスの場合： ボックスのblock-end側をトリムし、 内容エッジをtext-box-edgeで指定されたメトリクスに一致させる。

trim-both

trim-startとtrim-endの両方の挙動を指定。

注: ::first-line同様、 このプロパティはflex, grid, table整形コンテキストには適用・伝搬されません。

注: block-end側は、 line-under側と一致しません（writing-modeがvertical-lrのとき）。

複数の祖先が同じ行ボックスにトリム指定した場合、 使われるメトリクスは該当側でトリム指定した最も内側のブロックコンテナーのものです。

注: text-box-trimの初期値以外でボックスから内容やインクが溢れた場合、 通常のオーバーフロー処理と同じく扱われます。

::first-lineと異なり、 マルチカラムコンテナーの最初（または最後）の整形行に適用した場合、 マルチカラムコンテナー内の各カラムの最初（または最後）の整形行それぞれに適用されます。

カラムがspannerで分割された場合の挙動は？ [Issue #11363]

text-box-trimを適用したボックスが断片化された場合（[CSS-BREAK-3]）、 トリムが断片ごとに適用されるか最初／最後の断片だけに適用されるかは、 box-decoration-breakで決まります。

印刷時、行ボックスのトリムで内容がクリップされそうな場合、 UAはその行ボックスの該当端でtext-box-trimを無視してもよいです。

6.3. テキストトリムメトリクス: text-box-edge プロパティ

このプロパティはtext-box-trim効果に使うメトリクスを指定します。 値の意味はline-fit-edgeと同じです。 autoキーワードは line-fit-edgeの値を使用します。 ただしleading（初期値）はtextとして解釈されます。

注: このプロパティはtext-box-trimとtext-boxショートハンドで同時設定可能です。 line-fit-edgeとは異なり継承されませんが、 初期値は 継承されるline-fit-edgeの値をコピーします。

6.4. インラインボックス描画高さ: inline-sizing プロパティ

この名前は紛らわしいため、変更が必要です。 あるいはtext-box-trimに統合する？ [Issue #5189]

このプロパティは論理高さを 内容領域（content area）の インラインボックスについて 内容に対してどう測定するかを指定します。 ボックス内容・行ボックス・他コンテンツのサイズや位置には影響しません。

各値の意味：

normal

内容領域は、インラインボックスの first available fontの仮想テキストに合わせてサイズ・配置されます。 text-box-trimでトリム指定があれば、指定メトリクスを使うこと。 そうでない場合、仕様では方法の指定がありません。 UAは例えばフォントの最大ascender/descenderを使ってもよい。 （これでem-box外のグリフも内容領域に収まるが、フォントごとにボックスサイズが異なることになる）

注: 複数のフォントが使われた場合（グリフが異なるフォント由来の場合）でも、 論理高さはフォールバックフォントのグリフには影響されず、 first available fontのみに依存します。 ただしこれらフォールバックグリフは、行ボックスのサイズには影響する場合があります（line-heightがnormalの場合）。 詳細は§5.3 インラインボックスの論理高さ（レイアウト境界）の計算参照。

stretch

行ボックスのサイズ指定・内容配置が normal同様に行われた後、 インラインボックスのボックス端が 行ボックスの端と一致するようにシフトされ、 インラインボックスの内側論理高さが、外側サイズとして 行ボックスを埋めるよう拡張されます。 （子要素のサイズや位置は影響されません）

注: heightプロパティはインラインボックスには適用されません。

注: line-heightは インラインボックスのサイズには影響しません。行ボックス論理高さへの寄与のみに影響します。

7. 頭文字（イニシャルレター）

編集者は、特にインド系文字など非西洋文字でのドロップキャップの例を求めています。

7.1. 頭文字の概要

この節は規範的ではありません。

大きく装飾的な文字は、印刷技術が発明される以前から新しい段落の開始に使われてきました。実際、こういった文字使いは小文字の登場よりも古い歴史を持っています。

7.1.1. ドロップキャップ（頭文字）

ドロップキャップ（または「ドロップイニシャル」）は、段落の先頭に現れる通常より大きな文字であり、そのベースラインは段落の最初のベースラインより少なくとも一行分下に位置します。ドロップキャップのサイズは通常、その文字が占める行数で示されます。2行・3行分のドロップキャップが一般的です。

ドロップキャップの正確なサイズや位置は、そのグリフの整列によって決まります。ドロップキャップの基準点は本文の基準点と正確に揃える必要があります。整列の制約は書記体系によって異なります。

西洋書記体系では、上端の基準は頭文字のcap-heightと本文1行目のcap-heightです。下端の基準は頭文字のalphabeticベースラインとN行目本文のベースラインです。下図は2行ドロップキャップの例で、関連する基準線が描かれています。

漢字系書記体系では、頭文字は1行目のグリフのblock-start端からN行目のグリフのblock-end端まで伸びます。

インド系文字の一部では、上端の整列点はハンギングベースライン、下端の整列点はtext-after-edgeです。

7.1.2. 沈み頭文字（サンケンキャップ）

ドロップキャップのスタイルによっては、1行目本文に揃えない場合もあります。沈み頭文字（サンケンキャップ）は、ベースラインより下へ沈み、さらに1行目本文より上へもはみ出します。

7.1.3. 浮かし頭文字（レイズドキャップ）

浮かし頭文字（レイズドキャップまたはスティックアップキャップ）は、1行目のベースラインまで沈みます。

注: 適切な浮かし頭文字は、単純に最初の文字のフォントサイズを大きくするより多くの利点があります。段落の他の行間は変化せず、大きなディセンダーがあってもテキスト回りが除外されます。また、浮かし頭文字のサイズを整数行数で定義すれば、暗黙のベースライングリッドを維持できます。

7.2. 頭文字の選択

この節は規範的ではありません。

頭文字は通常1文字ですが、句読点やユーザーが一つのタイポグラフィ単位と認識する文字列を含むこともあります。::first-letter擬似要素（[SELECT]、[CSS-PSEUDO-4]で定義）は、頭文字として整形する文字を選択できます。

より細かな文字選択や、置換要素・複数単語に頭文字スタイリングを適用したい場合は、ブロックコンテナーの最初のインラインレベル子要素にinitial-letterプロパティを直接指定できます。

<p>この段落はドロップキャップTを持ちます。
<p><img alt="H" src="illuminated-h.svg">ここでは装飾されたHがあります。
<p><span>単語にも</span> 段落冒頭で頭文字スタイリングを適用できます。

::first-letter, /* 最初の段落のTにスタイル */
img, /* 装飾Hにスタイル */
span /* span内の語にスタイル */
{ initial-letter: 2; }

注意：::first-letterは最初の文字の前後の句読点も選択するため、::first-letter使用時はこれらも頭文字に含まれます。

この挙動を避ける方法が必要か？ GitHub Issue 310参照。

7.3. 頭文字の作成：initial-letterプロパティ

このプロパティは、ドロップキャップ・浮かし頭文字・沈み頭文字のサイズと沈み量（sink）を行数で指定します。

h2 + p::first-letter { initial-letter: 2; }

主な値は以下の通り：

normal

特別な頭文字効果なし。通常のテキストとして扱う。

<number [1,∞]>

第一引数は頭文字のサイズ（占める行数）を指定します。1未満は不正です。

<integer [1,∞]>

第二引数（オプション）は、頭文字の沈み量（sink、何行下まで沈むか）を指定します。 1は浮かし頭文字、1より大きいと沈み頭文字になります。1未満は不正です。

raise

sink値が1として算出されます。

drop

sink値はサイズの整数切り捨てとなります。

sink値を省略した場合、dropが指定されたとみなされます。

normal以外の値を指定すると、対象ボックスは頭文字ボックスとなり、 特別なレイアウト動作を持つin-flowのインラインレベルボックスになります。

他のCSSプロパティと併用して、initial-letterで「隣接頭文字」（テキスト横に頭文字を配置）も作成できます：

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

p {
  margin-left: 5em;
}

7.3.1. 適用範囲

著者がどの文字を頭文字としてスタイリングするかをより細かく制御できるようにし、複数文字の頭文字（単語やフレーズのスタイリングなど）も可能にするため、 initial-letterプロパティはCSSで定義された::first-letter擬似要素だけでなく、 inside配置の::marker擬似要素や、 インラインレベルボックスで行頭に配置されたものにも適用されます。 具体的には、initial-letterは、 親ボックスの最初の子であり、 祖先（あれば）はその包含ブロックの子孫で、 すべて最初の子かつインラインボックスで、 算出された initial-letter値がnormalのものに適用されます。

例えば、 次の例中の<span>、<em>、<b>要素は <p>の「first-most inline-level descendants」となりますが、 <strong>要素は該当しません：

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

以下のルールを適用した場合：

em { initial-letter: 2; }
b, strong { initial-letter: 3; }

initial-letterプロパティが有効になるのは <em>のみです。 <b>へのスタイリングは、祖先がすでに頭文字としてスタイリングされているので無視され、 <strong>へのスタイリングは、2番目の兄弟要素なので無視されます。

結果のレンダリング例：

initial-letterがインラインレベルボックスに適用されていても、 ビディ再順序や他のインラインレベル内容により 行頭に配置されていない場合、 使用値はnormalとなり、 頭文字として整形されません。

initial-letterプロパティの効果は、 ルビベースコンテナボックスの子や、 ルビコンテナボックスの子では未定義です。

注: initial-letterプロパティは、 floatがnoneでない要素や positionがstaticでない要素には適用できません。 なぜならこれらの値はdisplayを blockに算出させるためです。

7.4. 頭文字の整列: initial-letter-align プロパティ

前述の通り、頭文字の整列は使用する書記体系によって異なります。 initial-letter-alignプロパティで適切な整列方法を指定できます。

このプロパティは頭文字のサイズ・位置決め時に使う整列点を指定します。 整列点は2セット必要です： 頭文字のoverとunder整列点を、ルートインラインボックスの対応するoverとunder点に揃える形になります。

各値の意味：

alphabetic

周囲テキストのcap-heightとalphabeticベースラインを使って頭文字を整列。

ideographic

周囲テキストのideographic-ink-over・ideographic-ink-underベースラインで頭文字を整列。

hanging

周囲テキストのhanging・alphabeticベースラインで頭文字を整列。

leading

周囲テキストのover/under half-leading端（ascent/descent＋half-leading）で頭文字を整列。

注: これは頭文字の端を影響する最初／最後の行の行間中央に揃える形となり、インド系組版の一部などで使われる効果です。 詳細 [ILREQ].

border-box

頭文字ボックスのline-under・line-overのborder edgeをover/under整列点に使う。

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

border-box指定時以外は、 頭文字の整列点は内容から自動決定されます：

1. 頭文字がアトミックインラインなら、over/under内容ボックス端を使う。
2. 頭文字がHan, Hangul, Kana, Yi Unicode scriptプロパティを持つ文字を含む場合は、 ideographic-ink-over・ideographic-ink-underベースラインを使う。
3. 頭文字がHan, Hangul, Kana, Yi Unicode scriptプロパティを持つ文字を含む場合は、 hanging・alphabeticベースラインを使う。
4. それ以外はcap-height・alphabeticベースラインを使う。

ヘブライ語・タイ語など一部書記体系の頭文字整列は、現状OpenTypeメトリクスが未定義のため正確に指定できません。 (Issue 5244)

注: このプロパティのキーワード順は固定であり、border-boxが[ border-box | alphabetic | ideographic | hanging ]のように展開される場合、頭文字の整列点を明示的に指定できるようになります。

7.4.1. UAデフォルトスタイルシートの initial-letter-align

より適切な既定動作を提供するために、 UAはデフォルトUAスタイルシートに以下のルールを含める必要があります：

[lang]:lang(zh, ja, ko, ii) {
  initial-letter-align: ideographic;
}
[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;
}

これは主要な言語横断転写体系のみをカバーしています。 他のスクリプトタグもUAスタイルシートに含めるべきでしょうか？

7.5. 頭文字レイアウト

頭文字ボックスには2種類あります： 非置換のインラインボックス由来のものと、 アトミックインライン由来のものです。

非アトミックなインライン頭文字の場合、 そのボックスと内容は 行が属するインライン整形コンテキストに参加し、 期待通りのサイズや整列になるよう多くの特別な規則が適用されます。

アトミック頭文字の場合は、 置換要素であるか、 内容に対して独立整形コンテキストを確立するものであり、 ボックスのサイズ（自動サイズ以外のブロック軸）や ボックス内の内容レイアウトは通常通りであり、 主にボックスの位置決めが特別になります。

7.5.1. 頭文字に適用されるプロパティ

インラインボックスに適用可能なプロパティは、 インライン頭文字にも適用されますが、 vertical-alignとそのサブプロパティ、 font-size、 line-height、 line-fit-edge、 inline-sizingは除外されます。 さらにサイズ指定プロパティやbox-sizingも 頭文字に適用されます（[css-sizing-3]参照）。

アトミックインラインに適用可能なプロパティは、 アトミックインラインが頭文字としてスタイリングされた場合も適用されますが、 vertical-alignとそのサブプロパティは除外されます。

7.5.2. マージン・ボーダー・パディング

頭文字には他のボックス同様にmargin、padding、borderを指定できます。 ただしinitial-letter-alignがborder-boxでなければ、 垂直整列やフォントサイズ指定には影響しません。 ただし実効的な除外領域（通常は頭文字のmargin box（initial-letter-wrap参照））には影響します。

paddingとborderがゼロの場合、頭文字はカーニングされる場合があります（下記参照）。

7.5.3. 頭文字のフォントサイズ

インライン頭文字の場合、 頭文字内容のフォントサイズは、 指定されたサイズ（initial-letter参照）に整列点（initial-letter-align参照）をアンカーとして合うように算出します。 この計算にはレイアウトは不要で、算出値とフォントメトリクスのみで決まります。 この使用フォントサイズ算出は、算出font-sizeには影響しません。 そのためem長さ値等の計算にも影響しません。

子孫への継承はどう扱うか？ [Issue #4988]

この計算で使う行間は、包含ブロックのline-heightです。 （ベースライングリッド使用時は、ベースライングリッドで定義されたベースライン間隔 [CSS-LINE-GRID-1]） 行で跨がれる内容や行の高さ・位置の変動は計算に含みません。

西洋書記体系でN行ドロップキャップの場合、 頭文字のcap-heightは(N – 1) × line-height + 本文のcap-height となります。 この高さは頭文字自体のフォントサイズではありません。

実際のフォントサイズ計算は難しく、 N行ドロップキャップのフォントサイズは次式で求められます：

この計算式はa)書記体系・整列点によらず一般化すること b)非整数サイズにも対応することが必要です。

アトミック頭文字では、 使用フォントサイズは通常通り算出された値になります。

7.5.4. 字形形成とグリフ選択

initial-letterがnormal以外の場合、 インライン頭文字は 字形形成のために分離されますが、 その後のテキストは本来、インライン頭文字ボックスの境界をまたいで字形形成されるべきです。 （CSS Text 3 § 7.3 要素境界を跨ぐ字形形成参照） 例えば「يحق」の最初の文字をinitial-letter: 2 1でスタイリングすると、 最初の文字は孤立形「ي」として頭文字となり、 後続の「ﺤﻖ」は通常通り頭文字の内容の後に続くものとして形が決まります。

7.5.5. 頭文字ボックスのサイズ指定

インライン頭文字の場合、 頭文字の希望幅/希望高さが明示的であれば、 その値（必要に応じて最小サイズや最大サイズプロパティでクランプし、 box-sizingも考慮）がボックスのその寸法に使われます。

そうでなければ、その寸法は自動サイズとみなし、 内容ボックスは以下両方を収容するようにサイズ決定されます：

• 指定された沈み量（over整列点〜under整列点の空間）
• ボックス内の全グリフのアウトライン（hanging（hanging-punctuation参照）なものは除外）や、 ボックス内のmargin box（アトミックインラインを含む場合）など。
  頭文字のグリフが指定した沈み量内に収まらない場合もあります。 例えばディセンダーがある頭文字は(n+1)行目のテキストに衝突する可能性があります。 これは望ましくありません。

  

  したがって、頭文字のグリフアウトラインの影響範囲すべての行ボックスを除外する必要があり、 沈み量sink範囲内だけでは不十分です。

  

ただし、block-startのpaddingとborderが両方ゼロの場合、 block-startの内容エッジは over整列点と完全に一致し、その上にあふれる内容はレイアウト上無視されます。

注: インライン頭文字にアセンダーがあり、 それがover整列点より上に伸びている場合、著者がmarginを頭文字か包含ブロック側のどちらにも指定しないと、 そのアセンダーが前の内容と衝突する可能性があります。

注: このようなアセンダーに必要なスペースを自動でmarginとして扱い、 包含ブロックmarginと折り畳めるようにすれば、 必要になるまで余分なスペースを課さず、必要な時だけ確保できるため便利です。 実装の複雑さ次第で将来的な検討も可能ですが、現状は著者が明示的にスペースを指定する必要があります。

hanging-punctuationをボックス内に含めるべきか？ （border/backgroundで見える場合はボックスをpunctuation含めて描画し、位置決め時のみ除外？flush配置でpunctuationだけぶら下げる形？） 議論参照。

アトミック頭文字は、 そのアトミックインライン型に通常通りサイズ指定されます。 ただし、ボックスが自動ブロックサイズ（auto）の場合は、 block sizeは インライン頭文字のborder-box整列に準じて決まり、 明示的となります。

7.5.6. 頭文字ボックス内の整列

デフォルト（自動サイズ時）は、 インライン頭文字の内容ボックスは内容にぴったり合わせてサイズ決定され、 text-align やalign-contentは適用されません。 ただしボックスが自動サイズでない場合：

• インラインサイズが明示的なら、 text-alignで 頭文字内容を インライン軸で整列（通常通りインライン軸ベアリングを使い、グリフ外接ボックスではなく）。
• ブロックサイズが明示的なら、 align-contentで内容を ブロック軸で整列（ブロック軸ベアリングを使い、必要なら合成）。

7.6. 頭文字の位置決めとスペーシング

7.6.1. ブロック軸での配置

ブロック軸では、頭文字は その行ボックス（originates）に対し、 整列（initial-letter-align）と指定沈み量（initial-letter）に従って配置されます：

• サイズが沈み量以上の場合、 頭文字は under整列を満たすように配置され、 その後 (沈み量-1) × line-height（包含ブロック）分だけ 包含ブロックのblock end方向にシフトされます。

• サイズが沈み量未満の場合、 頭文字は over整列を満たすように配置されます。

注: 頭文字は本質的に、 initial-letterの第2引数で指定された行数分沈み、 必要なunder整列点に揃うよう配置されます。 これは包含ブロックに頭文字だけがあり、その後に無限のプレーンテキストが ルートインラインボックスの直接内容として続く場合を仮定した位置です。 影響を受ける行ボックスの内容による行間不整合は頭文字の位置に影響しません。

頭文字は、それが参加する行ボックスの論理高さを増やすことはありません。 上下にはみ出てもよいです。 自身のblock-startのmargin edgeが 包含ブロックのblock-startのcontent edgeより下になるよう配置され、 その結果、originating line box（や後続内容）がそのエッジから遠ざかることもあります。

7.6.2. インラインカーニング

頭文字が非アトミックインラインで、 自動のインラインサイズかつ パディング・ボーダーがゼロの場合、 そのmargin boxはカーニング（負方向インセット）されます。 これは内容ボックスの開始端から、本来頭文字でなければline boxの開始端に置かれるはずの内容までの距離（つまりグリフ外接ボックスと開始サイドベアリングの差分）だけです。 このインセットは実質的に ボックスへの追加のinline-start marginとなります。

7.7. 頭文字回り込み：initial-letter-wrap プロパティ

注: initial-letter-wrapはリスクあり。

このプロパティは、頭文字によって影響を受ける行が、 頭文字ボックスの矩形かグリフ輪郭に合わせて短縮されるかどうかを指定します。

none

輪郭フィッティングは実施されません。 影響行はすべて inline-endのmargin edgeで 頭文字に揃えて短縮されます。

first

noneと同じ挙動だが、 頭文字直後の最初のtypographic character unitがUnicode General Category Zsなら適用。 そうでなければ、頭文字を含むブロックの1行目はallと同じ、その他はnoneになる。

この例はなぜ1行目だけ輪郭フィットが必要か、また頭文字直後がスペースの時はなぜ不要かを示します：

無条件のfirstは必要か？ （値名をautoに変更し、スペースチェックしないfirst値を追加？）GitHub issue 410参照

all

頭文字に影響される各テキスト行について、 頭文字に隣接する行ボックスは 頭文字のグリフ輪郭と重ならない最も開始端から始まる。

shape-outsideがnoneでない場合は、グリフ輪郭の代わりにshape-outsideが使われる。

いずれの場合もshape-marginで輪郭が拡張され、 その輪郭は頭文字のmargin edgeでクリップされます。

注: この値はリスクあり。

grid

この値はnoneと同じですが、 影響行の除外領域の終端が文字グリッドに揃うように拡大されます。 すなわち、(1ic＋letter-spacing)の倍数になるように 包含ブロック上で計算されます。 justify-selfで 頭文字ボックスを除外領域内で整列できます。

注: この例では、ドロップキャップの除外領域はグリフより大きくなり、インライン軸の揃えを維持します。

注: この値もリスクあり。

<length>

<percentage>

この値はfirstと同様ですが、 1行目の調整量をグリフ形状から推定するのではなく明示的に指定します。

フォント相対長さ指定は使用サイズ基準であるべき。

注: この値は実装が容易なため存在します。 著者はfirst値と marginでスペーシングを制御し、グリフ検出のフォールバックとして本値を使うことを推奨します。

次の例では、UAがfirstをサポートすればグリフ輪郭＋指定marginで1行目位置決めし、 <length>や <percentage>値のみサポートなら 頭文字幅の40%分1行目を引き込み、marginを加えます。

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. */
  }
}

これらの値や関連する煩雑さは、Blinkがfirstサポートすれば不要になる可能性あり。

auto値の挙動を様々な文脈で示す図を編集すること

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

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

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

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

7.8. 行レイアウト

頭文字ボックスは、 in-flowとして ブロック整形コンテキストに属し、 その出現した行ボックス（originating line box）の内容の一部となります。 垂直軸以外（§ 7.6.1 ブロック軸での配置参照）は、 行の他の内容との相互作用は インラインレベル内容と同様ですが、 一部に特別な詳細があります…

7.8.1. インラインフローレイアウト：整列・ジャスティフィケーション・空白処理

頭文字ボックスは、 そのインラインレベル内容と同様に originating line boxで 整列・ジャスティフィケーション・空白処理に参加します。

ただし、影響行の整列を一貫させるため、折り畳み可能な空白は 沈み頭文字と その後の内容との間のoriginating line上で 折り畳まれます。 また、通常は沈み頭文字と後続内容の並びで生じる letter-spacingや justification opportunityは抑制されます。 （ただし、word-spacingや justification opportunityが 単語区切りで生じる場合は影響しません。 これは空白自体がtypographic character unitとして供給され、 隣接文字との並びで生じるものではないためです。）

7.8.2. 行端効果：インデントとぶら下がり句読点

text-indentや hanging-punctuationは 頭文字の originating line boxに通常通り適用され、 行頭（頭文字自身も含む）の内容がシフトします。 除外影響を受ける後続行も通常通り短縮されますが、 頭文字の位置によってはその度合いが変わることもあります。

initial-letterと hanging-punctuationの相互作用は 議論中です。

7.8.3. 祖先インライン

頭文字ボックスが インラインボックス祖先に含まれる場合、 それらインラインボックスの境界は 頭文字ボックスを除外する形で描画されます。 これは純粋な幾何的操作であり、 プロパティの継承や letter-spacingの有効値等には影響しません。

7.8.4. 複数行頭文字

頭文字が1行に収まらない場合、通常の折り返し規則に従って改行され、 各行は頭文字が長すぎて後続テキストが入らない場合の1行目と同じように埋められ、整形されます。 頭文字の後の通常テキストはその最終行から始まり、 その行が1行目であった場合と同じように影響を受けます。

7.9. 頭文字のクリア（回避）

7.9.1. 浮かし頭文字・沈み頭文字

頭文字のmargin boxは包含要素のサイズに寄与します。 1行目より上に伸びる頭文字（"浮かしキャップ"や"沈みキャップ"として知られる）は前要素に食い込むことはありません。 頭文字のcontent boxにはグリフインク全体が含まれるため、 頭文字のcap-heightより上のアクセント記号やインクも前要素に影響しません。

フォントのcap-height上のグリフインク処理。 提案：これを除外領域とし、行ボックス・border boxにも適用。頭文字marginも除外領域に含めてスペーシング制御。

ボックスモデル図を追加すること。頭文字marginはコンテナと折り畳まれるか？

7.9.2. 短い段落と頭文字

頭文字付き段落は、頭文字が占める行数より本文が少ない場合もあります。 この場合でも頭文字の上端整列は維持され、 除外領域は後続ブロックにも継続します。 そのため後続インライン内容は頭文字の周りに回り込むことになり（まるでそのブロックテキストが自身の包含ブロックの一部であるかのように）、 フロートが後続ブロック内容を除外するのと同様です。

後続ブロックが頭文字から始まる場合、 独立整形コンテキストを確立する場合、 あるいは頭文字の包含ブロックの開始方向で clear指定がある場合、 先行ブロックの頭文字をクリア（回避）する必要があります。

7.9.3. フロートとの相互作用

頭文字は floatではありません。 in-flowの インラインレベル内容で、 行ボックスに属します。 したがって：

• clearプロパティは頭文字を考慮しません。 頭文字には適用されず、近くのフロートでクリアされることもありません。
• 行ボックスやフロートと同様に、頭文字ボックスは、同じmargin boxを持つフロートと重ならないようにしなければなりません（ブロック整形コンテキスト内）。 頭文字ボックスが重なった場合、重ならなくなるまで内側または下方向にずらされます。
• 行ボックスの開始端がフロートをクリアするために移動した場合、その行内で頭文字がoriginatingしていれば一緒に移動します。 同様に、頭文字がフロートをクリアするために内側または下にずれる場合、 そのoriginating line boxや後続の行ボックスも短縮／移動されます。
• inline-startフロートが、 頭文字に隣接する内容の最初の行から発生する場合、 そのフロートは頭文字を越えて包含ブロック端へ移動します（頭文字が通常のインライン内容であるかのように）。

  ただし、そのようなフロートが（沈み頭文字に隣接する）後続行から発生する場合、 そのフロートは頭文字をクリア（回避）しなければなりません。

floatと隣接内容のレイアウトについてはCSS2§9.5参照。 [CSS2]

後続行由来のinline-end floatも頭文字をクリアすべきか？（inline-start float同様） 議論中。 美的理由はないが、基礎レイアウトモデルで両者を区別できるかは未定。

7.9.4. 断片化（ページ分割）との相互作用

単一グリフは断片化して ページ（やカラム、その他断片化コンテナ）を跨ぐことはできないため、 頭文字は ブロック軸断片化（ページ・カラム・領域分割等）に関しては monolithicとみなされます（[CSS-BREAK-3]）。 また、頭文字と並ぶin-flow行の間での分割も避けられます（widows, orphansの回避と同様）。 ただし、 頭文字ボックスの横で強制分割があればそちらが優先され、 頭文字ボックス自体には影響ありません。

他のmonolithicオブジェクトと同様、 頭文字ボックスが 断片化コンテナfragmentation containerの先頭に現れ、 その断片化コンテナが頭文字ボックスを収容するには短すぎる場合、 頭文字ボックスは切り詰め・切断される場合もあります。 ただし隣接内容は独自の規則に従って断片化され、 頭文字と一緒に切り詰め・切断されることはありません。

付録A: 整列メトリクスの合成

A.1: Em-overとEm-underの算出

注: em-overおよびem-underベースラインはCSSで使用されません。 これらの定義は、Canvas TextMetrics APIで使われる他のメトリクスとの一貫性のために本モジュールに含まれています。

em-overおよびem-underメトリクスは以下のように算出します：

• central、ideographic-over、ideographic-underのいずれかがフォントで定義されていれば、 em-overはcentralベースラインの上0.5em、 em-underは下0.5emとする。 centralベースラインが未定義の場合は他から導出する（下記参照）。

• それ以外の場合は、ascentおよびdescentを 合計がちょうど1emになるよう比例的に調整し、 正規化されたこの値をem-overおよびem-underメトリクスとみなす。

注: この計算により、em-overとem-underは常に正確に1em離れ、 グリフ輪郭の「重心」がちょうど中間になるよう調整されます。

A.2: テキストのベースライン（他のフォントメトリクス）の合成

一部のフォントには、本モジュールで説明した適切なテキスト整列に必要なメトリクス情報が含まれていない場合があります。 UAは必要なメトリクスがない場合、以下の方法を用いてもよい：

関連メトリクスの利用

特定のメトリクスには典型的な関係性があり、この関係性を使って欠損メトリクスを（少なくともヒューリスティックに）導出できます。 フォントフォーマット自体に具体的な計算方法がなければ、以下の規則を利用できます：

1. central baselineは、 ideographic-overと ideographic-underベースラインの中間点と定義されるので、 いずれか2つが分かれば残り1つも決定できる。
2. ideographic-overと ideographic-underベースラインは通常1em離れているので、 ideographic-over/ideographic-under/centralのいずれか1つしかない場合も、この関係から残り2つが算出できる。
3. CJKフォントではascentとdescentが ideographic-overとideographic-underベースラインに一致することが多いので、 両方とも欠損している場合は代用できる。

フォントの計測

メトリクスはグリフ形状から導出してもよい。 例えば：

1. マイナス記号（U+2212）の中心を数学ベースラインとみなす。
2. 小文字「o」がalphabeticベースラインより下にどれだけ伸びているかをその最高点から引くことで x-heightを測る。

   

3. 大文字「O」がalphabeticベースラインより下にどれだけ伸びているかをその最高点から引くことでcap-heightを測る。
4. 永（U+6C38）の外接ボックスを使い、表意文字の文字面端を求める。
5. ヘブライ語He（U+05D4 “ה”）の中心の上端をヘブライ語のhangingベースラインとみなす。
6. Ka文字の中心上端をhangingベースラインとみなす。 どのKaを使うかは内容言語による：

   言語	スクリプト	文字
   	デーヴァナーガリー	क U+0915 KA
   	ベンガル	ক U+0995
   	グルムキー	ਕ U+0A15
   	チベット	ཀ U+0F40

   デフォルトを決めること。

   

7. 課題: ここにさらに注記を追加する？

これらのヒューリスティックの妥当性チェックをお願いします。

フォールバック値の利用

以下のフォールバック値を推奨します：

• x-height: .5em;
• cap-height: .66em;
• hangingベースライン: .6em;

A.3: アトミックインラインのベースライン合成

アトミックインライン（inline-block, inline-table, 置換要素等）が、 参加するインライン整形コンテキストのインライン軸で 内容由来のbaseline setを持たない場合、 UAは以下のようにベースラインを合成して整列しなければなりません。

これらのベースラインは、 そのline-underのmargin edge上にあるとみなされます：

• text-under baseline
• ideographic-under baseline
• ideographic-ink-under baseline
• alphabetic baseline

これらのベースラインは、 そのline-underとline-overのmargin edgeの ちょうど中間点にあるとみなされます：

• central baseline
• math baseline
• x-middle baseline

これらのベースラインは、 そのline-overのmargin edge上にあるとみなされます：

• text-over baseline
• ideographic-over baseline
• ideographic-ink-over baseline
• cap-height baseline
• hanging baseline
• x-height baseline

注: 著者はmargin（正・負）を使って置換コンテンツの行内整列を調整できます。

img[src^="/text/"] {
  height: 1em; /* Adjacentテキストに合わせてサイズ調整 */
  margin-bottom: -0.2em; /* ベースラインを下端より20%上に調整 */
}
...
<p>これは未符号化文字で単語を書いたテキストです:
<img src="/text/ch3439.png" alt="...">
  <img src="/text/ch3440.png" alt="...">
  <img src="/text/ch3442.png" alt="...">

注: CSSの将来レベルでは、置換要素に完全なbaseline tableを指定する方法が追加されるかもしれません。 （この場合、baseline-tableプロパティで[<baseline-keyword> <percentage>]+のような指定ができる見込みです。）

変更点

2024年8月12日版ワーキングドラフト以降の変更：

• <text-edge>の両値を必須にした。 (Issue 10703)
• text-box-edgeを継承可能に変更； text-box-trimは 影響する行ボックスに適用された値を参照するようにした。 (Issue 10904)
• text-box-trimの 断片化分割時の挙動を定義。 (Issue 5335)
• text-box-trimの マルチカラムコンテナでの挙動を定義し、 他の整形コンテキストでも適用・伝播の明確化。 (Issue 5335, Issue 11038)
• 「invisible line boxes」をphantom line boxesに改名。 CSS2との整合性のためおよび レイアウト上で「見えない」ことを明確化。

2024年8月8日版ワーキングドラフト以降の変更：

• text-box-edgeへの 参照の一部を整理（line-fit-edgeも扱っていた時の名残）。
• text-box-edge: autoが 影響するline-fit-edgeを参照し、 指定要素のline-fit-edgeに計算しないよう調整。

2023年4月1日版ワーキングドラフト以降の変更：

• text-box-edgeを2つのプロパティに分割— text-box-edge（text-box-trimのエッジ制御用）と line-fit-edge（行ボックスサイズ制御用）を新設、 text-boxショートハンドも追加。 (Issues 8829, 8696)
• text-box-trimキーワードに trim-*プレフィックス追加。text-boxショートハンドでも意味が通るようにした。 (Issue 10675)
• 複数祖先でtext-box-trimを要求した場合、 一番内側のトリムエッジを使うように変更。 (Issue 5426)
• block-axis負のmarginを inline boxesの子孫で layout bounds計算時に適用。指定値が有効になるように。 (Issue 8182)
• phantom line boxesを inline-axisボックス装飾のみで計算するよう修正。 (Issue 9344)

2022年11月14日版ワーキングドラフト以降の変更：

• text-edgeをtext-box-edgeに、 leading-trimをtext-box-trimに改名し、 初期値も変更。 (Issue 8067)
• line gap metricをゼロで切り捨てるよう修正。 (Issue 5064)

2020年8月28日版ワーキングドラフト以降の変更：

• inline-sizingを 継承可能に修正（元々の意図通り）。 (Issue 1974)
• inline-sizingの「適用対象」からrubyボックスを除外するよう修正。
• 編集上の修正（画像追加など）。

2020年6月18日版ワーキングドラフト以降の変更：

• leading-trim祖先に非ゼロpadding/borderがあれば効果を妨げるように変更。 (Issue 5237)
• 「invisible line boxes」→phantom line boxesへ改名。
• leading値をinitial-letter-alignに追加、インド系書記体系の慣例対応。 Indic Layout Requirements参照。 (Issue 864)
• 祖先leading-trimを非ゼロpadding/borderが遮断するように修正。 (Issue 5237)
• initial-letter-alignから hebrew値を削除。 (Issue 5208)
• 頭文字サイズが沈み量より小さい場合はunder整列点を使うように変更。 (Issue 5329)
• dropped initials隣接の空白を折り畳むよう修正。 (Issue 5120)
• dropped initialsの raised initials同様の text-align処理を定義。 (Issue 5207)
• shape-margin・margin・shape-outsideの相互作用をfloatと合わせて修正（initial-letter-wrap参照）。 (Issue 5119)
• em-over・em-underベースラインの定義追加（Canvas 2D参照用）。 (Issue 5312)
• 新しいvertical-align構文の微調整。 (Issue 5235)
• baseline-shift: sub | superのフォールバックシフト定義。 (Issue 5225)

2020年6月4日版ワーキングドラフト以降の変更：

• 以前のline-sizingとtext-box-trimの関係を再設計し、 text-edgeと構造の異なるleading-trimを新設。 (Issue 5168)
• vertical-alignのline-relative shift valuesを alignment-baselineロングハンドからbaseline-shiftロングハンドへ移動。 (Issue 5180)
• text-edgeを行ボックス高計算に統合。
• 各種ベースライン定義を独立セクションに整理、[CSS-WRITING-MODES-3]から導入・統合。
• 残りのベースライン整列・行ボックスサイズ記述を[CSS2]から導入・統合。
• すべてのベースラインに対するアトミックインラインの合成ルールを定義。
• central baselineを 表意文字中心ベースラインとして明確化。
• 頭文字ボックスと後続テキスト間の空白折り畳みを定義。 (Issue 5120)
• 頭文字ボックスのボックスモデル定義強化、 包含ブロックとの相互作用含む。 (Issue 719)
• その他細かな修正・明確化・編集改善。

2018年8月8日版ワーキングドラフト以降の変更：

• line-sizingプロパティ追加、行間計算方法を制御。 (Issue 3199)
• baseline-sourceプロパティ追加、整列に使う最初／最後ベースライン制御。 (Issue 861)
• leading-trim提案追加、line-over/line-underエッジのメトリクス制御。 (Issue 3240, 3955)
• line-height定義および関連する規範的記述を[CSS2]から導入。
• § 2 インラインレイアウトモデルの高レベル記述を改善。
• initial-lettersをinitial-letterに戻した。 (Issue 862)
• raiseとsinkキーワード追加、 記法簡便化。 (Issue 2955)
• ベースラインセットを持たないアトミックインラインの合成ルール明確化。
• middle、 text-top、 text-bottomの 縦書きでの解釈を明確化。 (Issue 4495)
• text-top/text-bottom/text値を vertical-align、 dominant-baseline、 leading-trim、 インラインボックスの内容ボックス描画で一貫して解釈するよう明確化。 (Issue 3978)
• dominant-baselineの初期値を autoに修正。 (Issue 4115)
• vertical-alignのロングハンド／ショートハンドの記述を改善。
• initial-letterと float/positionの相互作用を明確化。
• § 7.5 頭文字レイアウトのセクション構成を改善、記述も明瞭化。
• shape-marginがグリフ輪郭に適用されると定義。
• ベースライン合成規則で永（U+6C38）を表意文字面端に使用。
• 頭文字は字形形成上分離されると定義。ただし後続テキストは接続形のまま。 (Issue 2399)

さらに以前の2016年5月24日版以降の変更も参照。

謝辞

初期著者Eric A. MeyerとMichel Suignardに特別な感謝を。

著者以外にも、次の方々の協力がなければ本仕様は成立しませんでした：

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。

プライバシーに関する考慮事項

本仕様に関して新たなプライバシー上の考慮事項は報告されていません。

セキュリティに関する考慮事項

本仕様に関して新たなセキュリティ上の考慮事項は報告されていません。