Webフォントが反映されないあるある

※ 2018/08/03 追記： TypeSquareのAPIのバージョンがv3になりましたので一部加筆しました。

TypeSquareなどのCloudサービスのWebフォントを使用している案件で、開発中にしばしば「Webフォントが当たらない」などと言われることがあります。

結構あとで言われて開発をとめて検証しないといけなくなるので、
どういうときにそうなるのか、よくあるハマりパターンをまとめてみます。
※実体験のみなので、網羅しているわけではありません。適宜あれば追記します。

個人的にこういうのはエンジニアだけではなく、できればデザイナーやディレクターにも事前に理解しておいてほしい内容ですのでなるべく平たく書くようにします。
分かりづらいところがあったらコメントください。

Webフォントサービスに開発用のドメインが設定されていない

モリサワのTypeSquareなどはWebフォントを利用できるドメインをホワイトリストで指定する必要があります。
本番環境のドメインだけしか登録されていないと、開発環境など他のドメインでは表示することができません。
また本番でもサブドメインや localhost:3000 のようなローカルでのURLも同様です。
ドメイン数で費用が変わったりするので、クライアントに了承の上で上記を追加する必要があります。

またモリサワに関しては、モリサワ製品（Morisawa Passport）を利用していればTypeSquareも利用できるので、開発用にタグを切り替える必要はありますが、そちらを設定しておくのもよいと思います。
（本番でタグを切り替えるのを忘れずに…）

Webフォントサービスのアクセス制限の上限に達している

モリサワのTypeSquareなどは呼び出し回数に上限があります。（プランによります）
管理画面を確認しましょう。

要素を動的に追加したときにフォントが更新されていない

クラウドサービスのWebフォントのいくつかは、表示時にWebフォントを読み込む際、表示されている文字だけ動的に読み込むことで読み込みサイズを最適化しています。

そのため、あとからユーザーの操作等で要素が動的に追加されると、そこに含まれている文字にはWebフォントが反映されません。（厳密には読み込み済みの文字のみ反映される）

だいたいJavaScriptのAPIが用意されているので、要素を生成したあとでWebフォントをリロードしましょう。

TypeSquareの場合

参考: https://typesquare.com/ja/service/api_reference

URLを /accessor/script から /accessor/apiscript/ にするとJSのAPIが利用できる。
※ 2018/08/03 追記 : v3からURIについての記載がなくなりました。

<script type="text/javascript" src="//typesquare.com/accessor/apiscript/typesquare.js?0Jyi6TwLGMA%3D" charset="utf-8"></script>

要素を生成したらリロード処理を呼ぶ。

function render() {
  // render的処理
  // Ts.reload(); // v2
  Ts.loadFont() // v3
}

placeholder属性やCSSで生成した文字には当たらない

Webフォントの内部で対象になるのはHTMLのテキストノードのみのようです。
フォームコントロールの placeholder の文字列や、 CSSの content: "hoge" などで生成した文字列は対象になりません。

<label>あなたのコメントをお願いします！</label><!-- ここはWebフォントになる -->
<textarea placeholder="ここにコメントを記入して下さい"><!-- この文字列はWebフォントにならない -->
</textarea>

.require-form:before {
  content: "※必須"; /* この文字列はWebフォントにならない */
}

別途HTMLに記述しておくか、あらかじめそういうので記号以外の文字列をつかわないようにしたほうが良いでしょう。
placeholderは仕方ないので、ローカルにありそうな汎用的なフォント指定をしておくのがいいと思います。

text-transform で整形した大文字小文字は対象にならない

text-tramsfrom: uppercase; /* 全部大文字に変換する */

これもCSSで大文字小文字等を整形するとその内容はリロードの対象になりません。
CMS等で入力内容と表記を別々にコントロールしないといけない場合は、CSSではなくPHPなどHTML出力時に変換するようにしましょう。
英語サイトなどアルファベットが全部読み込まれている保障があればその限りではありませんが。

現場からは以上です。