読者がページを利用するために文字を必要とする場合は、すぐに代替テキストを表示しましょう。一時的な非表示を選ぶのは、フォントに依存する小さな要素に正当な理由がある場合だけにしてください。Macで管理しているページを対象に、このガイドでは、方針の選び方とテキストの流れへの影響を検証する方法を説明します。

フォントの読み込み中に実際に何が変わるのか

代替フォントは、要求されたフォントを利用できない間、同じテキストを別の書体で表示します。一時的に非表示にされたテキストは、フォント読み込みのブロック期間に対応します。この間、ブラウザーは見えない代替書体でレイアウトを行います。読み込みのタイムラインは、ブラウザーがダウンロード可能な書体を初めて使おうとした時点で始まります。MDNのfont-displayリファレンスでは、これらの段階が説明されています。

ページを確認する際には、この違いが重要です。見出しが空白でも、最終的な寸法が確保されているとは限りません。ブロック期間中、ブラウザーは引き続き代替フォントでレイアウトを行います。文字を隠しても、ダウンロードしたフォントで最終的にどこで改行されるかは確定しません。表示状態とレイアウトの安定性は別々に判断してください。

該当する制御項目は、font-displayというディスクリプターです。これは@font-faceルールの中に記述します。通常の段落セレクターに記述するものではありません。これはページ作成時に決める項目です。管理しているページで利用できるスタイルシートやフォント設定を使ってください。MDNのfont-displayの適用箇所に関する説明。

読者の用途に合うfont-displayの値はどれか

編集する前に、2点を決めてください。別のフォントでも文字をすぐに表示するべきか、また後からそのフォントに置き換わってもよいか、という点です。次の表は、文書化された読み込み期間を、架空の一般公開ページに適した選択肢に置き換えたものです。MDNによる各値の説明では、基本的な動作が解説されています。

値 書体を利用できない間 代替フォントに置き換わる期間 選択の出発点として適する用途
swap ごく短時間ブロックした後、代替フォントを表示 無期限の置き換え期間 指定した書体が重要な短い見出し
fallback ごく短時間ブロックした後、代替フォントを表示 短い置き換え期間 早い段階での切り替えを許容できる読書用テキスト
optional ごく短時間ブロック 置き換え期間なし 最初に表示されたフォントを維持することが最も重要なテキスト
block 短いブロック期間中は代替フォントを非表示にし、その後表示 無期限の置き換え期間 特定のフォントに依存する小さな要素
auto ブラウザーが選択する方針 ブラウザーが選択する方針 ブラウザーの既定の動作を受け入れる場合

これらは方針の分類であり、設定可能な正確なタイマーではありません。W3Cの現行のCSS Fonts Level 4作業草案では標準的な期間が推奨されていますが、ブラウザーごとの差も明示的に認められています。また、blockの使用は、特定のフォントが使いやすさに必要な、少量のテキストに限られます。見出しの見た目を優先するだけでは、見出しを空白にする理由として不十分です。W3C：フォントフェイスごとの表示制御。

「Sample Collection」という見出し、「Section One」というナビゲーション項目、そして複数の段落がある架空のページなら、読書用テキストにはまずfallbackを検討します。指定書体を最終的に使えることが重要な場合は、短い見出しにswapを検討してください。最初に表示された描画を維持することを優先する場合は、optionalを選びます。これらの推奨は、文書化された方針を読者の用途に当てはめたもので、測定結果ではありません。

表示状態と再レイアウトの判断材料を使う

テキストの役割ごとに評価してください。ナビゲーションラベルと段落で同じフォントファミリーを使っていても、それぞれのレイアウト上の制約は異なります。確認すべきなのは、フォントの変更によって作業を続けられなくなるのか、それとも見た目が変わるだけなのかです。

  1. 代替フォントでページを読む。 「Section One」を理解し、見出しを認識して、段落を読めるでしょうか。できるなら、代替フォントを表示する方針は有力な出発点です。
  2. フォントが置き換わる様子を確認する。 見出しに1行増えるでしょうか。ラベルが折り返されるでしょうか。次の段落が移動するでしょうか。
  3. 許容できる置き換え期間を選ぶ。 遅れて置き換わってもよい場合はswap、早い段階での置き換えだけを許容する場合はfallback、最初に表示されたフォントを維持する場合はoptionalを使います。
  4. テキストを空白にする具体的な理由を求める。 blockを選ぶ前に、代替フォントでは何が使えなくなるのか、またその依存をなくせない理由を特定してください。

