CSSフォントモジュール レベル3

概要

このCSS3モジュールは、フォントプロパティの指定方法とフォントリソースの動的な読み込み方法について説明します。本仕様の内容は、以前分割されていたCSS3フォントおよびCSS3 Webフォントモジュールの内容を統合したものです。フォントのロードイベントの説明はCSSフォント ローディングモジュールに移動されました。

この文書のステータス

このセクションは、本書の公開時点でのステータスを示しています。他の文書が本書に取って代わる場合があります。現行標準のW3C出版物一覧や、この技術レポートの最新版はW3C技術レポート索引（https://www.w3.org/TR/）で確認できます。

この文書はW3C会員、ソフトウェア開発者、他のW3Cグループおよび関係者によってレビューされ、ディレクターによってW3C勧告として承認されました。これは安定した文書であり、参考資料として使用したり、他の文書から引用することができます。W3Cの勧告策定における役割は、仕様への注目を集め、その広範な展開を促進することです。これによりウェブの機能性と相互運用性が向上します。

この文書はCSS作業グループによってW3C 勧告として作成されました。

この文書はW3C特許ポリシーの下で運用されているグループによって作成されました。W3Cは グループの成果物に関連して行われた特許開示の公開リストを管理しています。そのページには特許の開示方法についての案内もあります。個人が、必須クレームを含むと考える特許について実際に知っている場合、W3C特許ポリシーの第6節に従って情報を開示する必要があります。

この文書は2018年2月1日 W3Cプロセス文書に準拠しています。

テストスイート及び 実装報告 が利用可能です。

1. はじめに

フォントは、文字の視覚的な表現を含むリソースを提供します[CHARMOD][UNICODE]。最も単純なレベルでは、文字コードをそれらの文字を表す形（グリフと呼ばれる）にマッピングする情報が含まれています。共通のデザインスタイルを持つフォントは、標準フォントプロパティのセットによって分類され、フォントファミリーにまとめられることが多いです。ファミリー内では、特定の文字に表示される形状は、ストロークの太さ、傾斜、相対的な幅などによって異なる場合があります。個々のフォントフェイスは、これらのプロパティの独自の組み合わせによって記述されます。特定のテキスト範囲に対して、CSS フォントプロパティを使用してフォントファミリーとそのファミリー内の特定のフォントフェイスを選択し、そのテキストの描画に使用します。簡単な例として、Helveticaのボールド体を使用するには次のようにします。

body {
    font-family: Helvetica;
    font-weight: bold;
}

フォントリソースは、ユーザーエージェントが動作しているシステムにローカルでインストールされている場合もあれば、ダウンロード可能な場合もあります。ローカルのフォントリソースについては、記述情報をフォントリソースから直接取得できます。ダウンロード可能なフォントリソース（ウェブフォントとも呼ばれる）の場合、記述情報はフォントリソースへの参照とともに含まれます。

フォントファミリーは、通常、フォントプロパティのすべてのバリエーションごとに一つのフェイスしか含まれていません。CSSのフォント選択メカニズムは、指定されたCSSフォントプロパティのセットをどのように単一のフォントフェイスに一致させるかを説明します。

2. タイポグラフィの背景

このセクションは規範的ではありません。

タイポグラフィの伝統は世界中で異なるため、言語や文化を問わずすべてのフォントを一意に分類する方法はありません。一般的なラテン文字でさえ、多くのバリエーションが存在します：

1つの文字、さまざまなグリフのバリエーション

文字の形状（レターフォーム）の構造の違いは、フォントを区別する一つの方法です。ラテンフォントの場合、文字の主ストロークの端にある装飾（セリフ）は、セリフのないフォントと区別する特徴となります。同様の比較は、非ラテンフォントでも、先細りのストロークを持つフォントと主に均一なストロークを使用するフォントの間で見られます：

セリフあり・なしのレターフォーム

日本語書体でも同様の分類

フォントにはレターフォームと、文字をこれらのレターフォームにマッピングするためのデータが含まれています。多くの場合、これは単純な一対一のマッピングですが、より複雑なマッピングも可能です。結合記号（ダイアクリティカルマーク）の使用により、基本のレターフォームに多くのバリエーションが生まれます：

ダイアクリティカルマークによるバリエーション

文字の並びが、一つのグリフ（合字）で表現されることがあります：

合字の例

テキストの文脈に基づく視覚的変換は、ヨーロッパ言語ではしばしばスタイリッシュなオプションですが、[ARABIC-TYPO]のような言語では正しく描画するために必須です。下のlamとalef文字は、連続して現れる場合、必ず結合されなければなりません：

必須のアラビア語合字

これらの形状変換の相対的な複雑さは、フォント内に追加のデータを必要とします。

さまざまなスタイリッシュなバリエーションを持つフォントフェイスのセットは、しばしばフォントファミリーとしてまとめられます。最も単純な場合、通常体にボールド体やイタリック体が追加されるだけですが、より広範なグループ化も可能です。レターフォームのストロークの太さ（ウェイト）、レターフォーム全体の比率（幅）のバリエーションが最も一般的です。下の例では、各文字がUniversフォントファミリー内の異なるフォントフェイスを使用しています。上から下に行くにつれて幅が広くなり、左から右に行くにつれてウェイトが太くなります：

1つのフォントファミリー内でのウェイトと幅のバリエーション

複数のスクリプトをサポートするフォントを作成するのは難しい作業です。デザイナーは、異なるスクリプトのタイポグラフィの文化的伝統を理解し、共通のテーマを持つレターフォームを考案する必要があります。多くの言語は同じスクリプトを共有しますが、それぞれの言語には顕著なスタイリッシュな違いがあります。例えば、アラビア文字はペルシャ語やウルドゥー語で使用される場合、文字の形状に著しい体系的な違いが現れます。また、キリル文字もセルビア語やロシア語などの言語で使われると形状が異なります。

フォントの文字マップは、そのフォントにおける文字とグリフの対応関係を定義します。もし文書に、フォントファミリーリスト内のフォントの文字マップでサポートされていない文字が含まれている場合、ユーザーエージェントは適切なフォントを見つけるためにシステムフォントのフォールバック手続きを使うことがあります。適切なフォントが見つからない場合は、ユーザーエージェントによって「欠損グリフ」文字が描画されます。指定したフォントファミリーリストに、対象の文字をサポートするフォントが含まれていない場合、システムフォールバックが発生することがあります。

フォントの文字マップが特定の文字をその文字用のグリフにマッピングしていても、OpenType[OPENTYPE]やAAT（Apple Advanced Typography）[AAT-FEATURES]などの最新のフォント技術では、機能設定に基づいて文字を異なるグリフにマッピングする方法があります。これらのフォーマットのフォントでは、これらの機能をフォント自体に埋め込んでアプリケーションから制御することができます。この方法で指定できる一般的なタイポグラフィ機能には、合字、装飾的なスワッシュ、文脈依存の交替、プロポーショナル数字やタブ付き数字、自動分数などがあります。OpenTypeの機能のビジュアル概要については、[OPENTYPE-FONT-GUIDE]を参照してください。

3. 基本フォントプロパティ

文字の描画に使用される特定のフォントフェイスは、要素に適用されるフォントファミリーやその他のフォントプロパティによって決定されます。この構造により、各設定を独立して変更することが可能です。

3.1. フォントファミリー：font-familyプロパティ

このプロパティは、フォントファミリー名や汎用ファミリー名の優先順位付きリストを指定します。フォントファミリーは、ウェイト・幅・傾斜などが異なるフェイスのセットを定義します。CSSはファミリー名と他のスタイル属性の組み合わせを用いて個々のフェイスを選択します。この選択メカニズムを使うことで、デザインアプリケーションでよくあるスタイル名によるフェイス選択ではなく、フォールバック時にテキスト表示の規則性をある程度維持できます。

デザイナーはCSSで選択に使われるフォント属性の定義が、フォントの分類（タクソノミー）を決定するためのものではないことに留意すべきです。タイプデザイナーの考えるファミリーは、ウェイト・幅・傾斜だけでなく、他の軸でも異なるフェイスのセットに及ぶ場合があります。ファミリーは、セリフ体とサンセリフ体両方のセットを含む場合や、そのファミリー独自の軸で変化することもあります。CSSのフォント選択メカニズムは、置換が必要な場合に「最も近い」代替を決定する手段を提供するだけです。

他のCSSプロパティと異なり、コンポーネント値は代替案を示すカンマ区切りのリストです。ユーザーエージェントは、描画する文字のグリフを含む利用可能なフォントが見つかるまで、ファミリー名リストを順に調べます。これにより、プラットフォーム間のフォントの違いや、個々のフォントがサポートする文字範囲の違いに対応できます。

フォントファミリー名は、フォントフェイスのセットに付けられた名前を指定するだけで、個々のフェイスを指定するものではありません。たとえば、以下のフォントが利用可能な場合、Futuraは一致しますが、Futura Mediumは一致しません：

ファミリー名と個別フェイス名

以下の例を考えてみましょう：

body {
    font-family: Helvetica, Verdana, sans-serif;
}

フォントファミリー名には2種類あります：

<family-name>

前述の例のHelveticaやVerdanaのような、任意のフォントファミリーの名前です。

<generic-family>

以下の汎用ファミリーキーワードが定義されています：‘serif’, ‘sans-serif’, ‘cursive’, ‘fantasy’, ‘monospace’。これらのキーワードは、著者が希望するフォント選択肢が利用できない場合の一般的なフォールバック手段として使用できます。キーワードとしては、引用符で囲ってはいけません。著者は、堅牢性向上のために汎用フォントファミリーを最後の選択肢として追加することが推奨されます。

汎用ファミリー以外のフォントファミリー名は、文字列として引用符で囲むか、識別子の1つ以上の並びとして引用符なしで指定しなければなりません。つまり、引用符なしのフォントファミリー名では、ほとんどの句読点や先頭が数字のトークンはエスケープが必要です。

例えば、以下の宣言は無効です：

font-family: Red/Black, sans-serif;
font-family: "Lucida" Grande, sans-serif;
font-family: Ahem!, sans-serif;
font-family: test@foo, sans-serif;
font-family: #POUND, sans-serif;
font-family: Hawaii 5-0, sans-serif;

識別子の並びをフォントファミリー名として指定した場合、算出値はすべての識別子を単一のスペースで結合した文字列になります。

エスケープの間違いを防ぐため、空白・数字・ハイフン以外の句読点を含むフォントファミリー名は引用符で囲むことが推奨されます：

body { font-family: "New Century Schoolbook", serif }

<BODY STYLE="font-family: '21st Century', fantasy">

キーワード値（‘inherit’, ‘serif’など）と同じ名前のフォントファミリー名は、混同を防ぐために必ず引用符で囲む必要があります。UAはこれらのキーワードを<family-name>型として一致させてはいけません。これはCSS全体のすべてのキーワードに適用されます。

フォントがどのようにファミリーにまとめられるかの詳細は、プラットフォームのフォント管理APIによって異なります。WindowsのGDI APIではファミリーに4つのフェイスしかまとめられませんが、DirectWrite APIやOSX他のAPIでは様々なウェイト・幅・傾斜を持つフォントファミリーがサポートされています（詳細は付録Aを参照）。

一部のフォント形式では、ファミリー名の複数言語ローカライズを持つことができます。ユーザーエージェントは、プラットフォームのローカライズやシステムAPI、文書エンコーディングに関係なく、すべての名前を認識し正しく一致させなければなりません：

ローカライズされたファミリー名

ローカライズされたフォントファミリー名の一致方法や、大文字・小文字区別に関する詳細は、後述のフォント照合セクションで説明します。

3.1.1. 汎用フォントファミリー

5種類すべての汎用フォントファミリーは、すべてのCSS実装で必ず1つ以上一致するフォントフェイスが結果として得られる必要があります。ただし、汎用ファミリーは複合フェイス（文字のUnicode範囲や要素の言語、ユーザーの好みやシステム設定などに基づき異なる書体を使う場合など）であることがあります。また、それぞれが常に異なるとは限りません。

ユーザーエージェントは、各ファミリーの特徴を可能な限り表現する合理的な初期選択肢を提供するべきです。技術的制約がある場合でも、ユーザーが汎用フォントの代替選択肢を選べるようにすることが推奨されます。

serif

セリフ体フォントは、スクリプトの正式なテキストスタイルを表します。これは多くの場合、グリフの端に仕上げのストロークや先細り・広がりのある端、または実際のセリフ（スラブセリフを含む）があることを意味しますが、これに限りません。セリフ体フォントは一般にプロポーショナル（可変幅）です。‘sans-serif’汎用ファミリーのフォントと比べると、太い・細いストロークの差が大きい傾向があります。CSSでは‘serif’という用語を、どのスクリプトのフォントにも適用しますが、特定のスクリプトでは他の名称の方が一般的な場合もあります（日本語なら明朝、中国語なら宋体、韓国語ならバタンなど）。アラビア語では、Naskhスタイルは実際のデザインというよりもタイポグラフィ上の役割から‘serif’に対応します。以上のように表現されるフォントは、汎用‘serif’ファミリーを表すために使用できます。

セリフ体フォントの例

sans-serif

CSSで使われる「サンセリフ体」フォントのグリフは、一般的にコントラストが低く（縦横のストロークがほぼ同じ太さ）、端がシンプルで広がり・交差・装飾がありません。サンセリフ体フォントも通常プロポーショナルです。‘serif’ファミリーのフォントに比べると、太さのバリエーションは小さい傾向があります。CSSでは‘sans-serif’という用語を、どのスクリプトのフォントにも適用しますが、日本語ならゴシック、中国語ならヘイ体、韓国語ならグリムなど、他の名称が一般的な場合もあります。以上のように表現されるフォントは、汎用‘sans-serif’ファミリーを表すために使用できます。

サンセリフ体フォントの例

cursive

