脱・「とりあえずクラス名」！HTMLテキスト要素を美しく制御する設計術
現場でコードをレビューしていると、よく目にする光景があります。「`p` タグに `mt-20` を当てて、その中に `span` で色を変えた文字を入れて……」といった、場当たり的なスタイリングです。
動けばいい。確かにそうかもしれません。しかし、プロジェクトが中規模を超えた瞬間、その「とりあえず」の積み重ねは、負債となってあなたの首を絞め始めます。今回は、HTMLの基本であるテキスト要素を、いかに堅牢で再利用可能な形で設計するか。その現場のリアルな解をお話しします。
—
ブラウザはどう「テキスト」を理解しているか
まず、大前提を整理しましょう。`h1-h6` や `p` などのテキスト要素は、ブラウザにとって単なる「文字の入れ物」ではありません。これらはセマンティクス（意味論）とレンダリングの境界線に存在します。
ブラウザの内部では、これらの要素にデフォルトの User Agent Stylesheet が適用されています。例えば、`h1` はブロック要素であり、かつ文字サイズやマージンが既に定義されている。これを理解せずに「リセットCSSで全部消して、全部クラスで指定する」という手法をとるチームもありますが、私はあまり推奨しません。
「HTMLのデフォルトの振る舞い」を活かしつつ、「必要な差分だけをCSSで定義する」。 これが、最もメンテナンスコストが低く、かつブラウザの描画負荷も抑えられるアプローチです。
—
BEMとUtility-firstの「美味しいとこ取り」
現代のフロントエンド開発において、テキスト要素の命名規則をどうするか。結論から言うと、「役割はBEMで、装飾はUtilityで」というハイブリッド戦略が最強です。
1. 役割としてのBEM（Block, Element, Modifier）
テキスト要素は「何者か」を定義するためにBEMを使います。
- `.article__title`
- `.card__description`
これらは「文脈」を担保します。「これは記事のタイトルである」という意図がコードから読み取れることは、数ヶ月後の修正時に絶大な安心感を生みます。
2. 装飾としてのUtility-first（Tailwind等）
一方で、「文字を赤くする」「マージンを16pxあける」といった装飾をクラス名に詰め込むのはやめましょう。これらはUtilityクラスに任せます。
……
……
—
実務で使えるコンポーネント設計サンプル
では、実際にチームで使える「堅牢なテキストコンポーネント」の設計を見ていきましょう。ここでは、汎用性の高い `p` タグと `h` タグの設計例を紹介します。
/ CSSベースの設計例 /
/ コンポーネントのベースとなる共通設定 /
.text-body {
line-height: 1.6; / 可読性を高める行間 /
color: var(–text-main); / CSS変数で管理してテーマ変更に対応 /
margin-bottom: 1em; / 要素間の間隔を統一 /
}
/ Modifier（装飾的な変化） /
.text-body–small {
font-size: 0.875rem;
opacity: 0.8;
}
.text-body–lead {
font-size: 1.25rem;
font-weight: 600;
}
フロントエンドエンジニアにとって、テキスト設計はUIの品質を左右する基礎体力です。
HTMLの本来の役割を尊重し、CSSで柔軟に拡張する。これがベストプラクティスです。
※この記事は実務経験に基づく知見です。
—
なぜこの設計が良いのか？
1. 一貫性の担保: `text-body` を当てるだけで、プロジェクト全体で統一された行間とマージンが適用されます。個別のページで `line-height` をちまちま指定する必要はありません。
2. 修正コストの削減: 「やっぱり本文の行間を少し広げたい」という要望が来た時、CSSファイルを1箇所直すだけで全ページに反映されます。
3. アクセシビリティへの配慮: コンポーネント化することで、`h` タグの階層構造を意識した設計がしやすくなります。Utilityを単に並べるだけでは見落としがちな「文書構造」を、BEMのクラス名が補完してくれるのです。
—
最後に：完璧主義を捨てよう
もちろん、これが唯一の正解ではありません。Atomic DesignやCSS Modules、あるいはCSS-in-JSなど、技術スタックによって最適な形は変わります。
しかし、最も大切なのは「HTMLのタグ本来の意味を殺さないこと」です。`div` に `font-size` を当てるのと、`p` に当てるのでは、スクリーンリーダーの解釈やSEOの観点で大きな差が出ます。
「とりあえずクラスを当てる」その一手を打つ前に、一度立ち止まって考えてみてください。「このテキストは、ドキュメントの中でどのような役割を持っているか？」。その問いに対する答えが、あなたのコードを「ただ動くもの」から「美しい資産」へと変えてくれるはずです。
現場からは以上です。明日からのコーディングが、少しでも快適で論理的なものになりますように。
コメント