たとえば、「Sample Collection」が代替フォントでは1行、ダウンロードしたフォントでは2行になるとします。見出しの行の高さが仮に40ピクセルで、間隔が変わらないなら、追加された行によって高さは40ピクセル増えます。その分、下のコンテンツも移動する可能性があります。これらは説明用の仮定であり、ブラウザーでの測定値ではありません。

一時的に非表示にしても、この不一致は解消されません。現実的な選択肢は、代替フォントとの一致度を高めること、テスト後にレイアウトを調整すること、または遅れて置き換わる事態を避ける方針を選ぶことです。現行のW3C草案のoptionalの動作では、代替テキストが一度描画された後、ページを表示している間はオプションの書体に置き換わりません。W3Cによるoptionalの定義。

Macで選択内容を適用してテストする方法

スタイルシートを編集でき、既存のWebフォントが正常に読み込まれるページを使います。この比較では、そのページが実際に参照しているフォントファイルをそのまま使います。新しいフォントのダウンロードや代替アセットは必要ありません。

ページのソースのスタイルシート、またはサポートされているフォント設定から、該当する@font-face宣言を見つけます。そのfont-displayディスクリプターに、font-display: fallback;のような候補の値を設定します。ウェイトやスタイルに関する他の宣言も確認し、ページが実際に要求する書体がテスト対象になるようにします。ディスクリプターの配置はMDNのfont-displayの例で確認できます。

MacのChromeでCommand + Option + Iを押すと、DevToolsが開きます。あるいは対象のテキストを右クリックしてInspectを選びます。Elementsパネルには、適用されたCSSがStylesに表示されます。ChromeのDevToolsを開く手順には、両方の方法が記載されています。

スタイルシートを変更するたびに、次の比較を実施してください。違いをフォント読み込み方針によるものと判断できるよう、ウィンドウ幅とズームを一定に保ちます。

  1. Networkを開き、Disable cacheを有効にし、Throttlingメニューから遅いプリセットを選んで再読み込みします。フォントのリクエストに注目するには、Fontフィルターを使います。
  2. 見出し、ナビゲーション、段落の冒頭を観察します。テキストが最初に空白になるか、代替フォントで表示されるか、その後に改行位置が変わるかを記録します。
  3. 切り替わりが速すぎて確認できない場合は、Networkパネルの設定でCapture screenshotsを有効にして再読み込みし、読み込みの流れを確認します。
  4. スロットリングを無効にして、Disable cacheを解除します。もう一度再読み込みして、通常の条件での再訪時と比較します。ChromeのNetwork機能リファレンスに、これらの設定が記載されています。

フォントを利用できない場合の結果は、別途テストします。Networkで実際のフォントリクエストを右クリックしてBlock requestを選び、再読み込みします。Chromeでは、該当するパターンがRequest conditionsに表示されます。文字が読める状態になり、代替フォントでもページを利用できることを確認します。テスト後は、パターンを削除するか無効にしてください。ChromeのRequest conditionsに関するドキュメントでは、リクエストのブロック方法と、ブロックされたリクエストの確認方法が説明されています。

想定するMacの閲覧環境にSafariが含まれる場合は、Safariでもページを確認します。Chromeでのテスト結果はそのブラウザーの描画に関する根拠として扱ってください。仕様ではブラウザー間の差が認められているため、他のブラウザーでもタイミングが同じだという証明にはなりません。ブラウザー、候補の値、最初の表示状態、観察された折り返しを簡単に記録しておきます。

