メインコンテンツまでスキップ

line-heightのハーフ・レディングを打ち消す`calc((1em - 1lh) / 2)`をCSS変数に定義しておくとよい

CSS

広告

最近Xで投稿したline-heightの上下の余白(ハーフ・レディング)を打ち消す方法が反響を得ていましたが、こちらで紹介したcalc((1em - 1lh) / 2)はグローバルスコープのCSS変数で定義しておくと便利です。

参考:最近投稿したポスト
ポストを別枠で表示する
🙆‍♂ Recommended
:root {
--leading-trim: calc((1em - 1lh) / 2);
}

calc((1em - 1lh) / 2) とは

現在のフォントサイズ(1em)から行の高さ(1lh)を引き、その差を2で割ることでハーフ・レディングを取り除いた値を算出する計算式です。

例えばp要素に以下のような指定を行ったとします。

p {
font-size: 1rem;
line-height: 1.5;
margin-block: calc((1em - 1lh) / 2);
}

lhという単位に見慣れない方もいるかと思われますが、これは現在のline-heightと同じ長さを表す新しく登場した単位です。この例ではline-heightはフォントサイズの1.5倍なので、もし1rem16pxであれば1lh24pxとなります。

この場合、行の高さと文字の高さの負の差は1em - 1lh、つまり16px - 24px-8pxです。それを片方の値を算出するために2で割ると-4pxになります。したがって、margin-block: calc((1em - 1lh) / 2)は、書式のブロック方向(横書き時:上下)にそれぞれハーフ・レディングの大きさ(今回では4px)分のネガティブマージンを設定するということになります。

従来の上下の余白を打ち消す方法との比較

lhが登場するまではSassの@mixinなどを使用して以下のような関数を定義し、ハーフ・レディングを打ち消す方法が一般的でした。