カ―シブ体フォントのグリフは、より非公式な筆記体スタイルを使用することが多く、印刷された文字よりも手書きのペンや筆で書かれた文字に近い見た目になります。CSSでは‘cursive’という用語を使いますが、Chancery、Brush、Swing、Scriptなどの名称もフォント名で使われます。

カ―シブ体フォントの例

fantasy

ファンタジー体フォントは、主に装飾的または表現的なフォントで、装飾的・表現的な文字表現を持っています。実際の文字を表さないPiフォントやピクチャーフォントは含みません。

ファンタジー体フォントの例

monospace

等幅フォントの唯一の条件は、すべてのグリフの幅が同じであることです。これはコンピュータコードのサンプルを描画する際によく使われます。

等幅フォントの例

3.2. フォントウェイト: font-weightプロパティ

‘font-weight’ プロパティは、フォントのグリフの太さや黒さ（ストロークの厚み）を指定します。

値の意味は以下の通りです:

100〜900

これらの値は順序付けされた系列であり、各番号は前の値より少なくとも濃いウェイトを示します。おおよそ下記の一般的なウェイト名に対応します:

• 100 - Thin（極細）
• 200 - Extra Light（ウルトラライト）
• 300 - Light（ライト）
• 400 - Normal（ノーマル）
• 500 - Medium（ミディアム）
• 600 - Semi Bold（セミボールド／デミボールド）
• 700 - Bold（ボールド）
• 800 - Extra Bold（エクストラボールド／ウルトラボールド）
• 900 - Black（ブラック／ヘビー）

normal

‘400’と同じ。

bold

‘700’と同じ。

bolder

継承値より太いウェイトを指定します。

lighter

継承値より細いウェイトを指定します。

9段階以外のスケールを使用するフォント形式は、CSSのスケールにマッピングする必要があります。例えば、400はレギュラー、ブック、ローマンなどのラベルのフェイスに、700はボールドのラベルのフェイスに概ね対応させてください。また、スタイル名からウェイトを推定する場合は、上記スケールに概ね一致するものを選びます。スケールは相対的なので、より大きいウェイト値のフェイスがより細く見えてはいけません。スタイル名からウェイトを推定する場合は、ロケールによる名称の違いにも注意してください。

特定のフォントファミリーには、利用可能なウェイトが限られている場合が多いです。指定されたウェイトに該当するフェイスが存在しない場合、近いウェイトのフェイスが使用されます。一般的に、ボールド系ウェイトはより太いフェイス、ライト系ウェイトはより細いフェイスにマッピングされます（正確な定義はフォント照合セクションを参照）。下記の例は各ウェイトにどのフェイスが使われるかを示しており、グレーはそのウェイトのフェイスが存在せず、近いウェイトのフェイスが使われることを表します:

400, 700, 900ウェイトフェイスを持つフォントファミリーのウェイトマッピング

300と600ウェイトフェイスを持つフォントファミリーのウェイトマッピング

タイポグラファーには好まれませんが、実際のボールドフェイスが存在しない場合、ユーザーエージェントがボールドフェイスを合成することがよくあります。スタイル照合の目的では、これらのフェイスはファミリー内に存在するものとして扱われます。著者がこの挙動を明示的に避けたい場合は、‘font-synthesis’プロパティを使用できます。

‘bolder’や‘lighter’の指定値は、親要素のウェイトに対する相対値を示します。算出されるウェイトは、継承された‘font-weight’値を基に、以下の表に従い計算されます。

上記の表は、ノーマルとボールドフェイス、さらに細い・太いフェイスを持つフォントファミリーがある場合に、次に相対的なbolderやlighterフェイスを選択するのと同等です。特定の要素に対してより細かくウェイト値を制御したい場合は、相対値の代わりに数値を使うことができます。

3.3. フォント幅: font-stretchプロパティ

‘font-stretch’ プロパティは、フォントファミリーから通常・凝縮・拡張フェイスを選択します。絶対キーワード値の順序は、最も狭いものから最も広いものへ、次の通りです:

• ultra-condensed
• extra-condensed
• condensed
• semi-condensed
• normal
• semi-expanded
• expanded
• extra-expanded
• ultra-expanded

指定された幅のフェイスが存在しない場合、normalやcondensed値はより狭いフェイスに、その他はより広いフェイスにマッピングされます。逆に、expanded値はより広いフェイスに、その他はより狭いフェイスにマッピングされます。下図は、さまざまな幅を持つフォントファミリーにおいて、9つのfont-stretchプロパティ設定がフォント選択にどのように影響するかを示しており、グレーは該当する幅のフェイスが存在しないため、代替幅が使われていることを表します:

凝縮・標準・拡張幅フェイスを持つフォントファミリーの幅マッピング

font stretchのアニメーション: font stretchは離散ステップで補間されます。補間は、順序付けされた値が等間隔の実数であるかのように行われます。補間結果は最も近い値に丸められ、ちょうど中間の場合は上記リストで後ろの値側に丸められます。

3.4. フォントスタイル: font-style プロパティ

‘font-style’ プロパティは、イタリックやオブリークフェイスの選択を可能にします。イタリック体は一般的に筆記体に近く、オブリーク体は通常体を傾斜させたバージョンです。オブリーク体は、通常体のグリフを人工的に傾斜させてシミュレートすることができます。下図は、Palatinoの‘a’とBaskervilleの‘N’を人工的に傾斜させたグレーのレンダリングと、実際のイタリック体の比較を示しています:

人工的な傾斜 vs 本物のイタリック体

値の意味は以下の通りです:

normal

通常フェイスとして分類されるフェイスを選択します（イタリックでもオブリークでもない）

italic

イタリックフェイスとしてラベル付けされたフォント、またはそれがない場合はオブリークフェイスを選択します

oblique

オブリークフェイスとしてラベル付けされたフォント、またはそれがない場合はイタリックフェイスを選択します

イタリックやオブリークフェイスが利用できない場合、非オブリークフェイスを人工的に傾斜させてオブリーク体を合成できます。これらの人工的なオブリーク体の使用は‘font-synthesis’プロパティで無効化可能です。オブリーク処理の詳細は明示的には定義されていません。

著者は、合成的なアプローチがキリル文字などのスクリプトには適さない場合があることも意識してください。キリル文字ではイタリック体の形が大きく異なります。合成版に頼るよりも本物のイタリックフォントを使う方が常に望ましいです。

多くのスクリプトには、通常体のテキスト内で筆記体を混ぜる伝統がありません。中国語・日本語・韓国語フォントはほぼ常にイタリックやオブリークフェイスを持ちません。複数スクリプト対応フォントでは、イタリックフェイスのグリフセットからアラビア文字など特定スクリプトが省略される場合もあります。ユーザーエージェントはシステムフォントのフォールバック対応時に、フェイス間で文字マップの仮定を慎重に扱うべきです。

3.5. フォントサイズ: font-size プロパティ

このプロパティは、フォントのグリフの希望する高さを示します。スケーラブルフォントの場合、font-sizeはフォントのEM単位にスケールファクターを掛けたものです（特定のグリフがEMボックス外にはみ出すことがあります）。非スケーラブルフォントの場合、font-sizeは絶対単位に変換され、フォントの宣言された‘font-size’と一致するように、同じ絶対座標空間でマッチングされます。値の意味は以下の通りです:

<absolute-size>

<absolute-size>キーワードは、ユーザーエージェントが計算・保持するフォントサイズテーブルのエントリを参照します。可能な値は:

[ xx-small | x-small | small | medium | large | x-large | xx-large ]

<relative-size>

<relative-size>キーワードは、フォントサイズテーブルと親要素の算出‘font-size’に対して相対的に解釈されます。可能な値は:

[ larger | smaller ]

例えば、親要素が‘medium’を持つ場合、‘larger’は現在の要素のフォントサイズを‘large’にします。親要素のサイズがテーブルエントリに近くない場合、ユーザーエージェントはテーブル間を補間したり最も近いものに丸めたりしても構いません。数値がキーワードを超えた場合はテーブル値を外挿する場合もあります。

<length-percentage>

長さ値[CSS-VALUES]は、ユーザーエージェントのフォントテーブルに依存しない絶対フォントサイズを指定します。負の長さは無効です。

パーセンテージ値は、親要素のフォントサイズに対する絶対フォントサイズを指定します。パーセンテージ値やem値の使用は、より堅牢でカスケードしやすいスタイルシートにつながります。負のパーセンテージは無効です。

次の表は、絶対サイズのスケーリングファクターおよびHTML見出し・絶対フォントサイズへのマッピングについて、ユーザーエージェント向けガイドラインを示します。‘medium’値は基準の中間値です。ユーザーエージェントはフォントや表示デバイスの種類に応じてこれらの値を微調整しても構いません。

注1. 読みやすさを保つため、これらのガイドラインを適用するUAは、コンピュータ画面でEM単位あたり9デバイスピクセル未満のフォントサイズを作成しないようにすべきです。

注2. CSS1では隣接インデックス間の推奨スケーリングファクターは1.5でしたが、ユーザー体験上大きすぎることが判明しました。CSS2ではコンピュータ画面用に1.2が推奨されましたが、小サイズでは問題が残りました。新しいスケーリングファクターはインデックスごとに異なり、より良い可読性を実現しています。

このプロパティの実際の値は、‘font-size-adjust’の数値値や特定のフォントサイズが利用できない場合などに、算出値と異なる場合があります。

子要素は算出 ‘font-size’値を継承します（そうでなければ‘font-size-adjust’の効果が累積してしまいます）。

p { font-size: 12pt; }
blockquote { font-size: larger }
em { font-size: 150% }
em { font-size: 1.5em }

3.6. 相対サイズ: font-size-adjustプロパティ

同じフォントサイズでも、フォントによって見かけのサイズや可読性が異なります。ラテン文字やキリル文字のように大文字と小文字が区別されるスクリプトでは、小文字の高さ（xハイト）が大文字に対してどれだけあるかが可読性の決め手となります。これは一般的にアスペクト値と呼ばれます。正確には、フォントのx-heightをフォントサイズで割った値です。

フォントフォールバックが発生した場合、代替フォントが希望するフォントファミリーと同じアスペクト値を持たないことがあり、可読性が低下する場合があります。‘font-size-adjust’プロパティは、フォールバック時にもテキストの可読性を保つ方法です。これはxハイトがどのフォントでも同じになるようにfont-sizeを調整します。

p {
    font-family: Verdana, Futura, Times;
}

<p>Lorem ipsum dolor sit amet, ...</p>

下図は各フォントでレンダリングされたテキストの比較です。列はそれぞれVerdana、Futura、Timesで描画したものです。各行で同じfont-size値が使われており、赤い線でxハイトの違いが示されています。上半分は同じfont-size値で描画されています。下半分も同様ですが、‘font-size-adjust’プロパティも設定されており、実際のフォントサイズがxハイトを揃えるように調整されています。下半分では小さいテキストでも各行で比較的読みやすくなっていることが分かります。

‘font-size-adjust’あり・なしのテキスト

このプロパティによって、著者は要素にアスペクト値を指定し、最初のフォントが代替されてもxハイトが保たれるようにできます。値の意味は以下の通りです:

none

フォントのxハイトを保持しません。

<number>

以下の計算式で使うアスペクト値を指定します:

