インラインの限界を超える：`text-overflow`と省略記号の深淵なる実装
Webフロントエンドの世界において、「テキストの省略」ほど見かけによらずエンジニアを苦しめる要件はない。特に、コンポーネント指向の現代において、インライン要素内での動的な省略制御は、ただCSSを書けば済むというレベルをとうに超えている。
我々のようなテックリードが直面するのは、「なぜか省略されない」「動的に中身が変わるとレイアウトが崩壊する」「レンダリング負荷でスクロールがカクつく」といった、ブラウザエンジンの挙動に根ざしたトラブルだ。今日は、単なる`text-overflow: ellipsis`の解説ではない。堅牢なアプリケーションを支えるための、実装の流儀について深掘りしよう。
—
1. インライン要素に`ellipsis`が効かない理由を再考する
まず大前提として、CSSの仕様上、`text-overflow: ellipsis`はブロックレベル、あるいは`display: inline-block`（または`flex`, `grid`）が適用された要素に対してのみ機能する。
`span`や`a`タグなどの純粋なインライン要素にこれを適用しようとして頭を抱えるジュニアは多い。インライン要素は「行ボックス」の一部であり、幅の概念が曖昧だからだ。
/ 陥りがちなアンチパターン /
span.truncate {
text-overflow: ellipsis; / 無効！ /
overflow: hidden;
white-space: nowrap;
width: 100px; / インライン要素には幅が適用されない /
}
/ 現場での解法 /
span.truncate {
display: inline-block; / 物理的な幅を持たせる /
max-width: 100%; / 親要素の制約に従わせる /
vertical-align: bottom; / ベースラインのズレを防ぐ /
text-overflow: ellipsis;
overflow: hidden;
white-space: nowrap;
}
この「インライン要素をブロック化する」という操作は、実はレンダリングパスに影響を与える。過度な`inline-block`の乱用は、レイアウト計算時のリフロー範囲を広げ、複雑なDOM構造下ではレンダリングパフォーマンスの劣化を招く。特にリストレンダリングにおいては、`contain: layout`などのCSSプロパティを併用し、レイアウト計算のスコープを制限することを検討すべきだ。
—
2. 非同期データと「不確定な幅」の戦い
実務で最も厄介なのは、「APIから返ってきた文字列を省略したいが、親要素の幅も動的に変動する」というケースだ。
例えば、ReactやVueで`props`を通じてテキストを流し込む場合、DOMがマウントされた瞬間の幅と、画像や外部フォントがロードされた後の幅が異なることがある。この「タイミングのズレ」により、`ellipsis`が正しく計算されず、中途半端な位置で切れたり、逆に突き抜けたりするバグが発生する。
この問題を解決するには、ResizeObserver API を活用したカスタムフックが最も堅牢だ。
/
- 要素の幅を監視し、オーバーフロー状態を検知するカスタムフック
/
export const useTruncation =
const [isTruncated, setIsTruncated] = useState(false);
useEffect(() => {
const element = ref.current;
if (!element) return;
const observer = new ResizeObserver(() => {
// scrollWidth が clientWidth を超えていれば、省略が発生していると判断できる
setIsTruncated(element.scrollWidth > element.clientWidth);
});
observer.observe(element);
return () => observer.disconnect();
}, [ref]);
return isTruncated;
};
このように、CSSによる省略（視覚的な制御）と、JavaScriptによる状態検知（インタラクションやツールチップ表示の制御）を分離するのが、上級者の設計だ。
—
3. エッジケースを制する：日本語と禁則処理
省略記号の扱いで見落とされがちなのが、マルチバイト文字（日本語）における「禁則処理」だ。`text-overflow: ellipsis`はブラウザのデフォルト挙動に依存するため、ギリギリの文字数で「句読点」や「閉じ括弧」が不自然に省略されることがある。
もしプロダクトのUXとして「完璧な省略」を求めるなら、CSSだけで解決しようとせず、以下の戦略を推奨する。
1. CSSでハードな制限をかける: 基本はCSSで行い、軽微なズレは許容する（パフォーマンス優先）。
2. キャンバスで文字幅を計算する: どうしても特定の文字数で厳密に切りたい場合、`OffscreenCanvas`や`measureText`を用いて、文字単位でトリミングを行う（高負荷なので、必要な箇所のみに限定）。
特にテックリードたるもの、「100%の正確性」と「60fpsの描画速度」のどちらを優先すべきかというトレードオフを常に天秤にかける必要がある。ほとんどの場合、CSSの`ellipsis`で十分であり、過剰なJS実装はレンダリング性能を殺すだけだ。
—
結び：エンジニアリングとしての省略
インライン要素の省略は、単なる見た目の調整ではない。それはWebアプリケーションの「制約」と「データ」の衝突点だ。
- メモリ効率: DOM要素を不必要に生成していないか？
- レンダリング: `text-overflow`の計算コストを抑えるDOM構造になっているか？
- 型安全: TypeScriptで省略の有無を状態として管理し、UIの矛盾を防いでいるか？
これらの問いに自問自答し、泥臭くブラウザの挙動を検証し続けること。それこそが、ただの「画面を作る人」から「システムを設計する人」へと進化する、我々の仕事の醍醐味ではないだろうか。
次のプルリクエストでは、ぜひ「なぜこのCSSを選択したのか」「このレンダリング負荷は許容範囲内か」をチームメンバーに語れるような実装を心がけてほしい。それが、世界最高峰のフロントエンドを創るということだ。
コメント