Sassの関数の例
@mixin leadingTrim($lh) {
&::before,
&::after {
content: '';
display: block;
inline-size: 0;
block-size: 1px; // marginが貫通しないようにする
}
// 前の要素との相殺を防ぐために::beforeに`margin-block-end`、::afterに`margin-block-start`を指定する
&::before {
margin-block-end: calc((1 - #{$lh}) * 0.5em);
}
&::after {
margin-block-start: calc((1 - #{$lh}) * 0.5em);
}
}
p {
font-size: 1rem;
line-height: 1.5;
@include leadingTrim(1.5); //line-heightで指定されている値を指定する
}

この方法はその要素が持つline-heightの値を事前に知っておく必要があり、レスポンシブデザインなどでline-heightの値が変更された場合に再度計算を見直す必要があるため柔軟性や保守性に欠けていました。

一方、lhを使用することで現在のline-heightに基づいた相対的なサイズを指定できるため、ハーフ・レディングを直接的かつ動的に打ち消すことができます。これにより、要素が持つline-heightの値を知らなくても上下の余白を打ち消すことができ、またline-heightの値が変更された場合にも手動で再計算を行う必要がなくなるため柔軟性や保守性が向上します。

lh は全モダンブラウザで対応済み

lhは現在全てのモダンブラウザで対応されています。ただし、iOS Safari では 16.4 からの対応となるため、iOS 16 以上をサポートする場合はフォールバックを検討する必要があります。

lhがサポートされていない環境を考慮する場合は@supports機能クエリを使用して0pxを定義しておくと良いかもしれません。

フォールバックの例
:root {
--leading-trim: calc((1em - 1lh) / 2);
}
@supports not (top: 1lh) {
:root {
--leading-trim: 0px; /* `px`などの単位が必要 */
}
}

このフォールバックをすることでmargin-block:calc(24px + var(--leading-trim))のような指定を行った場合、ハーフ・レディングを含んだ値にはなるものの計算エラーによって余白が無くなるという事態は防ぐことができます。

calc((1em - 1lh) / 2) をCSS変数に定義しておいたほうが良い理由

calc((1em - 1lh) / 2)をグローバルスコープのCSS変数で定義しておくとよい理由は次のとおりです。

Adobe製デザインツールを元にコーディングする際の余白調整として

現在デザインツールとして主流のFigmaはハーフ・レディングに対応しているものの、Adobe製のデザインツール(XD、Illustrator、Photoshop)は行送り(レディングがベースライン)であるため、そのままデザインツールから取得した余白の値を適用するとハーフ・レディング分のズレが生じてしまいます。

参考:せきゆおうさんのポスト
ポストを別枠で表示する

Xでは定期的にピクセルパーフェクトは必要か否かで盛り上がっていますが、大体このハーフ・レディング分のズレが要因になっているように思われます。個人的な見解ですが、フォントサイズが16pxline-height1.5の場合、そのまま余白を設定してしまうとその要素だけで8px分のズレが生じるためピクセルパーフェクト云々の範疇に収めるべきではないと感じます。

ちなみにピクセルパーフェクトの議論においてマージンが40pxズレているとか、フォントや配色が間違っているなどをまとめて「ピクセルパーフェクト」と言っている方も散見されますが、それは単にデザインを再現していないだけなのでピクセルパーフェクトと一緒くたにするのは誤りです。

このため、Adobe製デザインツールを元にコーディングする場合はその余白にハーフ・レディングが絡むかどうかを確認し、calc()関数と併せてCSS変数で用意しておいたcalc((1em - 1lh) / 2)を呼び出すことを推奨します。

h2 {
/* デザインカンプで取得した余白が32pxの場合 */
margin-block-start: calc(32px + var(--leading-trim));
}

上記の例のようにcalc(32px + var(--leading-trim))とすることで「デザインカンプで取得した余白(32px)にleading-trimを加える」と明示でき、コードの可読性が向上します。

もしデザインガイドラインで余白がトークン化されている場合は--spacing-lg-trimのようにハーフ・レディングを除いた余白も変数化しておくと良いでしょう。

次の例はデザイン庁のデザインシステムで用いられている、8pxを余白の基準としてフィボナッチ数列を用いて定義したスペーシングルールをグローバルスコープで変数化したものです。

余白のCSS変数の例
:root {
--leading-trim: calc((1em - 1lh) / 2);
--spacing-unit: 0.5rem; /* 8px */
--spacing-xs: calc(var(--spacing-unit) / 2);
--spacing-sm: var(--spacing-unit);
--spacing-md: calc(var(--spacing-unit) * 2);
--spacing-lg: calc(var(--spacing-unit) * 3);
--spacing-xl: calc(var(--spacing-unit) * 5);
--spacing-2xl: calc(var(--spacing-unit) * 8);
--spacing-3xl: calc(var(--spacing-unit) * 13);
--spacing-xs-trim: calc(var(--spacing-xs) + var(--leading-trim));
--spacing-sm-trim: calc(var(--spacing-sm) + var(--leading-trim));
--spacing-md-trim: calc(var(--spacing-md) + var(--leading-trim));
--spacing-lg-trim: calc(var(--spacing-lg) + var(--leading-trim));
--spacing-xl-trim: calc(var(--spacing-xl) + var(--leading-trim));
--spacing-2xl-trim: calc(var(--spacing-2xl) + var(--leading-trim));
--spacing-3xl-trim: calc(var(--spacing-3xl) + var(--leading-trim));
}

また、Figmaを使用している場合においても文字上下余白トリミング機能(vertical-trim)が一部では有効になっていたり、意図せず全体的に有効になっている場合も考えられるためデザインツールの種類にかかわらずcalc((1em - 1lh) / 2)をCSS変数に定義しておくことを推奨します。

Figmaの文字上下余白トリミングはフォントのbase lineからcap lineまでの高さにトリミングする機能であるため、現状のCSSでは再現が厳しいという指摘を頂きました。そのため、Figmaの文字上下余白トリミング機能はオフにするようデザイナーに掛け合ったほうが良さそうです。ご指摘ありがとうございました。

ポストを別枠で表示する

話は逸れますが、先述したデザイン庁のデザインシステムはデザインガイドラインのサンプルとして完成されているため、デザイナー・エンジニア共に一度は確認しておくことをオススメします。

ポストを別枠で表示する

line-height:1 の指定の代わりとして

僕のコーディングのポリシーとして、可能な限りline-height:1という指定は避けるというものがあります。

ポストを別枠で表示する

以前、ボタンの高さと同じ数値でline-heightを指定し、テキストを天地中央寄せする実装方法に苦言を呈したことがありますが、line-height:1を避ける理由も同様の意味合いを持っています。

デザインカンプ上でline-height:1が指定されていたとしても、将来テキストが更新されることで複数行になる可能性がありますし、テキストの変更が行われないことが期待されるテキストでも機械翻訳されることで複数行になる可能性があるため、可能な限りline-height:1という指定は避けたほうが良いという見解です。

参考:びしーさんのポスト
ポストを別枠で表示する

単純にline-height:1は読みにくいというのもありますが、特に認知障害を持つ方は行間が狭すぎると文字を追うのが難しくなる可能性があり、line-height:1は複数行になった際にアクセシビリティの観点で問題となる可能性があります。可能な限りデザイナーにline-height:1が指定されている部分は複数行になった際にどれくらいの行間を設けるか?は確認したほうが良いですが、「WCAG(Web Content Accessibility Guideline) 2.1」では達成基準の一つ「1.4.8 視覚的提示」で「段落中の行送りは、少なくとも1.5文字分ある。そして、段落の間隔は、その行送りの少なくとも1.5倍以上ある」と記載されているため、特に指定がなければ最低でもline-height:1.5程度を確保することが望ましいという見解です。

ウェブデザインにおけるline-heightについて

ウェブデザインにおけるline-heightってけっこう曲者で、CSSを理解してデザインしないと「空き」の設計が破綻したりコーディングで苦労することになります。FigmaやAdobe XD、Affinity Design […]

parashuto.com

例えば「ボタンのラベルはline-height:1として、ボタンのpadding1remとする」とデザインの仕様で定められている場合はpadding-blockの値をcalc(1rem + var(--leading-trim))とすることでデザインの仕様を満たしたうえで複数行の対応を行うことができます。

参考:当ブログの汎用的なボタンコンポーネントのpaddingの指定

また、「ベースのline-height1にしておくとコーディングしやすい」という技術発信を見かけましたが、これも上記の理由から避けたほうが良いでしょう。

将来 text-box-trim & text-box-edge プロパティが全モダンブラウザで使用可能になればこの指定は不要になる

将来的にはtext-box-edge:texttext-box-trim:bothというプロパティを使うことでハーフ・レディングを打ち消すことが可能になるようです。

しかし、現時点では全モダンブラウザでサポートされておらず(Safari Technology Previewでのみ使用可能)、僕がこの業界に入った当時からleading-trimプロパティとして提案されていたのにも関わらず一向にサポートされる気配がなかったため、これらのプロパティが使用可能になるのは遠い未来だと予測されます。

参考リンク

ドキュメント

書籍

参考記事

本文上部へ戻る