c  =  ( a / a' ) s

ここで

s  =  font-size値
a  =  'font-size-adjust'プロパティで指定されたアスペクト値
a' =  実際のフォントのアスペクト値
c  =  使用する調整後のfont-size

負の値は無効です。

この値は選択されたすべてのフォントに適用されますが、通常はfont-familyリストの最初のフォントのアスペクト値を基に指定します。正しく指定すれば上記式の(a/a')項が最初のフォントでは1になり、調整は行われません。不正確に指定すると、リスト最初のフォントでの表示が‘font-size-adjust’非対応の旧UAと異なる表示になります。

‘font-size-adjust’の値は ‘font-size’の使用値に影響しますが、算出値には影響しません。最初に利用可能なフォントのフォントメトリクスに基づく相対単位（exやchなど）のサイズには影響しますが、em単位のサイズには影響しません。‘line-height’の数値値は算出‘font-size’サイズを参照するため、‘font-size-adjust’は ‘line-height’の使用値には影響しません。

CSSでは、著者はよく‘line-height’を‘font-size’の倍数で指定します。‘font-size-adjust’プロパティが使用値に影響するため、line-heightの設定に注意が必要です。line-heightを詰めすぎると、行が重なってしまう場合があります。

著者は、同じ内容を持つspanで‘font-size-adjust’プロパティを変えて比較することで、特定フォントのアスペクト値を算出できます。同じfont-sizeなら、‘font-size-adjust’値が正しければ両方のspanが揃います。

2つの枠付きspanでフォントのアスペクト値を判定します。両方とも同じ‘font-size’ですが、右側のspanのみ‘font-size-adjust’プロパティが指定されています。値0.5から始めて、枠が揃うまでアスペクト値を調整します。

p {
    font-family: Futura;
    font-size: 500px;
}

span {
    border: solid 1px red;
}

.adjust {
    font-size-adjust: 0.5;
}

<p><span>b</span><span class="adjust">b</span></p>

アスペクト値0.5のFutura

右側のボックスが左側より少し大きいので、このフォントのアスペクト値は0.5未満です。値を調整して枠が揃うようにします。

3.7. フォントプロパティのショートハンド: fontプロパティ

‘font’プロパティは、下記の説明を除き、 ‘font-style’、 ‘font-variant’、 ‘font-weight’、 ‘font-stretch’、 ‘font-size’、 ‘line-height’、 ‘font-family’ を一括で設定するためのショートハンドプロパティです。‘font-variant’プロパティの値も含められますが、CSS 2.1でサポートされているものだけです。本仕様で追加された‘font-variant’値はショートハンドでは使えません。

<font-variant-css21> = [normal | small-caps]

このプロパティの構文は、複数のフォント関連プロパティを一括指定する伝統的なタイポグラフィのショートハンド記法に基づいています。

‘font’プロパティのすべてのサブプロパティはまず初期値にリセットされます。上記以外にも‘font-size-adjust’、‘font-kerning’、‘font-variant’のサブプロパティ全て、‘font-feature-settings’も含みますが、‘font-synthesis’のみはリセットされません。その後、ショートハンドで明示的に指定された値のみが設定されます。値と初期値の詳細は前述の個別プロパティを参照してください。後方互換性のため、‘font-size-adjust’はショートハンドでは初期値以外設定できません。個別プロパティを利用してください。

p { font: 12pt/14pt sans-serif }
p { font: 80% sans-serif }
p { font: x-large/110% "new century schoolbook", serif }
p { font: bold italic large Palatino, serif }
p { font: normal small-caps 120%/120% fantasy }
p { font: condensed oblique 12pt "Helvetica Neue", serif; }

‘font-stretch’はCSS 2.1では定義されていなかったため、‘font’ルールでfont-stretch値を利用する際は、古いUA対応用のバージョンも併記してください:

p {
  font: 80% sans-serif;   /* 古いUA用 */
  font: condensed 80% sans-serif;
}

以下の値はシステムフォントを参照します:

caption

キャプション付きコントロール（ボタン、ドロップダウン等）用フォント。

icon

アイコンラベル用フォント。

menu

メニュー（ドロップダウンやメニューリスト等）用フォント。

message-box

ダイアログボックス用フォント。

small-caption

小型コントロールのラベル用フォント。

status-bar

ウィンドウのステータスバー用フォント。

システムフォントは全体としてのみ設定可能です（フォントファミリー、サイズ、ウェイト、スタイル等をまとめて設定）。個別に変更することもできます。指定した特徴を持つフォントがプラットフォームにない場合、UAは適切に代替するか（例: ‘small-caption’には‘caption’の小型版を使うなど）、UAのデフォルトフォントを使うべきです。システムフォントでも、OSのユーザー設定で個別プロパティが利用できない場合は初期値を設定します。

このプロパティが「ほぼ」ショートハンドプロパティとされる理由は、システムフォントがこのプロパティでのみ指定可能であり、‘font-family’単体では指定できないためです。つまり、‘font’でサブプロパティの合計以上のことができます。ただし、‘font-weight’等の個別プロパティは、システムフォントから取得した値で変更できます。

上記のシステムフォント用キーワードは先頭位置でのみキーワードとして扱われます。他の位置ではフォントファミリー名の一部として扱われます:

  font: menu;        /* システムメニューのフォント設定を使用 */
  font: large menu;  /* "menu"というフォントファミリーを使用 */

button { font: 300 italic 1.3em/1.7em "FB Armada", sans-serif }
button p { font: menu }
button p em { font-weight: bolder }

button p { font: 600 9pt Charcoal }

button p {
  font-style: normal;
  font-variant: normal;
  font-weight: 600;
  font-size: 9pt;
  line-height: normal;
  font-family: Charcoal
}

3.8. 合成フォントフェイスの制御: font-synthesisプロパティ

このプロパティは、フォントファミリーにボールド体やイタリック体が欠如している場合に、ユーザーエージェントがボールドやオブリークフェイスを合成できるかどうかを制御します。‘weight’が指定されていない場合、ユーザーエージェントはボールドフェイスを合成してはいけません。また‘style’が指定されていない場合、ユーザーエージェントはイタリックフェイスを合成してはいけません。‘none’の値はすべての合成フェイスを禁止します。

*:lang(ar) { font-synthesis: none; }

4. フォントリソース

4.1. @font-face規則

@font-face規則は、必要な時に自動的に取得・有効化されるフォントへのリンクを可能にします。これにより、著者は特定ページのデザイン目標に合ったフォントを選択でき、プラットフォームごとに利用可能なフォントだけに制限されることがなくなります。フォント記述子のセットにより、フォントリソースの場所（ローカルまたは外部）と個々のフェイスのスタイル特性を定義します。複数の@font-face規則を使って、様々なフェイスを持つフォントファミリーを構築できます。CSSのフォント照合規則を使い、ユーザーエージェントは必要なテキストに必要なフェイスだけを選択的にダウンロードできます。

@font-face規則は、@font-faceアットキーワードと、記述子宣言のブロックから構成されます。文法上、この仕様は以下の生成規則を定義します:

font_face_rule
  : FONT_FACE_SYM S* '{' S* descriptor_declaration? [ ';' S* descriptor_declaration? ]* '}' S*
  ;

descriptor_declaration
  : property ':' S* expr
  ;

以下の新しい定義が導入されます:

-    -|\\0{0,4}2d(\r\n|[ \t\r\n\f])?
F    f|\\0{0,4}(46|66)(\r\n|[ \t\r\n\f])?

以下の新しいトークンが導入されます:

@{F}{O}{N}{T}{-}{F}{A}{C}{E} {return FONT_FACE_SYM;}

各@font-face規則は、すべてのフォント記述子に対して、明示または暗黙的に値を指定します。規則で明示的に値が指定されていない場合は、この仕様で記載されている初期値が使われます。これらの記述子は定義された@font-face規則の範囲内のみで適用され、文書言語要素には適用されません。どの要素に記述子が適用されるかや、値が子要素に継承されるかという概念もありません。同じ@font-face規則内で記述子が複数回現れる場合、最後の宣言のみが使われ、それ以前の宣言は全て無視されます。

@font-face {
  font-family: Gentium;
  src: url(http://example.com/fonts/Gentium.woff);
}

p { font-family: Gentium, serif; }

指定された@font-face規則のセットは、その規則を含む文書内で使用可能なフォントのセットを定義します。フォント照合時には、これらの規則で定義されたフォントがシステム上の他の利用可能なフォントよりも優先されます。

ダウンロードされたフォントは、それらを参照する文書でのみ利用可能です。これらのフォントを有効化する処理は、他のアプリケーションや直接同じフォントにリンクしない文書には利用できないようにしなければなりません。ユーザーエージェントの実装者は、他文書の描画時に他のフォントがない場合にダウンロードフォントを使うことを便利と考えるかもしれませんが、これはセキュリティ上の問題（攻撃ベクトル）となるため禁止されています。これらの制限はキャッシュ動作には影響せず、フォントは他のウェブリソースと同様にキャッシュされます。

このat規則はCSSの前方互換パースルールに従います。宣言ブロック内のプロパティと同様、ユーザーエージェントがサポートしていない記述子の宣言は無視されます。@font-face規則にはfont-familyとsrc記述子が必要で、どちらかが欠けている場合、その@font-face規則はフォント照合アルゴリズムの対象として扱ってはいけません。

ユーザーエージェントがプラットフォームリソースに制限があったり、ダウンロードフォントリソースを無効化できる機能を実装している場合は、@font-face規則を単に無視します。個々の記述子の動作を仕様通り変更してはいけません。

4.2. フォントファミリー: font-family記述子

この記述子は、すべてのCSSフォントファミリー名照合に使用されるフォントファミリー名を定義します。@font-face規則の有効性には必須です。基礎となるフォントデータに含まれるフォントファミリー名を上書きします。フォントファミリー名が特定ユーザー環境で利用可能なフォントファミリー名と同じ場合、スタイルシートを使用する文書では基礎となるフォントが事実上隠されます。これにより、ウェブ著者はユーザー環境のフォントファミリー名との衝突を気にせず自由にfont-family名を選択できます。同様に、特定のフォントファミリー名に対するプラットフォームの代替は使用してはいけません。

4.3. フォント参照: src記述子

この記述子はフォントデータを含むリソースを指定します。@font-face規則の有効性には必須です。値は外部参照またはローカルインストールされたフォントフェイス名の優先順位付きカンマ区切りリストです。フォントが必要な時、ユーザーエージェントはリストされた参照を順に調べ、最初に有効化できたものを使用します。無効なデータを含むフォントや、見つからないローカルフォントフェイスは無視され、ユーザーエージェントはリストの次のフォントを読み込みます。

CSSの他のURL同様、URLは相対指定も可能で、その場合は@font-face規則を含むスタイルシートの場所から解決されます。SVGフォントの場合、URLはSVGフォント定義を含む文書内の要素を指します。要素参照が省略された場合は最初に定義されたフォントへの参照とみなされます。同様に、複数のフォントを含むフォントコンテナ形式では、ある@font-face規則ごとに一つだけフォントを読み込まなければなりません。フラグメント識別子はどのフォントを読み込むかを示すために使われ、これは[RFC8081]で定義されるPostScript名を用います。準拠したユーザーエージェントは、フラグメント識別子が不明または非対応の場合、そのフォントリソースのダウンロードをスキップしなければなりません。たとえば、OpenTypeコレクションに対応しない古いユーザーエージェントはリストの次のurlに進みます。

src: url(fonts/simple.woff);       /* スタイルシートの場所からsimple.woffを読み込み */
src: url(/fonts/simple.woff);      /* 絶対パスでsimple.woffを読み込み */
src: url(fonts/coll.otc#foo);      /* コレクションcoll.otcからfooフォントを読み込み */
src: url(fonts/coll.woff2#foo);    /* woff2コレクションcoll.woff2からfooフォントを読み込み */
src: url(fonts.svg#simple);        /* id 'simple' のSVGフォントを読み込み */

外部参照は、URLの後にそのURLで参照されるフォントリソースの形式を示すヒント（formatヒント）がオプションで続きます。formatヒントには、よく知られたフォント形式を示すカンマ区切りのformat文字列リストが含まれます。準拠したユーザーエージェントは、formatヒントが未知または非対応のフォント形式だけを示す場合、そのフォントリソースのダウンロードをスキップしなければなりません。formatヒントがない場合は、ユーザーエージェントはフォントリソースをダウンロードすべきです。

/* 可能ならWOFF2、無理ならWOFF、それ以外はOpenTypeフォントを使用 */
@font-face {
  font-family: bodytext;
  src: url(ideal-sans-serif.woff2) format("woff2"),
       url(good-sans-serif.woff) format("woff"),
       url(basic-sans-serif.ttf) format("opentype");
}

この仕様で定義されるformat文字列:

TrueTypeとOpenType[OPENTYPE]の一般的な使われ方が重複するため、formatヒントの"truetype"と"opentype"は同義とみなす必要があります。"opentype"のヒントは、PostScript CFFスタイルのグリフデータやOpenTypeレイアウト情報を含むことを意味しません（詳細は付録A参照）。

著者が特定フォントのローカルコピーを優先し、なければダウンロードしたい場合はlocal()を利用できます。local()の引数であるローカルインストール済み<font-face-name>は、ファミリー内の単一フォントフェイスを一意に識別する形式固有の文字列です。<font-face-name>の構文は、"local("と")"で囲まれた一意のフォントフェイス名です。名前は引用符で囲んでも囲まなくてもよく、引用符なしの場合は識別子の並び（空白区切り）が一つのスペースで連結された文字列になります。

/* Gentiumの通常フェイス */
@font-face {
  font-family: MyGentium;
  src: local(Gentium),    /* ローカルのGentiumを使用 */
       url(Gentium.woff); /* なければダウンロード */
}

OpenTypeやTrueTypeフォントの場合、この文字列はローカルに利用可能なフォントのPostScript名またはフルフォント名のみと照合されます。どちらの名前を使うかはプラットフォームやフォントによって異なるため、両方を記載することで確実な照合が可能です。特定フォント名へのプラットフォーム代替は使用してはいけません。

/* Gentiumのボールドフェイス */
@font-face {
  font-family: MyGentium;
  src: local(Gentium Bold),    /* フルフォント名 */
       local(Gentium-Bold),    /* PostScript名 */
       url(GentiumBold.woff);  /* なければダウンロード */
  font-weight: bold;
}

@font-face規則がファミリー内の単一フォントの特性を指定するように、local()で使う一意の名前も単一フォントフェイスを指定します。OpenTypeフォントデータで定義すると、PostScript名はフォントのnameテーブルのnameID = 6レコードにあり（詳細は[OPENTYPE]参照）、OSXでは全フォント、WindowsではPostScript CFFフォントのキーです。フルフォント名（nameID = 4）はWindowsでTrueTypeグリフのフォントの一意キーです。

OpenTypeフォントでフルフォント名の複数ローカライズがある場合は、US英語版（Windowsはlanguage ID = 0x409、Macintoshはlanguage ID = 0）またはUS英語がなければ最初のローカライズを使用します（OpenType仕様ではすべてのフォントにUS英語名を含めることが推奨されています）。システムロケールがオランダ語など他言語の場合にその言語名と照合するUAは非準拠です。これは英語優先のためではなく、フォントバージョンやOSローカライズ間での照合の一貫性を保つためです（スタイル名は多言語化されており、プラットフォームやバージョンごとに異なるため）。ファミリー名（nameID = 1）とスタイル名（nameID = 2）の連結で照合するUAも非準拠です。

これにより、通常は参照できない大きなファミリーに属するフェイスの参照も可能になります。

@font-face {
  font-family: Headline;
  src: local(Futura-Medium),
       url(fonts.svg#MyGeometricModern) format("svg");
}

@font-face {
  font-family: jpgothic;
  src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic);
}

@font-face {
  font-family: Hoefler Text Ornaments;
  /* Hoefler Text Regularと同じフォントプロパティを持つ */
  src: local(HoeflerText-Ornaments);
}

@font-face {
  font-family: SectionHeader;
  src: local("Arial Lihavoitu");  /* Arial Boldのフィンランド語フルネーム、一致しないはず */
  font-weight: bold;
}

h2 { font-family: SectionHeader, serif; }

@font-face {
  font-family: MainText;
  src: url(gentium.eot);                     /* 古いユーザーエージェント用 */
  src: local("Gentium"), url(gentium.woff);  /* src定義を上書き */
}

4.4. フォントプロパティ記述子: font-style, font-weight, font-stretch 記述子

これらの記述子は、フォントフェイスの特性を定義し、スタイルを特定のフェイスに照合する際に使われます。複数の@font-face規則で定義されたフォントファミリーに対して、ユーザーエージェントはファミリー内の全フェイスをダウンロードするか、これらの記述子を利用して文書で実際に使われているスタイルに一致するフェイスのみを選択的にダウンロードできます。これらの記述子の値は、対応するフォントプロパティと同一ですが、相対キーワード、すなわち‘bolder’や‘lighter’は許可されません。これらの記述子が省略された場合は初期値が仮定されます。

これらのフォントフェイススタイル属性の値は、基礎となるフォントデータで暗示されるスタイルの代わりに使用されます。これにより、著者は元のフォントデータの配置が異なる場合でも、柔軟な組み合わせでフェイスを構成できます。合成ボールドやオブリークを実装するユーザーエージェントは、フォントデータで暗示されるスタイル属性ではなく、記述子で必要とされた場合のみ合成スタイリングを適用しなければなりません。

このセクションで定義されているフォント記述子は、特定のファミリーに対して@font-face規則で定義されたフォント集合からフォントを選択する際に使われます。

単一の通常フェイスのみを含むファミリーを考えます:

@font-face {
  font-family: BaskervilleSimple;
  src: url(baskerville-regular.woff);
}

スタイル指定のないテキストは、@font-face規則で定義された通常フェイスで表示されます:

しかし、イタリック体は、別のイタリックフェイスが定義されていないため、ほとんどのユーザーエージェントで通常フェイスのグリフを合成的に傾斜させて表示されます:

次に、実際のイタリックフェイスが定義されているファミリーを考えます:

@font-face {
  font-family: BaskervilleFull;
  src: url(baskerville-regular.woff);
}

@font-face {
  font-family: BaskervilleFull;
  src: url(baskerville-italic.woff);
  font-style: italic;
}

2つ目の@font-face規則は、フォントリソースbaskerville-italic.woffに、ノーマルウェイト、ノーマルストレッチ、イタリックスタイルの属性を持たせています。イタリック体テキストの表示時、ユーザーエージェントはこのフォントを使用し、イタリック体に最も近いフェイスとなります。そのため、テキストはタイプデザイナーが設計したグリフで表示され、通常フェイスのグリフを合成的に傾斜させて表示することはありません:

特定のファミリー内で特定のフェイスを選択するプロセスの詳細については、フォント照合セクションを参照してください。

4.5. 文字範囲: unicode-range 記述子

この記述子は、宣言されたフォントフェイスがサポートする可能性のあるUnicode[UNICODE]コードポイントの集合を定義します。記述子の値は、カンマ区切りのUnicode範囲（<urange>）値のリストです。これらの範囲の和集合が、ユーザーエージェントが特定のテキストランに対してフォントリソースをダウンロードするかどうかを判断する際のヒントとなるコードポイント集合を定義します。

各<urange>値は、"U+"または"u+"の接頭辞に続き、以下の3つの形式のいずれかでコードポイント範囲を記述するUNICODE-RANGEトークンです。これらの形式に当てはまらない範囲は無効となり、宣言は無視されます。

単一コードポイント（例: U+416）

Unicodeコードポイント（1〜6桁の16進数）

区間範囲（例: U+400-4ff）

開始・終了コードポイントをハイフンで区切った範囲（両端含む）

ワイルドカード範囲（例: U+4??）

末尾の‘?’で任意の16進数を示すワイルドカードコードポイント集合

個々のコードポイントは、Unicodeキャラクターコードポイント[UNICODE]に対応する16進数値で記述されます。コードポイント値は0〜10FFFFの範囲でなければなりません。コードポイントの数字はASCII大文字・小文字区別なしです。区間範囲の場合、開始・終了コードポイントもこの範囲内で、終了コードポイントは開始より大きいか等しい必要があります。

‘?’付きワイルドカード範囲で先頭の数字がない場合（例: "U+???"）、これは有効で、先頭ゼロのワイルドカード範囲（例: "U+0???" = "U+0000-0FFF"）と同じ意味になります。ワイルドカード範囲がUnicodeコードポイント範囲を超える場合は無効です。そのため、最大5個まで‘?’ワイルドカード文字が許されます（UNICODE-RANGEトークン自体は6個対応）。

‘unicode-range’記述子宣言内のカンマ区切りUnicode範囲リストでは、範囲が重複しても構いません。これら範囲の和集合が、そのフォントが使用できるコードポイント集合を定義します。ユーザーエージェントは、この集合外のコードポイントに対してフォントをダウンロード・使用してはいけません。ユーザーエージェントは、同じコードポイント集合を表す異なるリストに正規化しても構いません。

関連するフォントが、‘unicode-range’記述子で定義された全てのコードポイントのグリフを持っているとは限りません。フォントが使用される際、有効文字マップは、‘unicode-range’で定義されたコードポイントとフォントの文字マップの積集合となります。これにより、著者は基礎フォントでサポートされる厳密な範囲を気にせず、広い範囲としてサポート範囲を指定できます。

4.6. 文字範囲を使った合成フォントの定義

同じファミリー・スタイル記述値に対し、異なるunicode範囲で複数の@font-face規則を定義することで、異なるフォントのグリフを異なるスクリプトに割り当てる合成フォントを作成できます。これにより、単一スクリプトのみを含むフォント（例: ラテン、ギリシャ、キリル）を組み合わせたり、著者がよく使う文字と頻度の低い文字を分割したフォントとしてセグメント化することも可能です。ユーザーエージェントは必要なフォントだけをダウンロードするため、ページ帯域幅の削減に有効です。

同じファミリー・スタイル記述値でunicode範囲が重複する@font-face規則セットの場合、ルールの定義順の逆順で評価され、最後に定義されたルールが優先されます。

特定言語や文字用の例:

unicode-range: U+A5;

単一コードポイント（円/元記号）

unicode-range: U+0-7F;

ASCII基本文字範囲

unicode-range: U+590-5ff;

ヘブライ文字範囲

unicode-range: U+A5, U+4E00-9FFF, U+30??, U+FF00-FF9F;

日本語漢字・ひらがな・カタカナ＋円/元記号

@font-face {
  font-family: BBCBengali;
  src: url(fonts/BBCBengali.woff) format("woff");
  unicode-range: U+00-FF, U+980-9FF;
}

@font-face {
  font-family: STIXGeneral;
  src: local(STIXGeneral), url(/stixfonts/STIXGeneral.otf);
  unicode-range: U+000-49F, U+2000-27FF, U+2900-2BFF, U+1D400-1D7FF;
}

@font-face {
  font-family: JapaneseWithGentium;
  src: local(MSMincho);
  /* no range specified, defaults to entire range */
}

@font-face {
  font-family: JapaneseWithGentium;
  src: url(../fonts/Gentium.woff);
  unicode-range: U+0-2FF;
}

/* フォールバックフォント - サイズ: 4.5MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansFallback.woff);
  /* no range specified, defaults to entire range */
}

/* 日本語グリフ - サイズ: 1.2MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansJapanese.woff);
  unicode-range: U+3000-9FFF, U+ff??;
}

/* ラテン・ギリシャ・キリル＋一部記号・記号 - サイズ: 190KB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSans.woff);
  unicode-range: U+000-5FF, U+1e00-1fff, U+2000-2300;
}

body { font-family: DroidSans; }

<p>This is that</p>

<p>This &#x21e8; that<p>

4.7. フォント機能: font-feature-settings 記述子

この記述子は、@font-face規則で定義されたフォントを描画する際に適用される初期設定を定義します。フォント選択には影響しません。値は、下記で定義される対応する‘font-feature-settings’プロパティと同一ですが、‘inherit’値のみ省略されます。複数のフォント機能記述子やプロパティが使われた際のテキスト描画への累積的な効果については、後述のフォント機能の解決セクションで詳述します。

4.8. フォントの読み込みガイドライン

@font-face規則は、文書内で使用された場合のみフォントリソースをダウンロードする遅延読み込みを実現するために設計されています。スタイルシートでライブラリ的に多数の@font-face規則を記述しても、ユーザーエージェントは特定ページでスタイル規則により参照されたフォントのみをダウンロードしなければなりません。定義されたすべての@font-faceフォントを、実際にページで使われているかを考慮せずに全てダウンロードするユーザーエージェントは非準拠です。文字フォールバックケースでフォントをダウンロードする場合、特定テキストランの算出‘font-family’値に含まれていればフォントをダウンロードしても構いません。

@font-face {
  font-family: GeometricModern;
  src: url(font.woff);
}

p {
  /* p要素があるページではフォントがダウンロードされる */
  font-family: GeometricModern, sans-serif;
}

h2 {
  /* h2要素があるページでは、Futuraがローカルにあってもフォントがダウンロードされる場合がある */
  font-family: Futura, GeometricModern, sans-serif;
}

ダウンロード可能なフォントが利用可能になる前にテキストコンテンツが読み込まれる場合、ユーザーエージェントはダウンロードフォントが利用できない場合と同様にテキストを描画してもよいし、フォールバックフォントでテキストを透明に描画しフォールバックフォントのフラッシュを回避してもよいです。フォントのダウンロードが失敗した場合、ユーザーエージェントは必ずテキストを表示しなければなりません。透明なまま残すのは非準拠動作です。著者は、ダウンロードフォントのメトリクスに近いフォールバックフォントをフォントリストに含めることで、大きなページ再レイアウトを避けることが推奨されます。

4.9. フォント取得要件

フォントのロードにおいて、ユーザーエージェントは@font-faceルール内で定義されたURLに対して、 可能な CORS対応フェッチメソッド（[FETCH]仕様で定義）を使用しなければなりません。フェッチ時には「Anonymous」モードを使用し、リファラーソースにはスタイルシートのURLを設定し、オリジンには含まれるドキュメントのURLを設定する必要があります。

この要件の著者への影響は、著者がクロスオリジンのロードを明示的に許可しない限り、通常フォントはクロスオリジンで読み込まれないということです。サイトはAccess-Control-Allow-Origin HTTPヘッダーを使用して、フォントデータのクロスサイト読み込みを明示的に許可できます。他のスキームについては、クロスオリジンのロードを許可する明示的なメカニズムは、可能なCORS対応フェッチメソッドで許可されている以上には定義・要求されません。

/* 同一オリジン（ドメイン、スキーム、ポートがドキュメントと一致） */
src: url(fonts/simple.woff);

/* リダイレクトなしのデータURLは同一オリジンとして扱われる */
src: url("data:application/font-woff;base64,...");

/* クロスオリジン、異なるドメイン */
/* Access-Control-Allow-Originレスポンスヘッダーが'*'に設定 */
src: url(http://another.example.com/fonts/simple.woff);

/* クロスオリジン、異なるスキーム */
/* レスポンスにAccess-Control-xxxヘッダーなし */
src: url(https://example.com/fonts/simple.woff);

/* クロスオリジン、異なるドメイン */
/* レスポンスにAccess-Control-xxxヘッダーなし */
src: url(http://another.example.com/fonts/simple.woff);

5. フォントマッチングアルゴリズム

以下のアルゴリズムは、フォントが個々のテキストランとどのように関連付けられるかを説明します。ラン内の各文字について、フォントファミリが選択され、その文字のグリフを含む特定のフォントフェイスが選択されます。

5.1. フォントファミリ名の大文字・小文字の区別

以下に示すフォントマッチングアルゴリズムの一部として、ユーザーエージェントはスタイルルールで使用されるフォントファミリ名を、その環境で利用可能なフォントに含まれる実際のフォントファミリ名や@font-faceルールで定義されたフォントファミリ名と照合しなければなりません。照合は「Default Caseless Matching」アルゴリズム（Unicode仕様 [UNICODE]）に従い、大文字・小文字を区別せずに行います。このアルゴリズムは、セクション3.13「Default Case Algorithms」で詳しく説明されています。特に、照合の際に文字列を正規化したり、言語固有の調整を適用したりせずにアルゴリズムを適用しなければなりません。このアルゴリズムで指定されるケースフォールディング方法は、Unicode Character DatabaseのCaseFolding.txtファイル内のステータスフィールド‘C’または‘F’のケースマッピングを用います。

著者にとっては、フォントファミリ名がプラットフォームフォントやスタイルシート内の@font-faceルールに存在する場合でも、大文字・小文字を区別せずに照合されることを意味します。特に合成文字（ダイアクリティカルマーク等）を使用する場合、実際のフォントファミリ名と一致する文字列になるよう注意すべきです。例えば、小文字a（U+0061）と合成リング（U+030A）を組み合わせたファミリ名は、見た目が同じでも、合成シーケンスではなく事前合成された小文字aリング（U+00E5）を使っている場合は一致しません。

実装者は、与えられた大文字・小文字区別なしの文字列比較実装がこのアルゴリズムそのものを使っていることを必ず確認しなければなりません。多くのプラットフォームの文字列照合ルーチンはロケール固有の動作をしたり、何らかのレベルで文字列正規化を行う場合があるためです [UAX15]。

5.2. フォントスタイルのマッチング

テキストラン内の特定の文字に対してフォントを選択する手順は、‘font-family’プロパティで指定されたフォントファミリを順に調べ、他のフォントプロパティに基づいて適切なスタイルのフォントフェイスを選択し、指定された文字のグリフが存在するかどうかを判断するというものです。これはフォントの文字マップを用いて行われます。文字マップは、文字をその文字のデフォルトグリフにマッピングするデータです。フォントがある文字をサポートしているとみなされるのは、(1)その文字がフォントの文字マップに含まれている場合、かつ(2)含まれるスクリプトで必要なら、その文字用のシェーピング情報が利用可能な場合です。

一部のレガシーフォントは、文字マップに特定の文字を含んでいても、テキストランの正しいレンダリングに必要なシェーピング情報（例えばOpenType レイアウトテーブルやGraphite テーブルなど）を欠いている場合があります。

基底文字の後に合成文字が続くコードポイントの並びは、やや異なる扱いを受けます。詳細はクラスターマッチングのセクションを参照してください。

この手順において、あるフォントファミリのデフォルトフェイスとは、すべてのフォントスタイルプロパティが初期値に設定されている場合に選択されるフェイスを指します。

1. ある要素に対する計算済みフォントプロパティ値を用いて、ユーザーエージェントは‘font-family’プロパティで指定された最初のファミリ名から開始します。
2. ファミリ名がジェネリックファミリキーワードの場合、ユーザーエージェントは使用すべき適切なフォントファミリ名を調べます。ユーザーエージェントは、含まれる要素の言語や文字のUnicode範囲に基づいてジェネリックフォントファミリを選択してもよいです。
3. その他のファミリ名の場合、ユーザーエージェントは、@font-faceルールで定義されたフォントの中からファミリ名を探し、次に利用可能なシステムフォントの中から探します。照合には、上記セクションで説明した大文字・小文字区別なしの比較を用います。システムに複数のローカライズされたフォントファミリ名を持つフォントがある場合、ユーザーエージェントは基盤となるシステムロケールやプラットフォームAPIに関係なく、いずれの名前も照合できなければなりません。@font-faceルールで定義されたあるフェイスのフォントリソースが利用不可または無効なフォントデータの場合、そのフェイスはファミリに存在しないものとして扱われるべきです。@font-faceルールで定義されたファミリにフェイスが存在しない場合、そのファミリは欠落しているものとみなし、同じ名前のプラットフォームフォントを照合してはなりません。
4. フォントファミリの照合が発生した場合、ユーザーエージェントはそのファミリ内のフォントフェイス集合を集め、下記の順番で他のフォントプロパティを使って集合を1つのフェイスに絞り込みます。@font-faceルールで同一フォント記述子値だが‘unicode-range’値が異なるフェイス群は、このステップでは1つの複合フェイスとみなします:
   1. ‘font-stretch’を最初に試します。照合集合に幅値が‘font-stretch’値と一致するフェイスが含まれる場合、幅値が異なるフェイスは照合集合から除外します。幅値が完全一致するフェイスがなければ、最も近い幅値が使われます。‘font-stretch’値が‘normal’または凝縮値の場合、まず狭い幅値を、次に広い幅値を調べます。‘font-stretch’値が拡張値の場合、まず広い幅値を、次に狭い幅値を調べます。この手順で最も近い幅値が決まったら、他の幅値のフェイスは照合集合から除外します。
   2. ‘font-style’を次に試します。‘font-style’値が‘italic’の場合、イタリックフェイスを最初に、次にオブリーク、次にノーマルフェイスを調べます。‘oblique’の場合、オブリークフェイスを最初に、次にイタリック、次にノーマルフェイスを調べます。値が‘normal’なら、ノーマルフェイスを最初に、次にオブリーク、次にイタリックフェイスを調べます。他のスタイル値のフェイスは照合集合から除外します。ユーザーエージェントはプラットフォームフォントファミリ内でイタリックとオブリークフェイスを区別してもよいですが、必須ではありませんので、イタリックまたはオブリークフェイスはすべてイタリックとして扱っても構いません。ただし、@font-faceルールで定義されたフォントファミリ内では、イタリックとオブリークフェイスは‘font-style’記述子値で区別しなければなりません。イタリックまたはオブリークフェイスが存在しないファミリでは、font-synthesisプロパティ値が許可する場合、人工的なオブリークフェイスを作成しても構いません。
   3. ‘font-weight’は次に照合されるため、照合集合は必ず1つのフォントフェイスに絞り込まれます。bolder/lighterの相対的なウェイトが使われている場合、継承されたウェイト値に基づいて有効なウェイトが計算されます（‘font-weight’プロパティ定義参照）。希望するウェイトと照合集合内のフェイスのウェイトを比較し、希望するウェイトが利用可能ならそのフェイスが選ばれます。そうでない場合、下記のルールでウェイトを選択します:
      • 希望するウェイトが400未満の場合、希望値未満のウェイトを降順で調べ、次に希望値より大きいウェイトを昇順で調べ、一致するまで繰り返します。
      • 希望するウェイトが500より大きい場合、希望値より大きいウェイトを昇順で調べ、次に希望値未満のウェイトを降順で調べ、一致するまで繰り返します。
      • 希望ウェイトが400の場合、まず500を調べ、次に400未満の希望値用ルールを使います。
      • 希望ウェイトが500の場合、まず400を調べ、次に400未満の希望値用ルールを使います。
   4. ‘font-size’は、UA依存の許容範囲内で照合しなければなりません。（通常、スケーラブルフォントのサイズは最近傍のピクセル値に丸められ、ビットマップフォントの場合は許容範囲が20%程度になることがあります。）他のプロパティの‘em’値等による更なる計算は、指定されたものではなく、実際に使われた‘font-size’値に基づいて行われます。

5. 照合されたフェイスが@font-faceルールで定義されている場合、ユーザーエージェントは下記の手順で1つのフォントを選択しなければなりません:

   1. フォントリソースが未ロードで、‘unicode-range’記述子値で定義された文字範囲に対象文字が含まれる場合、フォントをロードします。
   2. ダウンロード後、有効文字マップが対象文字をサポートしていれば、そのフォントを選択します。

   照合されたフェイスが複合フェイスの場合、ユーザーエージェントは@font-faceルール定義の逆順で、複合フェイス内の各フェイスに対して上記手順を使います。

   ダウンロード中、ユーザーエージェントはフォントのダウンロード完了まで待機するか、代替フォントメトリクスで一度描画してフォントがダウンロードされたら再描画することができます。

6. 一致するフェイスが存在しない場合、または一致したフェイスが描画すべき文字のグリフを含まない場合は、次のファミリ名を選択し、前の3ステップを繰り返します。ファミリ内の他のフェイスのグリフは考慮しません。唯一の例外として、ユーザーエージェントはfont-synthesisプロパティの値が許可している場合、default faceがそのグリフをサポートしていれば、合成オブリークのバージョンを代用してもかまいません。例えば、イタリックフェイスがアラビア文字用グリフをサポートしていない場合、通常フェイスの合成イタリック版を使うことができます。

7. これ以上評価するフォントファミリがなく、一致するフェイスも見つからなければ、ユーザーエージェントはシステムフォントフォールバック手順を実行して対象文字の最適な一致を探します。この手順の結果はユーザーエージェントごとに異なる場合があります。
8. 特定の文字をどのフォントでも表示できない場合、ユーザーエージェントは文字が表示されていないことを何らかの方法で示すべきです。例えば、ラストリゾートフォントを使った記号的表現や、デフォルトフォントの欠落文字グリフを表示するなどです。

この処理の最適化は、実装がアルゴリズム通りに動作する限り許可されます。照合は明確な順序で行われるため、利用可能なフォントやレンダリング技術が同じであれば、できる限り一貫した結果が得られます。

最初に利用可能なフォントは、例えばフォント相対長（‘ex’や‘ch’）や‘line-height’プロパティの定義において使用され、‘font-family’リスト（または利用可能なものがなければユーザーエージェントのデフォルトフォント）でU+0020（スペース）文字に一致する最初のフォントと定義されます。

5.3. クラスターマッチング

テキストに合成記号などが含まれる場合、理想的には基底文字と記号が同じフォントで描画されるべきです。これは記号の適切な配置を保証します。そのため、クラスタのフォントマッチングアルゴリズムは、単独文字のマッチングよりも特殊化されています。バリエーションセレクタを含むシーケンスの場合、これらは指定された文字に対する正確なグリフを示すため、ユーザーエージェントは常に適切なグリフを見つけるためにシステムフォントフォールバックを試み、その後に基底文字のデフォルトグリフを使います。

合成記号や修飾子を含むコードポイントの並びは「グラフェムクラスタ」と呼ばれます（より詳細な説明は[CSS-TEXT-3]や[UAX29]を参照）。基底文字bと合成文字c1, c2…からなるクラスタについて、クラスタ全体は以下の手順で照合されます:

1. フォントリスト内の各ファミリについて、前節で定義されたスタイル選択ルールに従いフェイスを選びます。
   1. シーケンスb + c1 + c2 …内のすべての文字がフォントで完全にサポートされていれば、そのフォントをシーケンスに選びます。
   2. 複数のコードポイントのシーケンスが1文字と正規的に等価で、フォントがその文字をサポートしていれば、そのフォントをクラスタに選び、正規等価文字に関連付けられたグリフをクラスタ全体に使います。
2. ステップ1でフォントが見つからない場合:
   1. c1がバリエーションセレクタの場合、システムフォールバックを使ってb + c1の全シーケンスをサポートするフォントを探さなければなりません。システム上に完全なシーケンスをサポートするフォントがなければ、通常の単独文字マッチング手順でbのみを照合し、バリエーションセレクタは無視します。注意:複数のバリエーションセレクタが含まれるシーケンスはエンコーディングエラーとして扱い、末尾のセレクタは無視します。[UNICODE]
   2. それ以外の場合、ユーザーエージェントはクラスタ全体をサポートするフォントをシステムフォールバックで照合しても構いません。
3. ステップ2でもフォントが見つからない場合、ステップ1の照合結果を使って、フォントリスト内で完全にサポートされる最長のシーケンスを決定し、残りの合成文字は単独文字の照合ルールで個別に照合されるよう試みます。

5.4. 文字処理に関する問題

CSSのフォントマッチングは常にUnicode文字[UNICODE]を含むテキストランに対して行われます。そのため、レガシーエンコーディングを使用する文書は、フォントを照合する前に変換済みであると仮定されます。レガシーエンコーディングおよびUnicode両方の文字マップを含むフォントの場合、レガシーエンコーディングの文字マップの内容はフォントマッチングの結果に影響を与えてはなりません。

フォントマッチング処理では、テキストランが正規化済みか非正規化か（詳細は[CHARMOD-NORM]参照）を仮定しません。フォントによっては、合成済み（事前合成）形式のみをサポートし、基底文字＋合成記号の分解されたシーケンスに対応していない場合があります。著者は、コンテンツが正規化済みか非正規化かを含め、常に内容に合わせてフォント選択を調整するべきです。

特定の文字が私用領域（Private-Use Area）Unicodeコードポイントの場合、ユーザーエージェントは‘font-family’リストで指定されたジェネリックファミリ以外のフォントファミリのみを照合しなければなりません。‘font-family’リストで指定されたファミリがそのコードポイントのグリフを含まない場合、ユーザーエージェントはその文字に対してシステムフォントフォールバックsystem font fallbackを試みるのではなく、何らかの欠落グリフ記号を表示しなければなりません。置換文字U+FFFDを照合する際、ユーザーエージェントはフォントマッチング処理を省略し、即座に欠落グリフ記号を表示しても構いません。必ずしもフォントマッチング処理で選択されるフォントのグリフを表示する必要はありません。

一般的に、あるファミリのフォントはすべて同じか類似した文字マップを持ちます。ここで説明する処理は、文字マップが大きく異なるフェイスを含むファミリにも対応できるよう設計されています。ただし、そのようなファミリを使用すると予期しない結果となる場合があることに注意してください。

5.5. CSS 2.1以降のフォントマッチングの変更点

上記のアルゴリズムはCSS 2.1とは重要な箇所で異なっています。これらの変更は、ユーザーエージェント実装間での実際のフォントマッチング挙動をより正確に反映するために行われました。

CSS 2.1のフォントマッチングアルゴリズムと比較した主な違い:

• アルゴリズムにfont-stretchの照合が含まれるようになった。
• フォントスタイルのすべての照合パターンが明確に区分された。
• スモールキャップフォント（小型大文字）はフォントマッチング処理の一部として照合されなくなり、フォント機能として扱われるようになった。
• Unicodeバリエーションセレクタの照合が必須となった。
• クラスタシーケンスは単位としてまとめて照合される。

5.6. フォントマッチング例

*:lang(ja) { font: 900 14pt/16pt "Heisei Mincho W9", serif; }
*:lang(zh-Hant-TW) { font: 800 14pt/16.5pt "Li Sung", serif; }

6. フォント機能プロパティ

現代のフォント技術は、様々な高度なタイポグラフィ機能や言語固有のフォント機能をサポートしています。これらの機能を利用することで、1つのフォントで多様な合字や文脈に応じた代替字形、スタイル違い、タブラー体やオールドスタイル数字、小型大文字、自動分数、スワッシュ、言語固有の代替字形を提供できます。著者がこれらのフォント機能を制御できるようにするため、CSS3では‘font-variant’プロパティが拡張されました。これは、スタイル上のフォント機能を制御する複数のプロパティのショートハンドとして機能します。

6.1. グリフの選択と配置

このセクションは規範的ではありません

ラテン文字表示に使われるシンプルなフォントは非常に基本的な処理モデルを採用しています。フォントは文字マップを含み、各文字をその文字のグリフにマッピングします。以降の文字のグリフは、テキストラン上で単純に並べて配置されます。OpenTypeやAAT（Apple Advanced Typography）などの現代的なフォント形式では、より高度な処理モデルが使われます。特定の文字のグリフは、その文字自身のコードポイントだけでなく、隣接する文字や言語、スクリプト、テキストに有効な機能によって選択・配置されます。フォント機能は特定のスクリプトで必須の場合や、デフォルト有効が推奨される場合、著者制御下で使うスタイリスティックな機能の場合があります。グリフの選択と配置がテキスト処理全体のどの順序で行われるか（テキスト変形、テキスト方向、テキスト整列などとの関係）は[CSS-TEXT-3]および§ テキスト処理順序で説明されています。

これらの機能の視覚的な概要は[OPENTYPE-FONT-GUIDE]を参照してください。 OpenTypeフォントのグリフ処理の詳細は[WINDOWS-GLYPH-PROC]を参照してください。

スタイリスティックなフォント機能は大きく2つのカテゴリに分類できます。カーニングや合字機能など、周囲の文脈との調和に影響するもの、そして小型大文字や下付き・上付き、代替字形など、字形の選択に影響するものです。

下記の‘font-variant’のサブプロパティは、これらのスタイリスティックなフォント機能を制御するために用いられます。これらは、アラビア語やインド系言語のテキスト表示時に用いられるOpenType機能など、特定のスクリプトの表示に必須な機能は制御しません。これらはグリフの選択と配置に影響しますが、フォントマッチングで説明したフォント選択には影響しません（CSS 2.1との互換性維持が必要な場合を除く）。

ユーザーエージェント間で一貫した動作を保証するため、個々のプロパティに対応するOpenTypeプロパティ設定を記載しており、これは規範的です。他のフォント形式を使う場合も、CSSのフォント機能プロパティ値を特定のフォント機能にマッピングする際の指針として利用すべきです。

6.2. 言語固有の表示

OpenTypeは言語固有のグリフ選択と配置もサポートしています。そのため、言語ごとに特有の表示挙動が求められる場合でも、テキストを正しく表示できます。多くの言語は共通のスクリプトを共有していますが、特定の文字の形状は言語によって異なる場合があります。例えば、いくつかのキリル文字はロシア語とブルガリア語で形状が異なります。ラテン文字では「fi」を明示的なfi合字（"i"に点がないもの）で表示することが一般的ですが、トルコ語のように点付きiと点なしiの両方を使う言語では、この合字を使わないか、点付きiを含む特別な合字を使う必要があります。下記の例はスペイン語、イタリア語、フランス語の正書法に見られるスタイリスティックな伝統に基づいた言語固有のバリエーションを示しています。

要素のコンテンツ言語が文書の言語の規則に従って判別できる場合、ユーザーエージェントはOpenTypeの言語システムをコンテンツ言語から推定し、OpenTypeフォントを使ったグリフの選択・配置時にそれを使用しなければなりません。

6.3. カーニング: font-kerningプロパティ

カーニングはグリフ間のスペーシングを文脈に応じて調整するものです。このプロパティは、フォント内の調整データを利用したメトリックカーニングを制御します。

auto

カーニングをユーザーエージェントの裁量で適用することを指定します

normal

カーニングを適用することを指定します

none

カーニングを適用しないことを指定します

カーニングデータを含まないフォントでは、このプロパティは見た目に影響しません。OpenTypeフォントのレンダリング時、[OPENTYPE] 仕様ではカーニングがデフォルトで有効にされることが推奨されています。カーニングが有効な場合、OpenTypeのkern機能が有効化されます（縦書きテキストランではvkrn機能が有効化されます）。ユーザーエージェントは、OpenType仕様で詳細に説明されているように、kernフォントテーブル内のデータのみでカーニングに対応するフォントもサポートしなければなりません。‘letter-spacing’プロパティが定義されている場合、カーニング調整はデフォルトの文字間スペースの一部とみなされ、カーニング後に文字間スペース調整が行われます。

‘auto’に設定した場合、ユーザーエージェントはカーニング適用の有無を、テキストサイズやスクリプト、その他テキスト処理速度に影響する要素に基づいて判断できます。より良いカーニングを求める著者は‘normal’を使って明示的にカーニングを有効化するべきです。同様に、パフォーマンスを優先する場合など、カーニングを無効化したい場面もあるでしょう。ただし、よく設計された現代的な実装では、カーニングの利用がテキストレンダリング速度に大きな影響を与えることはほとんどありません。

6.4. 合字（リガチャ）: font-variant-ligaturesプロパティ

合字（リガチャ）や文脈形は、グリフ同士を組み合わせてより調和したフォームを生成する方法です。

<common-lig-values>        = [ common-ligatures | no-common-ligatures ]

<discretionary-lig-values> = [ discretionary-ligatures | no-discretionary-ligatures ]

<historical-lig-values>    = [ historical-ligatures | no-historical-ligatures ]

<contextual-alt-values>    = [ contextual | no-contextual ]

個々の値の意味は以下の通りです:

normal

‘normal’は、共通のデフォルト機能が有効になることを指定します。詳細は次のセクションで説明します。OpenTypeフォントでは、共通合字と文脈形はデフォルトでオン、任意合字と歴史的合字はオフです。

none

このプロパティがカバーするすべての合字や文脈形を明示的に無効にします。合字が不要な場合、テキスト描画速度が向上する場合があります。

common-ligatures

共通合字（OpenType機能: liga, clig）の表示を有効にします。OpenTypeフォントでは、共通合字はデフォルトで有効です。

no-common-ligatures

共通合字（OpenType機能: liga, clig）の表示を無効にします。

discretionary-ligatures

任意合字（OpenType機能: dlig）の表示を有効にします。どの合字が任意かはフォントデザイナーが決定するため、著者は使用するフォントのドキュメントで任意合字を確認してください。

no-discretionary-ligatures

任意合字（OpenType機能: dlig）の表示を無効にします。

historical-ligatures

歴史的合字（OpenType機能: hlig）の表示を有効にします。

no-historical-ligatures

歴史的合字（OpenType機能: hlig）の表示を無効にします。

contextual

文脈的代替（OpenType機能: calt）の表示を有効にします。厳密には合字機能ではありませんが、合字同様、グリフ形状を周囲の文脈に調和させるためによく使われます。OpenTypeフォントではデフォルトでオンです。

no-contextual

文脈的代替（OpenType機能: calt）の表示を無効にします。

複雑なスクリプトの正しい描画に必要な必須合字（OpenType機能: rlig）は、上記設定（‘none’を含む）に影響されません。

6.5. 下付き・上付きフォーム: font-variant-positionプロパティ

このプロパティは、書体設計された下付き・上付きグリフを有効化するために使います。これらはデフォルトグリフと同じemボックス内で設計され、デフォルトグリフと同じベースライン上に配置されるよう意図されています。ベースラインのリサイズや再配置は行われません。周囲のテキストに調和し、行送りに影響を与えず、可読性を高めます。

下付きグリフ（上）と、典型的な合成下付き（下）

個々の値の意味は以下の通りです:

normal

下記の機能は有効化されません。

sub

下付きバリアント（OpenType機能: subs）の表示を有効にします。

super

上付きバリアント（OpenType機能: sups）の表示を有効にします。

下付き・上付きの意味的性質のため、連続したテキストランに対して値が‘sub’または‘super’の場合、すべての文字にバリアントグリフがない場合は、機能が適用されない場合に使うグリフの縮小形を使って合成グリフを生成すべきです。これはランごとに行い、バリアントグリフと合成グリフが混在しないようにします。OpenTypeフォントで特定文字の下付き・上付きグリフがない場合、ユーザーエージェントは必ず適切な合成グリフを生成しなければなりません。

上付きバリアントグリフ（左）、合成上付き（中央）、両者混在（右・誤り）

テキスト装飾が上付き・下付きグリフのみ含むテキストランに適用される場合、合成グリフを使って装飾位置の問題を避けることができます。

過去のユーザーエージェントは、HTMLのsub要素・sup要素に対してfont-sizeやvertical-alignを使って下付き・上付き文字を合成していました。後方互換のため、著者は[CSS3-CONDITIONAL]の条件付きルールで旧実装でも下付き・上付きが表示されるようにすることが推奨されます。

これらの要素にfont-size: smallerがよく使われるため、下付き・上付きテキストに適用される実際の縮小率はサイズにより異なります。大きいテキストでは1/3程度縮小されることが多く、小さいサイズでは縮小率はより少なくなります。これにより、小サイズでも可読性が保たれます。ユーザーエージェントは合成グリフ生成時にこの点を考慮すべきです。

OpenTypeフォント形式はOS/2 テーブル [OPENTYPE] に下付き・上付きメトリクスを定義していますが、実際には常に正確とは限らず、合成グリフ生成時に信頼できません。

著者は、フォントがサポートする文字すべてに下付き・上付きグリフがあるわけではないことに注意してください。例えばラテン数字はよく対応していますが、句読点や文字は対応していないことが多いです。このプロパティの合成フォールバック規則により、必ず表示されますが、使用フォントがすべての文字に対応バリアントを持たない場合は見た目が期待通りにならないことがあります。

このプロパティは累積的ではありません。下付き・上付き内の要素に適用しても、入れ子状にはなりません。‘sub’や‘super’値のテキストラン内画像は、‘normal’と同様に描画されます。

これらの制限のため、‘font-variant-position’はユーザーエージェントのスタイルシートでの利用は推奨されません。著者は、指定フォントで下付き・上付きに対応する狭い文字範囲のみ含む場合に利用してください。

バリアントグリフはデフォルトグリフと同じベースラインを使います。ベースライン位置の変化はなく、インラインボックスや行ボックスの高さにも影響しません。これにより、行送り（リーディング）を一定に保つ必要がある（例:多段組レイアウト等）場合に理想的です。

sub {
  vertical-align: sub;
  font-size: smaller;
  line-height: normal;
}

@supports ( font-variant-position: sub ) {

  sub {
    vertical-align: baseline;
    font-size: 100%;
    line-height: inherit;
    font-variant-position: sub;
  }

}

6.6. 大文字化: font-variant-capsプロパティ

このプロパティでは、小型大文字・小型ペティート大文字・タイトル用大文字等の代替グリフ選択が可能です。これらのグリフは周囲の通常グリフとよく馴染むよう特別に設計され、単純な縮小では損なわれるウエイトや可読性を保ちます。

個々の値の意味は以下の通りです:

normal

下記の機能は有効化されません。

small-caps

小型大文字（OpenType機能: smcp）の表示を有効にします。小型大文字グリフは通常、大文字の字形を使い小文字のサイズに縮小されます。

all-small-caps

大文字・小文字両方に小型大文字（OpenType機能: c2sc, smcp）を表示します。

petite-caps

小型ペティート大文字（OpenType機能: pcap）の表示を有効にします。

all-petite-caps

大文字・小文字両方に小型ペティート大文字（OpenType機能: c2pc, pcap）を表示します。

unicase

大文字は小型大文字、通常小文字はそのまま使う混合（OpenType機能: unic）を有効にします。

titling-caps

タイトル用大文字（OpenType機能: titl）の表示を有効にします。タイトル用大文字グリフは、通常大文字が強すぎる場合に使われるよう特別設計されています。

これらグリフの利用可否は、フォントの機能リストに該当機能が定義されているかどうかによります。ユーザーエージェントはスクリプト単位で判断してもよいですが、文字単位では判断しないでください。

フォントによっては、このプロパティの一部または全ての機能に非対応の場合があります。CSS 2.1との互換のため、‘small-caps’や‘all-small-caps’が指定されていても、フォントに小型大文字グリフがない場合、ユーザーエージェントは通常フォントの大文字グリフを小文字用に縮小して合成小型大文字を生成すべきです（‘all-small-caps’の場合は両方を置換）。

合成小型大文字と本物の小型大文字

‘font-feature-settings’プロパティは、合成小型大文字の利用可否には影響しません。

#example1 { font-variant-caps: small-caps; }
#example2 { font-variant-caps: small-caps; font-feature-settings: 'smcp' 0; }

周囲のテキストとの調和のため、これらの機能有効時にコードポイントがcaselessとみなされる場合、フォントは代替グリフを提供できますが、ユーザーエージェントは合成小型大文字生成時にcaseless用代替をシミュレートしてはならないです。

caseless文字に小型大文字・all-small-caps有効時

‘petite-caps’や‘all-petite-caps’が非対応フォント指定時は、‘small-caps’や‘all-small-caps’指定時と同様に振る舞います。‘unicase’非対応フォント指定時は、‘small-caps’が小文字化大文字のみ適用されたかのように振る舞います。‘titling-caps’非対応フォント指定時は、見た目に変化はありません。合成小型大文字グリフ使用時、上下区別のないスクリプトでは‘small-caps’，‘all-small-caps’，‘petite-caps’，‘all-petite-caps’，‘unicase’は効果がありません。

大小変換による合成小型大文字の場合、‘text-transform’プロパティで使われる変換規則と一致させてください。

最後の手段として、通常フォントの未縮小大文字グリフを小型大文字フォント用グリフに置換し、全文字を大文字で表示することができます。

略語の多いテキストの可読性向上に小型大文字活用

blockquote            { font-style: italic; }
blockquote:first-line { font-variant: small-caps; }

<blockquote>I'll be honor-bound to slap them like a haddock.</blockquote>

6.7. 数値書式: font-variant-numericプロパティ

数値の書式を制御します。下記例では、これらの値を組み合わせることで、対応フォントでタブラー体データの描画を制御できます。通常の段落文ではプロポーショナル数字を使い、表データでは桁が揃うようタブラー数字を使います:

数値スタイルの利用例

組み合わせ例:

<numeric-figure-values>   = [ lining-nums | oldstyle-nums ]

<numeric-spacing-values>  = [ proportional-nums | tabular-nums ]

<numeric-fraction-values> = [ diagonal-fractions | stacked-fractions ]

個々の値の意味は以下の通りです:

normal

下記の機能は有効化されません。

lining-nums

ライニング数字（OpenType機能: lnum）の表示を有効にします。

oldstyle-nums

オールドスタイル数字（OpenType機能: onum）の表示を有効にします。

proportional-nums

プロポーショナル数字（OpenType機能: pnum）の表示を有効にします。

tabular-nums

タブラー数字（OpenType機能: tnum）の表示を有効にします。

diagonal-fractions

斜線分数（OpenType機能: frac）の表示を有効にします。

stacked-fractions

縦積み分数（OpenType機能: afrc）の表示を有効にします。

ordinal

序数用文字（OpenType機能: ordn）の表示を有効にします。

slashed-zero

斜線付きゼロ（OpenType機能: zero）の表示を有効にします。

sup { font-variant-position: super; }
x<sup>2</sup>

.ordinal { font-variant-numeric: ordinal; }
<span class="ordinal">17th</span>

.amount { font-variant-numeric: oldstyle-nums diagonal-fractions; }

<h4>Steak marinade:</h4>
<ul>
  <li><span class="amount">2</span> tbsp olive oil</li>
  <li><span class="amount">1</span> tbsp lemon juice</li>
  <li><span class="amount">1</span> tbsp soy sauce</li>
  <li><span class="amount">1 1/2</span> tbsp dry minced onion</li>
  <li><span class="amount">2 1/2</span> tsp italian seasoning</li>
  <li>Salt &amp; pepper</li>
</ul>

<p>Mix the meat with the marinade and let it sit covered in the refrigerator
for a few hours or overnight.</p>

6.8. 東アジアテキストレンダリング: font-variant-east-asianプロパティ

東アジアテキストにおけるグリフの置き換えやサイズ調整を制御できます。

<east-asian-variant-values> = [ jis78 | jis83 | jis90 | jis04 | simplified | traditional ]

<east-asian-width-values>   = [ full-width | proportional-width ]

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

normal

下記の機能は有効化されません。

jis78

JIS78字形（OpenType機能: jp78）で描画します。

jis83

JIS83字形（OpenType機能: jp83）で描画します。

jis90

JIS90字形（OpenType機能: jp90）で描画します。

jis04

JIS2004字形（OpenType機能: jp04）で描画します。

各JISバリアントは日本の異なる国家標準で定義された字形フォームを反映しています。フォントは一般的に最新の国家標準の字形を含みますが、看板等で古いバリアントを使う必要がある場合もあります。

simplified

簡体字形（OpenType機能: smpl）で描画します。

traditional

繁体字形（OpenType機能: trad）で描画します。

‘simplified’および‘traditional’値は、時代とともに簡略化されたが、古い伝統的な字形が今も一部文脈で使われる文字についてグリフフォームを制御できます。どの文字がどの字形になるかは、フォント設計の文脈によって異なります。

full-width

全角バリアント（OpenType機能: fwid）で描画します。

proportional-width

プロポーショナル（OpenType機能: pwid）で描画します。

ruby

ルビ用バリアントグリフ（OpenType機能: ruby）の表示を有効にします。ルビテキストは通常本文より小さいため、フォントデザイナーはルビ用に可読性の高い特別なグリフを設計できます。グリフ選択のみが影響し、フォントの縮小や行レイアウトへの他の変更はありません。下記の赤いルビテキストは上がデフォルトグリフ、下がルビ用バリアントです。線の太さの違いに注目してください。

6.9. フォントレンダリング全体のショートハンド: font-variantプロパティ

‘font-variant’プロパティは、すべてのfont-variantサブプロパティのショートハンドです。値‘normal’は、‘font-variant’のすべてのサブプロパティを初期値にリセットします。‘none’は、‘font-variant-ligatures’を‘none’に設定し、他のフォント機能プロパティはすべて初期値にリセットします。他のショートハンド同様、‘font-variant’を使うと、指定されていない‘font-variant’サブプロパティは初期値にリセットされます。ただし、 ‘font-feature-settings’の値はリセットされません。

6.10. 低レベルフォント機能設定制御: font-feature-settingsプロパティ

このプロパティは、OpenTypeフォント機能に対する低レベル制御を提供します。あまり一般的でないが特定用途で必要なフォント機能にアクセスする手段です。

著者は基本的に‘font-variant’および関連サブプロパティを優先的に使用し、このプロパティは特殊なケースでのみ使うべきです。

/* 小型大文字を有効化し、第2スワッシュ代替を使用 */
font-feature-settings: "smcp", "swsh" 2;

値‘normal’は、このプロパティによるグリフ選択や配置に変化がないことを意味します。

機能タグ値の構文は以下の通りです:

<feature-tag-value> = <string> [ <integer> | on | off ]?

<string>は大文字小文字区別のOpenType機能タグです。OpenType仕様[OPENTYPE]に準拠し、タグは4文字のASCII文字列です。4文字より長い/短い、またはU+20–7E範囲外の文字を含むタグは無効です。タグはフォントで定義されていれば十分で、OpenTypeの登録済み機能に限りません。カスタム機能タグを定義する場合は、OpenType仕様タグ命名規則に従うべきです[OPENTYPE-FEATURES]。

フォントに存在しない機能タグは無視されます。ユーザーエージェントはこれらのタグに基づくフォールバック挙動を合成してはなりません。例外として、‘kern’テーブル内にカーニングデータがあり、‘GPOS’テーブルにkern機能がない場合、ユーザーエージェントはkern機能を合成的にサポートしても構いません。

一般に、著者は‘font-kerning’プロパティを使ってカーニングを明示的にON/OFFするべきです。このプロパティはどちらのタイプのカーニングデータにも常に効きます。

値がある場合、それはグリフ選択のインデックスを示します。<integer>値は0以上でなければなりません。0はこの機能を無効化します。ブール機能の場合、1で有効化。非ブール機能は1以上で有効化＆機能選択インデックス指定。‘on’は1と同義、‘off’は0と同義。値を省略した場合、1が指定されたものとみなします。

font-feature-settingsの算出値はマップなので、重複指定は保存されません。同じ軸名が複数回現れた場合、最後の値が有効です。

font-feature-settings: "dlig" 1;       /* dlig=1 任意合字を有効化 */
font-feature-settings: "smcp" on;      /* smcp=1 小型大文字を有効化 */
font-feature-settings: 'c2sc';         /* c2sc=1 caps to small caps有効化 */
font-feature-settings: "liga" off;     /* liga=0 共通合字無効化 */
font-feature-settings: "tnum", 'hist'; /* tnum=1, hist=1 タブラー数字・歴史的フォーム有効化 */
font-feature-settings: "tnum" "hist";  /* 無効、カンマ区切りリストが必要 */
font-feature-settings: "silly" off;    /* 無効、タグが長すぎる */
font-feature-settings: "PKRN";         /* PKRN=1 カスタム機能有効化 */
font-feature-settings: dlig;           /* 無効、タグは文字列でなければならない */

フォントがサポートする範囲を超える値を指定した場合の挙動は未定義です。ブール機能の場合は通常有効化、非ブール機能の場合は0相当になることが多いですが、実際の挙動はフォント設計（どの種類のlookupか）に依存します。

OpenType機能タグとして定義されていますが、他の現行標準フォント形式で機能タグを追加できる場合も将来的にあります。可能な限り、他のフォント形式の機能もOpenTypeの登録タグのパターンに従うべきです。

body { font-feature-settings: "hwid"; /* 半角OpenType機能 */ }

<p>毎日カレー食べてるのに、飽きない</p>

7. フォント機能の解決

前節で説明した通り、フォント機能は‘font-variant’や‘font-feature-settings’をスタイルルールや@font-faceルールで有効化できます。これらの設定の結合に対する解決順は以下の通りです。CSSプロパティで定義された機能は、レイアウトエンジンのデフォルト機能の上に適用されます。

7.1. デフォルト機能

OpenTypeフォントの場合、ユーザーエージェントはスクリプト・書字方向ごとにOpenTypeドキュメントで定義されたデフォルト機能を有効化しなければなりません。必須合字・共通合字・文脈形（OpenType機能: rlig, liga, clig, calt）、ローカライズフォーム（OpenType機能: locl）、合成文字・記号表示に必要な機能（OpenType機能: ccmp, mark, mkmk）はデフォルトで常に有効化されます。これらの機能は、‘font-variant’や‘font-feature-settings’が‘normal’であっても必ず有効です。個々の機能は、著者が明示的に上書きした場合（例:‘font-variant-ligatures’に‘no-common-ligatures’を指定）にのみ無効化されます。アラビア語[ARABIC-TYPO]やクメール語、デーバナーガリー等、複雑なスクリプトの正しい描画には追加機能も必要です。縦書きテキストラン内で立て字の場合、縦用代替（OpenType機能: vert）も有効化しなければなりません。

7.2. 機能の優先順位

一般的およびフォント固有のフォント機能プロパティ設定は、下記の優先順位（昇順）で解決されます。 この順序は、特定のテキストランに影響するフォント機能の統合リストを構築するために使用されます。

1. デフォルトで有効化されるフォント機能（スクリプトごとに必要な機能を含む）。
2. フォントが@font-faceルールで定義されている場合、@font-faceルール内のfont-feature-settings記述子で暗示されるフォント機能。
3. ‘font-variant’プロパティや関連する‘font-variant’サブプロパティ、およびOpenType機能を利用する他のCSSプロパティ（例: ‘font-kerning’プロパティ）によって暗示されるフォント機能。
4. ‘font-variant’や‘font-feature-settings’以外のプロパティによって決定される機能設定。 例えば、‘letter-spacing’プロパティにデフォルト以外の値を設定すると、共通合字が無効になります。
5. ‘font-feature-settings’プロパティ値によって暗示されるフォント機能。

この順序により、著者は@font-faceルール内でフォントの一般的なデフォルトを設定し、個々の要素に対してプロパティ設定で上書きできます。一般的なプロパティ設定は@font-faceルール内の設定を上書きし、低レベルのフォント機能設定は‘font-variant’プロパティ設定を上書きします。

統合されたフォント機能設定リストに同じ機能に対する複数の値が含まれる場合、最後の値が使用されます。フォントが特定の基礎的なフォント機能をサポートしていない場合、その機能が有効化されていないかのように描画されます。フォントフォールバックは発生せず、特定のプロパティで明示的に定義された場合を除き、機能の合成は行われません。

7.3. 機能の優先順位例

body {
  font-variant-numeric: proportional-nums;
}

table.prices td {
  font-variant-numeric: tabular-nums;
}

8. オブジェクトモデル

@font-faceルールの内容は、以下のCSSオブジェクトモデルへの拡張でアクセスできます。

8.1. CSSFontFaceRuleインターフェイス

CSSFontFaceRuleインターフェイスは、@font-faceルールを表します。

interface CSSFontFaceRule : CSSRule {
    readonly attribute CSSStyleDeclaration style;
};

付録A: プラットフォームフォントプロパティとCSSプロパティの対応

この付録は他のセクションで説明される問題や状況の背景として含まれています。参考情報としてのみご覧ください。

CSSのフォントプロパティは、使用する基盤フォント形式から独立して設計されています。ビットマップフォント、Type1フォント、SVGフォント、一般的なTrueTypeやOpenTypeフォントにも適用可能です。しかし、TrueTypeやOpenType形式の側面には、著者が混乱しやすく、異なるプラットフォームで実装者に課題を与えるものもあります。

TrueType [[TRUETYPE]]は元々Appleによって開発され、画面と印刷両方のためのアウトラインフォント形式として設計されました。MicrosoftはAppleと共同でTrueType形式の開発に参加し、両プラットフォームはそれ以降TrueTypeフォントをサポートしています。TrueType形式のフォントデータは、共通の4文字タグ名で区別される一連のテーブルから成り、それぞれ特定の種類のデータを格納します。例えば、著作権やライセンス情報を含む命名情報は‘name’テーブルに格納されます。文字マップ（‘cmap’）テーブルには文字エンコーディングからグリフへの対応表が含まれています。Appleは後にタイポグラフィ機能を強化するための追加テーブルを導入し、これらは現在Apple Advanced Typography（AAT）フォントと呼ばれています。MicrosoftとAdobeは高度なタイポグラフィのために別のテーブル群を開発し、その形式をOpenType[OPENTYPE]と呼称しました。OpenType仕様はISOでOpen Font Format[OPEN-FONT-FORMAT]として標準化されています。

多くの場合、Microsoft WindowsやLinuxで使われるフォントデータは、AppleのMac OS Xで使われるデータとやや異なります。これはTrueType形式がプラットフォーム間で明示的なバリエーションを許容していたためです。フォントメトリクス、名前、文字マップデータなどが含まれます。

特に、フォントファミリ名データはプラットフォームごとに扱いが異なります。TrueTypeとOpenTypeフォントでは、これらの名前は‘name’テーブルのname ID 1のレコードに含まれます。異なるローカル向けに複数の名前を格納できますが、Microsoftは米国英語版の名前を必ず含めることを推奨しています。Windowsでは、互換性のためにこのファミリ名を最大4フェイスに制限するという決定がなされており、より大きなグループには「preferred family」（name ID 16）や「WWS family」（name ID 21）が利用できます。OSXなど他のプラットフォームにはこの制限がなく、ファミリ名がすべてのグループ定義に使われます。

他のnameテーブルデータは、ファミリ内の特定フェイスを一意に識別するための名前を提供します。フルフォント名（name ID 4）やPostscript名（name ID 6）は1つのフェイスを一意に表します。例えば、Gill Sansファミリのボールドフェイスはフルネームが「Gill Sans Bold」、Postscript名が「GillSans-Bold」となります。あるフェイスに対して複数の言語版フルネームが存在し得ますが、Postscript名は常に限定されたASCII文字で構成された一意の名前です。

様々なプラットフォームで、異なる名前がフォント検索時に使われます。例えば、WindowsのGDI CreateIndirectFont APIではファミリ名またはフルネームでフェイスを検索できますが、Mac OS XではCTFontCreateWithName APIでフルネームやPostscript名を使ってフェイス検索します。Linuxではfontconfig APIがこれらの名前でフォント検索を可能にします。プラットフォームAPIが自動的に他のフォントを代替する場合、返されたフォントが指定名と一致するか確認する必要があることもあります。

あるフェイスのウェイトは、OS/2テーブルのusWeightClassフィールドやスタイル名（name ID 2）から判定できます。同様に、幅もOS/2テーブルのusWidthClassやスタイル名から判定可能です。Windows GDI APIで200以下のウェイトを持つ太字合成の歴史的な理由から、フォントデザイナーはOS/2テーブルの値を調整してこれらのウェイトを避けることがあります。

タイ語、アラビア語、デーバナーガリーなど文脈的なシェーピングを用いる複雑なスクリプトのレンダリングには、OpenTypeまたはAATフォントにのみ存在する機能が必要です。現状では、WindowsとLinuxではOpenTypeフォント機能で複雑スクリプトがレンダリングされ、Mac OS XではOpenTypeとAAT両方のフォント機能が利用されます。

変更点

2018年8月14日CSS Fonts 3提案勧告からの変更点

• 変更履歴でCSS Fonts 4に移動と記載された機能は、対応する仕様の該当セクションへのリンクに変更
• W3C勧告用の日付・定型文更新
• Unicodeの参照を最新バージョンに更新
• 本変更点セクションを更新

2018年3月15日CSS Fonts 3候補勧告からの変更点

• ‘font-variant’記述子が、実装不足のためCSS Fonts 4に移動
• ‘font-feature-values’ at-ruleが、実装不足のためCSS Fonts 4に移動
• 未知のフラグメント識別子の扱いについて明確化
• 長さ・パーセンテージの定義はCSS Values & Unitsへのリンクに変更

2013年10月CSS3 Fonts候補勧告からの変更点

• ‘font-language-override’プロパティがCSS Fonts 4に移動
• CSSFontFeatureValuesRuleインターフェイスがCSS Fonts 4に移動
• CSSFontFaceRuleインターフェイスがDOM Level 2 styleで広く実装されているものに戻された
• ジェネリックフォントファミリが複合フェイスになり得ることを明確化
• 「最初に利用可能なフォント」はU+0020（スペース）文字に一致するフォントであることを明確化
• 小型大文字合成と‘font-feature-settings’の相互作用を明確化
• すべてのCSSキーワードを無効なフォントファミリ名としてマーク
• ‘font-synthesis’は‘font’ショートハンドでリセットされないことを明確化
• 「system fonts」ではなく「installed fonts」と表記
• font-family:やsrc:がない不正な@font-faceルールもDOMには現れるが、フォント選択には影響しないことを明確化
• 絶対キーワードサイズ変更時の相対サイズの比率範囲を明確化
• font-variation-settingsとfont-feature-settings両方で、算出値はマップ（重複指定は除去）であることを明確化
• ‘font-variant-position’値の省略分を‘font-variant’ショートハンドに追加
• font-size-adjustの負値、および負のパーセンテージfont-size値を無効化
• ユーザーエージェントがOS/2テーブルの下付き・上付きメトリクスを必ず使う必要はないことを明確化
• CSS Text order of operationsへの参考リンク追加
• RFC 8081（font top-level type）への規範リンク追加
• 細かな編集修正

謝辞

Tal Leming、Jonathan Kew、Ken Lunde、Christopher Slyeに感謝します。John HudsonはOpenType言語タグの微妙な点やビザンチン印章の表示例を丁寧に説明してくださいました。Ken LundeとEric MullerはCJK OpenType機能やUnicodeバリエーションセレクタについての貴重なフィードバックを提供してくれました。‘font-variant’サブプロパティによるフォント機能サポートのアイデアは、Håkon Wium Lie、Adam Twardoch、Tal Lemingから生まれました。Elika Etemadは@font-feature-valuesルールの設計案を提供してくれました。Ed Interlockの任意合字例利用を許可してくれたHouse Industriesにも感謝します。

Robert Bringhurstに感謝します。彼の著書The Elements of Typographic Styleは素晴らしい啓発をもたらしました。

適合性

文書規約

適合性要件は記述的な主張とRFC 2119の用語を組み合わせて表現されています。規範的な部分で使われる「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」はRFC 2119の記述通りに解釈されますが、可読性のためすべて大文字では記載されていません。

この仕様書の全テキストは、明示的に非規範、例、注記とマークされているセクション以外、規範的です。[RFC2119]

この仕様の例は、「for example」という語で導入されるか、class="example"で規範テキストから区別されます。例:

参考注記は「Note」で始まり、class="note"で規範テキストから区別されます。例:

Note、これは参考注記です。

適合クラス

CSS Fonts Level 3 Moduleへの適合性は3つの適合クラスで定義されます:

スタイルシート

CSSスタイルシート。

レンダラー

UA（スタイルシートの意味を解釈し、それを利用する文書を描画するもの）。

オーサリングツール

UA（スタイルシートを書き出すもの）。

スタイルシートがCSS Fonts Level 3 Moduleに適合するためには、このモジュールで定義されたプロパティを使った宣言が、汎用CSS文法および各プロパティ固有の文法に従って有効な値である必要があります。

レンダラーがCSS Fonts Level 3 Moduleに適合するためには、適切な仕様書で定義されたようにスタイルシートを解釈することに加え、CSS Fonts Level 3 Moduleで定義されたすべての機能を正しく解析・描画する必要があります。ただし、デバイスの制限によって文書を正しく描画できない場合でも、UAが非適合とみなされるわけではありません（例:白黒モニターで色を描画する必要はありません）。

オーサリングツールがCSS Fonts Level 3 Moduleに適合するためには、汎用CSS文法および本モジュール内各機能の個別文法に従って文法的に正しいスタイルシートを書き出し、他のスタイルシート適合要件も満たす必要があります。

部分的な実装

著者が将来互換性のあるパース規則を利用しフォールバック値を割り当てられるよう、CSSレンダラーは、未サポートのat-rule、プロパティ、プロパティ値、キーワード、その他の構文要素は必ず無効として（適切に無視）扱う必要があります。特に、ユーザーエージェントは決して未サポートの値のみ選択的に無視したり、1つの複数値プロパティ宣言でサポート値だけを有効にしてはなりません。CSSでは、いずれかの値が無効（未サポート値は必ず無効）とみなされた場合、宣言全体が無視されます。

実験的な実装

将来のCSS機能との衝突を避けるため、CSS2.1仕様は、CSSへの独自・実験的な拡張のため接頭辞付き構文を予約しています。

W3Cプロセスで現行標準候補（Candidate Recommendation）段階に至るまで、CSS機能のすべての実装は実験的とみなされます。CSSワーキンググループは、W3C Working Draftを含め、こうした機能の実装にはベンダー接頭辞付き構文の使用を推奨しています。これにより、将来のドラフト変更との非互換を避けられます。

非実験的な実装

仕様が現行標準候補（Candidate Recommendation）段階に至ると、非実験的な実装が可能となり、実装者は仕様通りに正しく実装されたことを証明できるCRレベルの機能については、非接頭辞付き実装を公開すべきです。

CSSの相互運用性を確立・維持するため、CSSワーキンググループは、非実験的CSSレンダラーに対し、任意のCSS機能の非接頭辞付き実装を公開する前に、実装報告書（必要に応じてそのテストケース）をW3Cへ提出するよう要請しています。W3Cへ提出されたテストケースはCSSワーキンググループで審査・修正される場合があります。

テストケースや実装報告書の提出方法については、CSSワーキンググループWebサイトhttps://www.w3.org/Style/CSS/Test/を参照してください。質問はpublic-css-testsuite@w3.orgメーリングリストへどうぞ。

参考文献

規範参考文献

[CSS-VALUES]

Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3 2016年9月29日. CR. URL: https://www.w3.org/TR/css-values/

[FETCH]

Fetch. WhatWG現行標準. URL: https://fetch.spec.whatwg.org/

[OPENTYPE]

OpenType specification. Microsoft. URL: http://www.microsoft.com/typography/otspec/default.htm

[OPENTYPE-FEATURES]

OpenType feature registry. Microsoft. URL: http://www.microsoft.com/typography/otspec/featurelist.htm

[RFC2119]

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt

[RFC8081]

C. Lilley. The "font" Top-Level Media Type. 2017年2月. Proposed Standard. URL: https://tools.ietf.org/html/rfc8081

[UAX15]

Mark Davis; Ken Whistler. Unicode Normalization Forms. 2012年8月31日. Unicode Standard Annex #15. URL: http://www.unicode.org/reports/tr15/

[UNICODE]

Unicode標準 URL: http://www.unicode.org/versions/latest

その他の参考文献

[AAT-FEATURES]

Apple Advanced Typography font feature registry. Apple. URL: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html

[ARABIC-TYPO]

Huda Smitshuijzen AbiFares. Arabic Typography: A Comprehensive Sourcebook. Saqi Books. 2001. ISBN 0-86356-347-3.

[CHARMOD]

Martin J. Dürst; et al. Character Model for the World Wide Web 1.0: Fundamentals. 2005年2月15日. W3C勧告. URL: http://www.w3.org/TR/2005/REC-charmod-20050215/

[CHARMOD-NORM]

Addison Phillips. Character Model for the World Wide Web: String Matching. 2018年4月20日. W3C作業草案. (進行中) URL: https://www.w3.org/TR/2018/WD-charmod-norm-20180420/

[CSS-TEXT-3]

Elika J. Etemad / fantasai; Koji Ishii. CSS Text Module Level 3. 2017年8月22日. W3C作業草案. (進行中) URL: https://www.w3.org/TR/2017/WD-css-text-3-20170822/

[CSS3-CONDITIONAL]

L. David Baron. CSS Conditional Rules Module Level 3. 2013年4月4日. W3C現行標準候補. (進行中) URL: http://www.w3.org/TR/2013/CR-css3-conditional-20130404/

[OPEN-FONT-FORMAT]

Information technology — Coding of audio-visual objects — Part 22: Open Font Format. 国際標準化機構. ISO/IEC 14496-22:2009. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052136_ISO_IEC_14496-22_2009%28E%29.zip

[OPENTYPE-FONT-GUIDE]

OpenType User Guide. FontShop International. URL: http://www.fontblog.de/wp-content/uploads/2015/11/FF_OTF_user_guide.pdf

[TRUETYPE]

TrueType™ Reference Manual. Apple. URL: https://developer.apple.com/fonts/TrueType-Reference-Manual/

[UAX29]

Mark Davis. Unicode Text Segmentation. 2012年9月12日. Unicode Standard Annex #29. URL: http://www.unicode.org/reports/tr29/

[WINDOWS-GLYPH-PROC]

John Hudson. Windows Glyph Processing. Microsoft Typography. URL: http://www.microsoft.com/typography/developers/opentype/default.htm

索引

• 100...900 ウェイト値, 3.2.
• <absolute-size>, 3.5.
• all-petite-caps, 6.6.
• all-small-caps, 6.6.
• aspect値, 3.6.
• authoring tool, ??
• auto
  • font-kerning, 6.3.
• bold, 3.2.
• bolder, 3.2.
• character map, 5.2.
• common-ligatures, 6.4.
• <common-lig-values>, 6.4.
• composite face, 5.2.
• condensed, 3.3.
• contextual, 6.4.
• <contextual-alt-values>, 6.4.
• CSSFontFaceRule, 8.1.
• cursive, 定義, ??
• default face, 5.2.
• descriptor_declaration, 4.1.
• diagonal-fractions, 6.7.
• discretionary-ligatures, 6.4.
• <discretionary-lig-values>, 6.4.
• <east-asian-variant-values>, 6.8.
• <east-asian-width-values>, 6.8.
• effective character map, 4.5.
• expanded, 3.3.
• extra-condensed, 3.3.
• extra-expanded, 3.3.
• <family-name>, 3.1.
• fantasy, 定義, ??
• <feature-tag-value>, 6.10.
• first available font, 5.2.
• font, 3.7.
• @font-face, 4.1.
• <font-face-name>, 4.3.
• font_face_rule, 4.1.
• FONT_FACE_SYM, 4.1.
• font-family
  • 記述子, 4.2.
  • プロパティ, 3.1.
• font-feature-settings
  • 記述子, 4.7.
  • プロパティ, 6.10.
• font-kerning, 6.3.
• font-size, 3.5.
• font-size-adjust, 3.6.
• font-stretch
  • 記述子, 4.4.
  • プロパティ, 3.3.
• font-style
  • 記述子, 4.4.
  • プロパティ, 3.4.
• font-synthesis, 3.8.
• font-variant
  • プロパティ, 6.9.
• font-variant-caps, 6.6.
• <font-variant-css21>, 3.7.
• font-variant-east-asian, 6.8.
• font-variant-ligatures, 6.4.
• font-variant-numeric, 6.7.
• font-variant-position, 6.5.
• font-weight
  • 記述子, 4.4.
  • プロパティ, 3.2.
• full-width, 6.8.
• <generic-family>, 3.1.
• historical-ligatures, 6.4.
• <historical-lig-values>, 6.4.
• italic, 3.4.
• jis04, 6.8.
• jis78, 6.8.
• jis83, 6.8.
• jis90, 6.8.
• lighter, 3.2.
• lining-nums, 6.7.
• monospace, 定義, ??
• no-common-ligatures, 6.4.
• no-contextual, 6.4.
• no-discretionary-ligatures, 6.4.
• no-historical-ligatures, 6.4.
• none
  • font-kerning, 6.3.
  • font-size-adjust, 3.6.
  • font-variant, 6.9.
  • font-variant-ligatures, 6.4.
• normal
  • font-feature-settings, 6.10.
  • font-kerning, 6.3.
  • font-stretch, 3.3.
  • font-style, 3.4.
  • font-variant, 6.9.
  • font-variant-caps, 6.6.
  • font-variant-east-asian, 6.8.
  • font-variant-ligatures, 6.4.
  • font-variant-numeric, 6.7.
  • font-variant-position, 6.5.
  • font-weight, 3.2.
• <number>, 3.6.
• <numeric-figure-values>, 6.7.
• <numeric-fraction-values>, 6.7.
• <numeric-spacing-values>, 6.7.
• oblique, 3.4.
• oldstyle-nums, 6.7.
• ordinal, 6.7.
• petite-caps, 6.6.
• proportional-nums, 6.7.
• proportional-width, 6.8.
• <relative-size>, 3.5.
• renderer, ??
• ruby, 6.8.
• sans-serif, 定義, ??
• semi-condensed, 3.3.
• semi-expanded, 3.3.
• serif, 定義, ??
• simplified, 6.8.
• slashed-zero, 6.7.
• small-caps, 6.6.
• src, 4.3.
• stacked-fractions, 6.7.
• style sheet
  • 適合クラスとして, ??
• sub, 6.5.
• super, 6.5.
• support, 5.2.
• system font fallback, 5.2.
• tabular-nums, 6.7.
• titling-caps, 6.6.
• traditional, 6.8.
• ultra-condensed, 3.3.
• ultra-expanded, 3.3.
• unicase, 6.6.
• unicode-range, 4.5.
• <urange>, 4.5.
• weight, 2.
• width, 2.

プロパティ索引