EN
JP
KRテキスト切り詰めとは？CSS 省略表示・複数行対応・実務の注意点を徹底解説
UI を作っていると、テキストは常に設計どおりの長さで収まってくれるとは限りません。商品名、記事タイトル、ユーザー名、説明文、タグ一覧、通知メッセージなどは、短い場合もあれば、想定以上に長くなる場合もあります。最初はダミーテキストでちょうど良く見えていても、実際のデータを入れた瞬間にカードの高さが崩れたり、ボタン幅をはみ出したり、一覧の見た目がばらついたりすることは非常によくあります。こうした問題に対処するために重要になるのが、テキスト切り詰め、つまり text truncation の考え方です。これは単に文字数を減らす技術ではなく、「どこまで表示し、どこから先を省略するか」を UI 設計として扱う考え方でもあります。
特に実務では、テキスト切り詰めは見た目を整えるためだけの小手先の調整ではありません。表示領域の安定、カードレイアウトの統一、一覧性の維持、レスポンシブ対応、アクセシビリティ、SEO とは別の UI 可読性の問題など、かなり広い範囲に関わります。しかも、1 行の省略と複数行の省略では考え方も実装も違いますし、CSS だけで解決できる場合もあれば、JavaScript やコンポーネント側での制御が必要な場合もあります。本記事では、テキスト切り詰めを単なる text-overflow: ellipsis; の書き方としてではなく、UI 設計と実装の両面から整理し、基礎、使い分け、コード例、注意点までをまとめて掘り下げていきます。
1. テキスト切り詰めとは
テキスト切り詰めとは、表示領域に対してテキストが長すぎる場合に、その全文をそのまま表示せず、一部を省略して見せる処理のことです。一般的には末尾に ... のような省略記号を付けて、「この先にも内容はあるが、今はここまでしか見せていない」という状態を表現します。これは単なる見た目のトリックではなく、限られた UI 空間の中で情報量を制御するための仕組みです。つまり、テキスト切り詰めは「長い文字列をどう削るか」よりも、「限られたレイアウトの中で何を優先して見せるか」を決める行為に近いです。
ここで大切なのは、テキスト切り詰めが必ずしも「情報を減らすこと」だけを意味しないという点です。実際には、一覧画面では短く見せて詳細画面では全文を見せる、カードでは 2 行までに抑えて tooltip やタイトル属性で全文を補う、といったように、表示文脈ごとの情報設計の一部として使われます。つまり、テキスト切り詰めは CSS の細かなテクニックではなく、情報の見せ方の設計でもあります。この視点がないと、単にテキストを切るだけの実装になり、可読性や使いやすさを損なうことがあります。
1.1 テキスト切り詰めが扱う問題
テキスト切り詰めが扱っている問題は、「文字数が多いこと」そのものではなく、「表示領域より情報量が多いこと」です。同じ 30 文字でも、広い画面なら問題なく収まるかもしれませんが、狭いカードやモバイル表示でははみ出すことがあります。また、日本語、英語、ドイツ語のように言語ごとに単語長や改行の入り方も違うため、単純に何文字までと決めても解決しないことがあります。つまり、テキスト切り詰めは文字列の長さそのものより、表示コンテキストとの関係を扱う問題です。
この理解が重要なのは、「何文字で切るか」だけを考える実装がしばしば不十分だからです。実際には、幅、フォントサイズ、行数、改行許可、レスポンシブ変化などが影響します。そのため、実務では文字数制限だけでなく、CSS による視覚的な制御や、コンポーネントのレイアウト制約とあわせて考える必要があります。つまり、テキスト切り詰めとは、文字列制御というより表示領域制御でもあるのです。
1.2 テキスト切り詰めが重要になる理由
テキスト切り詰めが重要なのは、見た目の安定性を保つためです。たとえば記事カードが一覧で並んでいる画面で、一つだけタイトルが極端に長いと、そのカードだけ高さが伸びて全体のリズムが崩れることがあります。商品一覧でも、商品名が長いものだけ折り返し行数が増えると、価格やボタンの位置がバラバラになって見づらくなります。つまり、テキスト切り詰めは情報を減らすためではなく、UI 全体の整列感や読みやすさを守るためにも必要です。
さらに、狭い表示領域では全文表示がかえって不親切なこともあります。画面を圧迫しすぎたり、他の重要情報を押し出してしまったりするからです。つまり、テキスト切り詰めは「全文を見せない不親切な処理」ではなく、「必要な情報を見やすく残すための選択」だとも言えます。この視点を持つと、単なる CSS テクニックとしてではなく、UI の優先順位を整える方法として理解しやすくなります。
2. テキスト切り詰めが必要になる理由
テキスト切り詰めは、見た目を整えるための小さな調整に見えるかもしれませんが、実際にはかなり本質的な役割を持っています。特にコンポーネントベースで UI を組む現代のフロントエンドでは、カード、リスト項目、ナビゲーション、タグ、通知、フォーム補助文など、再利用される小さな部品が大量に存在します。これらの部品は、どんなデータが入ってもある程度安定して見える必要があります。そのとき、テキスト長が無制限だと、部品の高さや幅が想定以上に揺れやすくなります。つまり、テキスト切り詰めは「部品を安定して再利用するための条件」でもあります。
また、ユーザー体験の面でも重要です。長すぎるテキストが一覧画面にそのまま出ていると、どこに注目すべきかが分かりにくくなり、スキャンしづらくなります。逆に、適切に切り詰められていれば、一覧では必要なキーワードだけを素早く拾えます。詳細は詳細ページや展開UIで見せればよいからです。つまり、テキスト切り詰めは単なる削減ではなく、「一覧では要約、詳細では全文」という情報提示の分担にもつながっています。
2.1 レイアウト安定性のため
もっとも分かりやすい理由は、レイアウトの安定性です。カード一覧、商品一覧、ユーザー一覧、ニュース一覧などでは、並んだ要素の高さがある程度そろっているほうが圧倒的に見やすくなります。もし一部の項目だけタイトルが長くて 4 行に伸び、他は 1 行で収まると、視線移動のリズムが崩れ、一覧性が下がります。つまり、テキスト切り詰めは視覚的な秩序を保つための手段です。
このとき重要なのは、「長いものを罰する」ように切るのではなく、コンポーネントに許された表示量を設計することです。たとえばタイトルは 2 行まで、補足説明は 3 行まで、と決めておけば、どんなデータが入っても大きく崩れにくくなります。つまり、テキスト切り詰めは事後対応ではなく、コンポーネント設計の段階で考えるべきものです。
2.2 一覧性と可読性のため
一覧画面では、全文が読めることより、必要な情報を素早く拾えることのほうが重要な場合が多いです。たとえばニュースタイトルは先頭の数語だけで内容の方向性が分かることがありますし、商品名もブランド名と特徴キーワードが見えれば一覧では十分なことがあります。逆に全文を全部見せると、一つ一つのカードが重たくなり、スクロール体験が悪くなります。つまり、テキスト切り詰めは「読むため」ではなく「探すため」の UI において非常に有効です。
もちろん、何でも省略すればよいわけではありません。重要なのは、一覧で必要な情報密度と詳細で必要な情報密度を分けて考えることです。つまり、一覧では切り詰めるが、詳細では全文を見せる、あるいは hover や開閉で補う、といった設計が必要になります。テキスト切り詰めは単体では完結せず、情報表示全体の設計とセットで考えるべきです。
2.3 レスポンシブ対応のため
同じテキストでも、PC では 1 行で収まっていたものが、スマートフォンでは 2 行や 3 行に伸びることがあります。これにより、レイアウトバランスが大きく変わることがあります。テキスト切り詰めを適切に使うことで、画面幅が変わっても表示量をコントロールしやすくなります。つまり、テキスト切り詰めはレスポンシブデザインの一部でもあります。
また、単純に文字数制限をするだけではレスポンシブには対応しにくいです。画面幅に応じて見える文字数は変わるからです。そのため、実務では CSS ベースの省略や行数制御が重要になります。つまり、レスポンシブ時代のテキスト切り詰めは、文字列操作というよりレイアウト操作として理解したほうが自然です。
3. 1 行のテキスト切り詰め
テキスト切り詰めの中で最も基本的なのが、1 行で表示しきれない文字列を末尾で省略するパターンです。これはナビゲーション項目、テーブルセル、タグ、ボタンラベル、カードタイトルの一部など、かなり多くの UI で使われます。見た目としても理解しやすく、CSS だけで実装できることが多いため、最初に覚えるべきテキスト切り詰め手法でもあります。ただし、単に text-overflow: ellipsis; を書くだけでは動かないことがあり、そのために「なぜ省略記号が出ないのか」で詰まりやすいテーマでもあります。
1 行省略を理解するには、省略記号そのものより、どの条件でブラウザが「これははみ出している」と判断するのかを知ることが重要です。つまり、1 行切り詰めは装飾ではなく、レイアウト条件によって成立する処理です。この前提を理解すると、実装はかなり安定します。
3.1 1 行省略の基本条件
1 行のテキスト切り詰めを成立させるには、一般的に white-space: nowrap;、overflow: hidden;、text-overflow: ellipsis; の三つが必要です。white-space: nowrap; によって改行を禁止し、overflow: hidden; によってあふれた部分を隠し、text-overflow: ellipsis; によって末尾を省略記号で表現します。しかし、これだけでは足りないこともあります。要素自身に幅制約がないと、そもそも「はみ出し」が発生せず、省略処理も起きないからです。つまり、1 行省略は「省略記号を付ける指定」ではなく、「はみ出す条件を意図的に作る指定」でもあります。
この点を理解していないと、プロパティは書いているのに何も起きないという状態になります。特に inline 要素のままだったり、親にレイアウト制約がなかったりすると、省略記号が出ないことがあります。つまり、1 行省略は CSS の 1 行トリックではなく、幅制約を含むレイアウト設計の一部です。
3.2 1 行省略のコード例
以下は、1 行のタイトルを省略するもっとも基本的な例です。カードや一覧のタイトルでよく使われる形です。
index.html
<div class="card">
<p class="title">
とても長いタイトルが入った場合に、この領域の中で一行に収めながら末尾を省略したいテキストです
</p>
</div>
style.css
.card {
width: 280px;
padding: 16px;
border: 1px solid #dcdcdc;
}
.title {
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
この例では、.card に幅があるため、.title がその中ではみ出したときに省略が成立します。もし親にも子にも幅制約がなければ、省略は見えにくくなります。つまり、省略記号は CSS の魔法ではなく、レイアウト制約の結果として現れます。
3.3 1 行省略で起きやすい問題
1 行省略でよく起きるのは、「書いたのに効かない」という問題です。その原因の多くは、要素が inline のままである、幅制約がない、Flex コンテナ内で min-width の影響を受けている、といったレイアウト条件にあります。特に Flexbox の子要素では、min-width: auto; が影響して縮まらず、省略が起きないことがあります。その場合は min-width: 0; を明示する必要があることがあります。つまり、1 行省略は単体の CSS プロパティだけで完結しない場面もあります。
また、省略記号が付いたことで重要な情報が欠けてしまうことも問題です。たとえば商品名の最後に型番がある場合、常に後半が切れると識別性が下がることがあります。つまり、技術的に省略できることと、情報設計として省略してよいことは別問題です。UI の意味も含めて判断する必要があります。
4. 複数行のテキスト切り詰め
1 行省略だけでは足りない場面も多くあります。特にカード本文、ニュースのリード文、商品説明、レビュー抜粋などは、1 行では情報が少なすぎて意味が伝わりにくい一方、全文を出すとレイアウトが不安定になります。そのため、「2 行まで」「3 行まで」といった複数行の切り詰めが重要になります。これは 1 行省略より実務でよく使われる一方、ブラウザ実装やプロパティの癖もあるため、少し理解が必要なテーマです。
複数行切り詰めの本質は、「全文は見せないが、1 行よりは多くの文脈を見せる」ことにあります。つまり、情報量と一覧性のバランスを取るための設計です。ここを理解しておくと、何行まで許容するかの判断もしやすくなります。
4.1 複数行省略が必要になる場面
複数行省略は、一覧性を保ちつつある程度の説明量も必要な場面で活躍します。たとえば記事カードでタイトルは 2 行、説明文は 3 行までにする、といった設計は非常に一般的です。これにより、一覧の高さをある程度そろえながらも、内容の雰囲気や文脈をユーザーへ伝えやすくなります。つまり、複数行省略は「読み物としての文脈」と「一覧としての整列感」の中間を取る手法です。
また、1 行省略だとほとんど内容が分からないが、全文は長すぎる、という場面にも向いています。レビューの冒頭、商品説明、通知本文などでは特に有効です。つまり、複数行省略は「情報量を完全に削る」のではなく、「適切な量まで残す」という設計に近いです。
4.2 複数行省略のコード例
CSS で複数行省略を行う代表的な方法は -webkit-line-clamp を使う形です。現在では広く使われていますが、やや特殊な書き方になるため、1 行省略よりは仕組みを意識して使う必要があります。
index.html
<div class="article-card">
<p class="excerpt">
この説明文は複数行で表示しつつ、一定行数を超えたら末尾を省略したい文章です。カード一覧の高さをそろえながら、内容の雰囲気もある程度伝えたい場合によく使われます。
</p>
</div>
style.css
.article-card {
width: 320px;
padding: 16px;
border: 1px solid #dcdcdc;
}
.excerpt {
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 3;
overflow: hidden;
}
この例では、3 行を超えた部分が隠されます。1 行省略のような text-overflow: ellipsis; 単体ではなく、行数制御用のプロパティ群を使っている点が特徴です。つまり、複数行省略は 1 行省略の延長ではなく、別の仕組みとして理解したほうが分かりやすいです。
4.3 複数行省略の注意点
複数行省略で注意すべきなのは、見た目上は便利でも、ブラウザ依存や実装依存の性格がやや強いことです。また、行数が固定されるため、フォントサイズや行間を変えたときに見え方が想定とずれることがあります。つまり、単に「3 行」と決めれば終わりではなく、その 3 行が何を意味するのかまで見ておく必要があります。
さらに、複数行省略は全文を見せないため、詳細情報への導線が必要になることもあります。全文へのリンク、展開ボタン、詳細ページ遷移などをどう設計するかまで含めて考えないと、ただ「途中で切れたまま終わる UI」になりやすいです。つまり、複数行省略は CSS テクニック以上に、情報導線の設計が重要です。
5. CSS と JavaScript でのテキスト切り詰めの違い
テキスト切り詰めは CSS だけで行うこともあれば、JavaScript やアプリケーションロジック側で行うこともあります。どちらを使うべきかはケースによります。CSS は表示領域に応じた視覚的な制御に強く、JavaScript は文字列加工や条件分岐を含むロジックに強いです。つまり、見た目に合わせて切るなら CSS、内容の意味に応じて切るなら JavaScript やテンプレート処理、という考え方が基本になります。
ここを混同すると、本来 CSS で済むものを無駄に文字数カットしてしまったり、逆に文字数だけで切ってレスポンシブ時に不自然になったりします。つまり、技術の違いではなく、何を基準に省略したいのかで選ぶ必要があります。
5.1 CSS で切り詰める利点
CSS による切り詰めの最大の利点は、表示領域に応じて自然に省略できることです。画面幅や親要素のサイズが変われば、見える範囲も自動的に変わります。つまり、レスポンシブデザインと相性が良いです。また、元の文字列データはそのまま保持されるため、tooltip や展開UIと組み合わせやすいという利点もあります。
さらに、CSS ベースなら「何文字まで」という雑な制限ではなく、「今の見た目に収まるところまで」という視覚基準で処理できます。これは特に日本語・英語混在や可変幅フォントでは大きな意味があります。つまり、CSS は視覚レイアウトに合わせてテキストを制御する方法です。
5.2 JavaScript で切り詰める利点
JavaScript で切り詰める利点は、意味やルールを細かく制御しやすいことです。たとえば 50 文字を超えたら省略する、特定の単語の途中では切らない、モバイル時だけ文字数を変える、API レスポンス時点で短縮する、といったロジックは JavaScript やバックエンド側の文字列処理に向いています。つまり、表示領域ではなく内容ルールを基準に切りたいなら、ロジック側のほうが自然です。
ただし、単純な文字数カットだけでは、実際の表示幅と一致しないことがあります。英数字と日本語では横幅も違いますし、レスポンシブ環境では同じ 30 文字でも収まり方が変わります。つまり、JavaScript の切り詰めは便利ですが、「文字列処理」であって「表示処理」ではないという理解が重要です。
5.3 使い分けの考え方
実務では、まず CSS で解決できるかを考え、意味ベースの制御が必要なときだけ JavaScript を使う、という流れが自然です。特に一覧 UI やカードでは、表示領域に応じて見える範囲が変わるため、CSS ベースの省略が向いています。一方、メール件名の短縮、通知ログの固定文字数要約、検索結果スニペット加工のように、「見た目」より「文字列ルール」が重要な場合は JavaScript やサーバー側処理が向いています。
つまり、CSS と JavaScript の違いは、技術選択というより「何を基準に省略するか」の違いです。視覚基準か、内容基準かを分けて考えると判断しやすくなります。
| 方法 | 主な基準 | 強み | 注意点 |
|---|---|---|---|
| CSS で省略 | 表示領域 | レスポンシブと相性が良い | 幅制約やレイアウト理解が必要 |
| JavaScript で省略 | 文字列ルール | 条件分岐しやすい | 見た目の幅とは一致しにくい |
| サーバー側で省略 | 配信前のデータ加工 | 一貫した要約がしやすい | UI 幅への適応は弱い |
6. テキスト切り詰めとレスポンシブデザイン
テキスト切り詰めを考えるとき、レスポンシブデザインとの関係は非常に重要です。同じテキストでも、PC の広いカードでは 1 行で収まっていたものが、スマートフォンでは 2 行になったり、複数行省略の対象になったりします。つまり、テキスト切り詰めは固定条件の処理ではなく、表示幅やレイアウト条件によって結果が変わる可変的な処理です。このことを理解していないと、デスクトップではきれいに見えていたUIがモバイルで不自然になる、といった問題が起こりやすくなります。
また、レスポンシブでは単に画面幅が変わるだけではなく、フォントサイズ、余白、カード幅、列数も変わります。そのため、「省略するかどうか」だけではなく、「何行まで許容するか」「全文を見る導線をどう用意するか」も画面サイズごとに変わり得ます。つまり、テキスト切り詰めはレスポンシブの一部として設計すべきです。
6.1 画面幅によって変わる省略の意味
デスクトップでは 1 行省略で十分でも、モバイルでは同じ幅で表示される要素がずっと狭くなるため、ほとんど情報が見えなくなることがあります。その場合、1 行省略のままではなく、2 行まで許可したほうがユーザー体験が良いこともあります。逆に、デスクトップの大きな表で列幅をそろえるために 1 行へ固定したい場面もあります。つまり、「何行まで見せるべきか」は固定の正解があるわけではなく、画面文脈に応じて変わります。
この視点が重要なのは、レスポンシブ対応で単に幅だけを変えて満足してしまうと、情報密度の設計が崩れるからです。表示領域が変わるなら、省略方針も合わせて見直す必要があります。つまり、テキスト切り詰めはレスポンシブの副作用として起こるものではなく、レスポンシブ設計の一部です。
6.2 メディアクエリと組み合わせる考え方
実務では、テキスト切り詰めをメディアクエリと組み合わせることがあります。たとえば PC ではタイトルを 1 行、省略文を 3 行にし、スマートフォンではタイトルを 2 行、省略文を 2 行にするといった調整です。これは単なる見た目調整ではなく、画面サイズごとに「何をどれだけ優先表示すべきか」が変わるからです。つまり、省略行数もレスポンシブデザインの対象です。
以下は、画面幅によって行数を切り替える例です。
index.html
<p class="responsive-excerpt">
この文章は画面幅に応じて切り詰め方を変える例です。広い画面では余裕があるため多めに見せ、狭い画面では一覧性を保つため少なめに見せる、という考え方が実務ではよく使われます。
</p>
style.css
.responsive-excerpt {
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 3;
overflow: hidden;
}
@media (max-width: 600px) {
.responsive-excerpt {
-webkit-line-clamp: 2;
}
}
この例では、通常時は 3 行、狭い画面では 2 行に制限しています。つまり、省略は静的な指定ではなく、画面条件に応じて調整できるものです。
6.3 レスポンシブ時の落とし穴
レスポンシブ時にありがちなのは、切り詰めの見た目だけを見て、実際の可読性を評価しないことです。たとえば 2 行省略にした結果、タイトルの核心部分が毎回切れてしまい、一覧で判別しにくくなることがあります。また、モバイルでは全文を見る手段が hover に依存できないため、tooltip 前提の設計が機能しないこともあります。つまり、レスポンシブでは単に「収まるか」ではなく、「十分に意味が伝わるか」まで考えなければなりません。
そのため、実務では実機幅や主要ブレークポイントで、実データを入れて確認することが大切です。省略はダミーテキストでは綺麗に見えても、本番データで破綻しやすい領域だからです。つまり、レスポンシブ時のテキスト切り詰めは、見た目と意味の両方で検証すべきです。
7. テキスト切り詰めとアクセシビリティ
テキスト切り詰めは見た目を整えるのに便利ですが、そのままではアクセシビリティ上の問題を生むことがあります。なぜなら、表示上は一部しか見せていないのに、全文へのアクセス手段がないと、利用者によっては必要な情報へたどり着けなくなるからです。特にスクリーンリーダー利用者、キーボード操作中心の利用者、モバイル利用者にとって、単に「切れているだけ」の UI は不親切です。つまり、テキスト切り詰めは見た目の整理と引き換えに、情報アクセスの代替手段を考える必要があります。
ここで重要なのは、「省略すること」自体が悪いのではなく、「省略した後の導線がないこと」が問題だという点です。全文が重要なら、その全文をどう見せるかまで含めて設計しなければなりません。つまり、テキスト切り詰めは CSS のテーマであると同時に、UI アクセシビリティのテーマでもあります。
7.1 省略した情報をどう補うか
省略されたテキストは、何らかの形で補えるようにするのが理想です。代表的なのは、詳細ページで全文を見せる、開閉ボタンを用意する、tooltip や title 属性で補足する、といった方法です。ただし、tooltip は hover 前提だとモバイルで使いにくく、title 属性もスクリーンリーダーやモバイルで一貫して便利とは限りません。つまり、安易に tooltip を付ければ解決というわけではありません。
より重要なのは、切り詰められた情報が、その画面でどれだけ重要かを判断することです。単なる補助説明なら省略だけでも十分かもしれませんが、識別に必要な情報なら、何らかの手段で確実に全文へ到達できるべきです。つまり、アクセシビリティの観点では「どの情報が必須か」の見極めが前提になります。
7.2 スクリーンリーダーと見た目の差
CSS で視覚的に切り詰めた場合、DOM 上の文字列自体は残っていることが多いため、スクリーンリーダーは全文を読む場合があります。これは一見便利にも見えますが、視覚ユーザーと支援技術ユーザーで体験がずれることも意味します。逆に JavaScript やサーバー側で文字列自体を短くしてしまうと、スクリーンリーダーでも全文へアクセスできなくなることがあります。つまり、どのレイヤーで切り詰めるかによって、アクセシビリティへの影響も変わります。
この点からも、CSS による視覚的な省略は比較的安全な場合がありますが、それでも「見えていないものが重要ではないか」を確認すべきです。つまり、スクリーンリーダー対応まで考えるなら、テキスト切り詰めは単に見た目だけの問題ではありません。
7.3 モバイルでの補助手段の考え方
デスクトップでは hover による補助表示が機能することがありますが、モバイルではそれが前提にできません。そのため、モバイル中心の UI では、全文を見せる別画面や展開ボタン、詳細モーダルなどの手段を考える必要があります。つまり、アクセシビリティの問題は「スクリーンリーダー対応」だけではなく、「異なる操作環境で情報へ届くか」でもあります。
特に、テキスト切り詰めされたカード一覧をタップすると詳細へ行ける、といった設計は非常に自然です。一覧では短く、詳細で全文、という分担が明確だからです。つまり、アクセシビリティを意識するなら、省略した情報の行き先を用意することが大切です。
8. テキスト切り詰めで起きやすい問題
テキスト切り詰めは便利ですが、実際の現場ではかなり多くの「思った通りに動かない」問題が起きます。しかもその多くは、単に CSS を書き忘れたというより、レイアウト条件や情報設計の前提を見落としていることから起こります。たとえば、1 行省略が効かない、複数行省略が特定ブラウザで不安定、切り詰めた結果重要な情報が見えない、というのは非常に典型です。つまり、テキスト切り詰めは簡単そうに見えて、実は周辺条件への理解が必要なテーマです。
この章では、よくある問題を見ながら、なぜそれが起こるのかを整理します。原因を理解しておくと、CSS の丸暗記よりずっと安定した実装ができるようになります。
8.1 1 行省略が効かない問題
text-overflow: ellipsis; を書いたのに省略記号が出ない、というのは最もよくある問題です。その原因は、たいてい white-space: nowrap; や overflow: hidden; が足りない、あるいは幅制約が存在しないことです。また、Flex の子要素では min-width の影響で縮まないケースもあります。つまり、省略記号が出ないのはプロパティの一行が足りないというより、「この要素があふれる条件になっていない」ことが原因です。
この問題を解くには、要素単体ではなく親レイアウトまで見る必要があります。つまり、テキスト切り詰めは文字列制御ではなく、レイアウトの中で成立する現象だと理解することが重要です。
8.2 複数行省略が見た目とずれる問題
複数行省略では、フォントサイズ、行高、padding、親の幅、ブラウザ差分などによって、思ったより短く切れたり、逆に少し見えすぎたりすることがあります。特にデザインツール上で見ていた想定行数と、ブラウザ上の実レンダリングが完全には一致しないことがあります。つまり、3行で切る と指定しても、それが常に「ちょうど良い見え方」を保証するわけではありません。
この問題を避けるには、単にコードが動くかを見るだけでなく、実データと実画面幅で確認することが大切です。つまり、複数行省略は「書けば終わり」ではなく、見え方の検証込みで完成します。
8.3 情報が切れすぎて意味が失われる問題
UI がきれいにそろっていても、重要な情報が切れすぎてしまえば本末転倒です。たとえば商品タイトルの末尾に型番があり、それが毎回省略されてしまうと一覧での識別性が下がります。人名なら姓だけ見えて名が切れることもありますし、通知文なら肝心のアクション内容が後半にあって見えないこともあります。つまり、テキスト切り詰めは見た目だけを基準にすると失敗しやすいです。
そのため、何を前半へ寄せるべきか、どの情報は一覧で絶対に見えるべきか、といった内容設計も重要になります。つまり、テキスト切り詰めは CSS の問題である前に、情報設計の問題でもあります。
9. テキスト切り詰めの使い分け
テキスト切り詰めは、一つの方法を全画面に機械的に適用すれば良いものではありません。要素の種類、画面の役割、情報の優先度によって、1 行にするべきか、複数行にするべきか、そもそも切り詰めるべきではないかが変わります。つまり、テキスト切り詰めは CSS の部品ではなく、コンポーネントごとに最適な方針を決める設計課題です。
この使い分けを考えるときは、「一覧性」「可読性」「重要度」「全文への導線」の四つを見ると整理しやすくなります。何を優先する画面なのかで、最適な切り詰め方はかなり変わります。
9.1 タイトル・ラベル・ボタンでの使い分け
タイトルやラベルのように一覧性が重要なものは、基本的に 1 行または 2 行までの制限が向いています。特にボタンラベルやメニュー項目のように UI 部品自体のサイズが小さいものは、1 行で収めるほうが自然です。一方、記事タイトルのように一覧で意味がある程度伝わる必要があるものは、2 行程度許可したほうがよい場合があります。つまり、同じ短文でも、部品なのかコンテンツ見出しなのかで設計が変わります。
このとき、「全部 1 行」にしてしまうと情報量が足りず、「全部複数行」にすると一覧が重たくなることがあります。つまり、タイトル系では画面の読み方に合わせて行数を決めることが重要です。
9.2 説明文・本文抜粋での使い分け
説明文や本文抜粋は、1 行省略では情報が少なすぎることが多いため、複数行省略が向いています。記事カードのリード文、商品説明、レビュー抜粋などは、2 行から 4 行程度見せることで、内容の雰囲気を伝えつつ一覧性も保ちやすくなります。つまり、この種のテキストは「全部見せる」か「ほとんど見せない」かではなく、「必要最小限を見せる」設計が重要です。
また、ここでは行数だけでなく、詳細への導線も合わせて考えるべきです。抜粋である以上、その先をどう見せるかがないと不親切になりやすいです。つまり、説明文の切り詰めは一覧と詳細の役割分担の設計でもあります。
9.3 切り詰めないほうがよい場面
すべてのテキストに切り詰めが向いているわけではありません。エラーメッセージ、重要な警告、認可状態、支払い情報、確認ダイアログの本文などは、意味が途中で切れることで重大な誤解を招く可能性があります。こうした情報は、むしろ全文を見せるか、レイアウト側を広げるべきです。つまり、テキスト切り詰めは便利ですが、重要度の高い情報には慎重であるべきです。
この判断が重要なのは、UI の美しさより意味の正確さが優先される場面があるからです。つまり、切り詰める技術を知ること以上に、「切り詰めないほうがよい場所」を知ることも大切です。
おわりに
テキスト切り詰めは、一見すると ellipsis や line-clamp の書き方を覚えるだけのテーマに見えるかもしれません。しかし、実際にはそれ以上に広い意味を持っています。1 行で見せるのか、複数行で見せるのか、CSS で切るのか、JavaScript で切るのか、全文への導線をどう用意するのか、どの情報は絶対に切ってはいけないのかといった、UI 設計そのものに関わる判断が詰まっています。つまり、テキスト切り詰めは単なる見た目調整ではなく、情報の優先順位とレイアウトの安定性を両立させるための設計技術です。
実務では、まず「なぜ切り詰めたいのか」を明確にすることが大切です。見た目の統一のためなのか、一覧性のためなのか、レスポンシブ対応のためなのかによって、最適な方法は変わります。そして、そのうえで 1 行省略、複数行省略、CSS と JavaScript の使い分け、アクセシビリティ、レスポンシブ対応まで含めて考えられるようになると、単なる UI の表面ではなく、使いやすく壊れにくいコンポーネント設計に一歩近づけます。