代替フォントの表示でレイアウトが大きく変わる場合は？

実際のテキストと利用可能な幅から始めます。短いラベル、最も長い見出し、段落の数行を比較してください。Webフォントに見た目が似ている代替フォントでも、文字の送り幅が異なり、折り返し位置が変わることがあります。

より近づけるには、size-adjustを使って、グリフのアウトラインや送り幅を含むメトリクスを調整できます。MDNでは、ローカルの代替フォントフェイスを定義し、主要なWebフォントとの一致度を高める調整方法が示されています。実際に使うフォントの組み合わせに合うパーセンテージを決めてください。ドキュメントの例にある値が、どの環境にも共通する設定ではありません。MDN：size-adjust。

垂直方向のメトリクスは、別途確認する必要があります。ascent-overrideディスクリプターは、行ボックスのレイアウトに使われるベースラインより上のメトリクスを制御しますが、MDNでは現在、対応状況が限定的とされています。この調整は機能強化として扱い、対応していないブラウザーでも読みやすい代替フォントのレイアウトを維持してください。MDN：ascent-override。

テキストのシェーピングはブラウザーに任せてください。文字を一つずつ置き換えたり測定したりして、見出しを安定させようとしないでください。CSSのフォント照合では、基底文字と結合文字のような書記素クラスタが特別に扱われます。実際のレイアウトで、ラベルや行全体を確認してください。W3C：クラスタの照合。

プリロードやフォント読み込みライブラリーで判断は変わるか

プリロードはリソースの検出に関する機能です。WHATWG HTML Standardでは、preloadは、現在のナビゲーションで必要になると予想されるリソースを先回りして取得し、キャッシュするものと定義されています。フォントのfont-display方針を選ぶ機能ではありません。表示方法を決めた後でのみ、プリロードを検討してください。先に取得しても、書体をまだ利用できない場合の動作を決めることの代わりにはなりません。WHATWG：Link type preload。

一般的なページのテキストでは、まずCSSを使います。既存のプロジェクトでFont Face Observerを使っている場合、文書化されたload()メソッドは、フォントが読み込まれると解決し、失敗すると拒否されるプロミスを返します。ファミリー名と、必要に応じて指定するウェイト、スタイル、ストレッチの説明は、要求する書体に一致させてください。また、フォントに既定の文字が含まれていない場合に、適切なテスト用テキストを渡す方法もライブラリーのドキュメントに記載されています。Font Face Observerのドキュメント。

ライブラリーのコールバックが成功したことは、読み込みを知らせるシグナルです。何を表示するかは、引き続きアプリケーション側で決めます。独自のロジックでテキストを隠す場合は、失敗時に読みやすい代替フォントを表示する経路も指定してください。そうしないと、読み込みに失敗した後もアプリケーションの非表示ルールが残る可能性があります。これは、ライブラリーに文書化された成功時と失敗時の動作に基づく実装上の推奨です。

ネイティブAPIにも同様の制約があります。document.fonts.readyは、使用するフォントの読み込みとレイアウト処理が完了すると解決されます。対象となるフォントは、オプションの書体など、読み込みの機会を逃したものも含めたすべての宣言済みフォントとは異なる場合があります。したがって、意図したすべての書体が表示されていることの証明にはなりません。MDN：Documentのfontsプロパティ。

同様に、document.fonts.load()に渡す任意のテキスト引数は、Unicodeの範囲を使って一致する書体を選びます。個々のグリフが含まれているかを確認するものではありません。読み込みの完了と、サンプル全体が正しく描画されていることは、別々に確認してください。MDN：FontFaceSetのload()メソッド。

同じページの低速読み込み、フォントを利用できない状態、再読み込みの状態を確認して方針を選びます。通常の文字を読める状態に保ち、遅れて置き換わってもよいかを明確に決め、小さな要素にフォント依存の具体的な理由がある場合に限って、一時的な非表示を許容します。どの条件でテストしても、「Sample Collection」を快適に読み続けられる結果にしてください。

参考資料