タグ: CSS

ボタンやカードの枠線にグラデーションをかけたい、という要望は制作の現場でよく出てきます。ところがこれまでのCSSでは、枠線そのものに直接グラデーションを指定する手立てがありませんでした。地方の小さなサイトから大規模サイトまで、デザイナーが同じ回り道を強いられてきた領域です。ここに動きがあったので共有します。

これまで枠線グラデーションは回り道が必要だった

border-colorには単色しか指定できません。そのためグラデーションの枠線を作るには、いくつかの遠回りな方法が使われてきました。代表的なのがborder-imageを使う書き方ですが、角丸との相性が悪く、border-radiusを当てると角が欠けてしまうという弱点があります。

もうひとつは、擬似要素や入れ子の要素を重ねて、背景のグラデーションを枠線に見せかける方法です。こちらは角丸にも対応できますが、余分なマークアップが増え、レイアウトの計算も複雑になります。SVGで枠を描いて重ねるやり方もありますが、いずれにしても本来の目的に対して手数が多すぎました。

結果として、枠線グラデーションは「できなくはないが、毎回コピーしてきた定型のコードを貼り付けて使う」ような、少し身構える表現になっていました。どれも「枠線にグラデーション」というシンプルな見た目のわりに、裏側の手間が大きいのが実情です。新しく担当する制作者がコードを読み解くときにも、なぜこんな構造になっているのか分かりにくいという副作用がありました。

background-clipにborder-areaという値が加わった

Chrome 150で、background-clipプロパティにborder-areaという新しい値が入りました。これは要素の背景を、枠線が描かれる範囲に沿って切り抜くという指定です。border-widthとborder-styleを踏まえて背景を枠線の形に合わせ、border-colorの透明度は無視します。

やっていることは単純で、背景にグラデーションを敷き、それを枠線の領域だけに見えるよう切り抜く、という発想です。border-imageのような専用の仕組みではなく、使い慣れた背景まわりのプロパティの延長で枠線を装飾できるのが利点です。角丸ともきれいに馴染みます。なおこの機能は先にWebKit系のブラウザが搭載しており、今回のChrome側の対応で足並みがそろった形になります。

実際の書き方と気をつける点

基本の流れは、background-imageにグラデーションを指定し、background-clipにborder-areaを指定し、あわせてbackground-originをborder-boxにする、という三点セットです。background-originを省くと初期値のpadding-boxで描かれてしまい、グラデーションの位置が枠線とわずかにずれます。ここは忘れやすい落とし穴なので、border-boxを明示しておくと安全です。

枠線を実際に見せるには、border-styleをsolidにしてborder-widthで太さを与える必要があります。透明な枠線では切り抜く範囲そのものが生まれないためです。破線や点線を指定すれば、その途切れた形のままグラデーションが乗るので、単なるグラデーション枠にとどまらない装飾も作れます。詳しい挙動はChrome 150の公式ブログにまとまっているので、導入前に一度目を通しておくとよいでしょう。

既存の背景色や背景画像と組み合わせたいときは、backgroundを複数レイヤーで重ねる書き方になります。枠線用のグラデーションと本体の背景を別々のレイヤーとして指定し、border-areaを枠線側のレイヤーにだけ効かせる、という整理をしておくと崩れにくくなります。

中小企業サイトでどう活かせるか

現時点では対応ブラウザがまだ限られるため、すべての来訪者に同じ見た目を届ける用途には早すぎます。実務では、枠線グラデーションを装飾の飾りと位置づけ、対応していないブラウザでは単色の枠線にフォールバックさせる考え方が無理のない使い方です。見た目が少し華やかになるかどうかの差であれば、対応環境だけで恩恵を受けられれば十分という判断もできます。

キャンペーンのバナーや、目立たせたいボタン、料金プランのカードなど、装飾の効果が効く場所は中小企業サイトにもよくあります。これまで擬似要素を積んで実現していた表現が、背景まわりの数行で書けるようになるのは、保守のしやすさという点でも歓迎できる変化です。ブラウザ全体に広がるのを待ちつつ、手元の環境で挙動を試しておくと、対応がそろったときにすぐ使い始められます。

ウェブサイトで「下にスクロールしていくと、画面に入った要素がふわっと動き出す」という演出はよく見かけます。これまでこの手の動きは、JavaScriptでスクロール位置を監視するか、専用のライブラリを読み込むのが定番でした。ところが最近のChromeに、こうした動きをCSSだけで指定できる新しい仕組みが加わりました。制作の手間が一段減りそうなので、いまのうちに内容を整理しておきます。

これまではJavaScript頼りだった

要素が画面に入ったタイミングでアニメーションを始めたい場合、多くの現場ではIntersectionObserverというJavaScriptの仕組みを使ってきました。要素が見えたことを検知し、クラスを付け外ししてCSSアニメーションを起動する、という流れです。

動かす方法としては十分ですが、監視するコードを書き、要素ごとに設定し、画面から外れたときの処理も考える、という作業が毎回ついて回ります。アニメーションを多用するページほど、JavaScript側の記述が積み重なっていきます。GSAPのScrollTriggerのような外部ライブラリを入れる手もありますが、読み込むファイルが増える分、表示速度への影響も気になるところです。

animation-trigger でCSSに寄せられる

新しく加わったのはanimation-triggerとtimeline-trigger、それにtrigger-scopeという3つのプロパティです。ざっくり言うと、「どの位置に来たら」「どのアニメーションを」再生するかを、CSSの中だけで書けるようになります。

まずtimeline-triggerで、監視したい範囲に名前を付けます。たとえば要素が画面に現れる範囲をview()で指定し、そこに--tのような名前を割り当てます。次に動かしたい要素側でanimation-triggerにその名前を書き、入ってきたら順に再生、出ていったら逆に再生、といった動作を指定します。Chrome for Developersの解説によると、カードが順に現れる演出や、文字が飛び込んでくる表現などが、この仕組みで組めるとされています。なお、トリガーの名前はページ全体から見えるため、同じ名前を複数の箇所で宣言すると最後のものが勝ちます。trigger-scopeで名前の見える範囲を絞っておけば、部品ごとに同じ名前を使い回せます。

細かい調整も効きます。要素がどこまで入ってきたら再生を始めるか、どの範囲にいる間は動いた状態を保つか、といった境目を指定できます。画面の下端に少し入った瞬間から動かす、まだ半分見えていないうちは静止させておく、といった塩梅を、値を書き換えるだけで整えられます。

JavaScriptで書いていた「見えたら動かす」という一連の流れが、スタイルシートの数行に置き換わるイメージです。要素が増えても、監視用のコードを書き足す必要はありません。

スクロール駆動アニメーションとの違い

少し紛らわしいのが、以前から話題になっている「スクロール駆動アニメーション」との違いです。スクロール駆動のほうは、スクロール量そのものにアニメーションの進み具合を結びつけます。スクロールを止めれば動きも止まり、戻せば巻き戻る、という連動です。

今回のスクロールで動き出すほうは性格が異なります。ある位置を通過した瞬間に、決まった長さのアニメーションを頭から再生する動きです。スクロールの速さに関係なく、いったん始まれば最後まで再生されます。JavaScriptのIntersectionObserverでやっていたことに近く、用途もそちらに寄っています。両者は名前が似ていますが、狙う演出が違うので、目的に応じて使い分けることになります。

現場で使うときの見極め

便利な仕組みですが、2026年の時点ではChromeとEdgeで先行して使える段階で、ほかのブラウザはこれからです。すべての来訪者に同じ動きを届けたい場面では、まだ本命として据えるのは早いかもしれません。

とはいえ、この種の演出は「あれば嬉しいが、無くても中身は読める」性質のものです。対応ブラウザでは動き、そうでなければ静止したまま表示される、という前提で組めば、いまから取り入れても実害はありません。中小企業サイトのトップページで、見出しや写真をさりげなく動かす程度の使い方なら、JavaScriptを減らす一歩として試す価値があります。WordPressで運用しているサイトでも、テーマのスタイルシートに数行足すだけで組み込めます。演出のためにプラグインを増やさずに済むのは、管理する部品が少なくなるという意味でも扱いやすい点です。仕様が固まってほかのブラウザにも広がれば、スクロールに連動した演出はCSSで書くのが当たり前になっていくはずです。

ツールチップやドロップダウンメニュー、吹き出し。ボタンの近くに小さな要素をぴたりと寄り添わせる場面は、ウェブサイトのあちこちにあります。ところが、この「ある要素を別の要素のそばに置く」という一見単純な処理が、これまでのCSSでは驚くほど手間のかかる作業でした。その状況を根本から変えるアンカーポジショニング(anchor positioning)が、2026年に入って主要ブラウザすべてで使えるようになりました。単なる新プロパティの追加ではなく、位置決めという古くからの悩みに対する設計思想の転換なので、少し腰を据えて整理しておきたいと思います。

これまでの位置決めがなぜ面倒だったのか

従来のCSSで要素を任意の場所に置く手段は、position: absolute でした。ただしこれは「親要素を基準にした座標」でしか位置を決められません。ボタンの真下にメニューを出したいとき、ボタンそのものを基準にすることができず、共通の親を用意して相対位置を調整する、といった回りくどい組み立てが必要でした。

さらに厄介だったのが、画面のスクロールやウィンドウのリサイズです。ボタンが動けばメニューも追従させなければなりませんが、CSSだけではそれを追いかけられません。そこで多くの現場が JavaScript に頼りました。要素の座標を getBoundingClientRect で毎回計測し、スクロールやリサイズのたびに再計算して位置を書き換える。この処理を安定して動かすのは意外に難しく、Floating UI や Popper.js といった専用ライブラリが広く使われてきたのは、まさにこの面倒を肩代わりするためでした。

つまり「要素を別の要素のそばに置く」という日常的な要件のために、数十KBのライブラリを読み込み、イベント監視のコードを書く。この構図が長らく当たり前になっていたのです。位置ずれの不具合報告が絶えなかったり、スクロール中にメニューがわずかにガタつく、といった細かな粗さに悩まされた記憶のある制作者も多いのではないでしょうか。

アンカーポジショニングの基本的な考え方

アンカーポジショニングは、この関係を CSS だけで宣言的に記述できるようにします。仕組みは素直です。基準にしたい要素、つまり錨(いかり)となる要素に anchor-name というプロパティで名前を付けます。名前はカスタムプロパティと同じくハイフン二つで始まる文字列です。一方、寄り添わせたい側の要素には position-anchor でその名前を指定し、どの要素に結びつくかを宣言します。

あとは anchor() 関数を使って、錨のどの辺を基準に自分をどこへ置くかを書きます。たとえば錨の下端を自分の上端に合わせれば、ボタンの真下にメニューが並びます。座標を計算するのはブラウザの役目です。錨が動けば結びついた要素も自動で追従し、スクロールしてもリサイズしても関係は保たれます。JavaScript のイベント監視も、再計算のループも要りません。ひとつの錨に対して複数の要素を結びつけることもでき、たとえばボタンにツールチップと補助メニューの両方をぶら下げる、といった構成も素直に書けます。位置の面倒をブラウザに任せられると、制作者は見た目の設計そのものに集中できるようになります。

position-areaで方向をわかりやすく指定する

anchor() 関数は柔軟ですが、上下左右の細かな指定を辺ごとに書くのはやや冗長になりがちです。そこで用意されているのが position-area というプロパティです。これは錨の周囲を九つのマス目に見立て、そのどこに要素を置くかを言葉で指定できる仕組みです。「錨の上」「右下」といった感覚で配置を書けるため、コードの意図が読み取りやすくなります。

ちなみにこのプロパティは策定の途中で inset-area という名前から position-area へ改称された経緯があり、Chrome でも 129 で名称が揃いました。少し前の解説記事では古い名前で書かれている場合があるので、参照するときは注意しておくとよいでしょう。

はみ出しを自動で回避するフォールバック

位置決めで最も神経を使うのが、画面の端での挙動です。ボタンの下にメニューを出す設計でも、そのボタンが画面の下端近くにあれば、メニューが見切れてしまいます。従来はこの判定も JavaScript で書く必要がありました。空きスペースを測り、足りなければ上に開く、といった条件分岐です。

アンカーポジショニングには、この切り替えを CSS だけで完結させる仕組みが備わっています。position-try-fallbacks というプロパティに候補の配置を並べておくと、既定の位置ではみ出しが起きたときにブラウザが順番に候補を試し、収まる配置を自動で選びます。より込み入った代替案は @position-try という規則で定義できます。判定はレイアウトの過程で自動的に行われ、リサイズ監視のコードは一切必要ありません。下に空きがなければ上へ、横が詰まっていれば別の向きへ、といった気配りをブラウザが肩代わりしてくれるわけです。

Popover APIやdialogと組み合わせて真価を発揮する

アンカーポジショニングが特に力を発揮するのは、HTML の popover 属性や dialog 要素と組み合わせたときです。popover 属性は、追加のコードなしで開閉できる小さな重ね表示をブラウザ標準で実現する仕組みで、メニューやツールチップの土台に向いています。ただし popover 属性だけでは「どこに出すか」までは面倒を見てくれません。ここに位置決めを担うアンカーポジショニングを重ねることで、開閉と配置の両方を標準機能だけで組み立てられます。

しかもこの組み合わせにはアクセシビリティ上の利点もあります。popover 属性や dialog 要素と一緒にアンカーポジショニングを使うと、キーボード操作の順序、つまりフォーカスの移動をブラウザが適切に補正してくれます。錨となるボタンから開いた要素へ自然に焦点が移るため、支援技術を使う利用者にも扱いやすい構造になります。メニュー、サブメニュー、設定ダイアログといった部品を、ライブラリ抜きで組み立てられる土台が整ったことになります。

導入をどう見極めるか

気になる対応状況ですが、アンカーポジショニングは Chrome が 125 から、Safari が 18.2 から対応し、最後まで残っていた Firefox も 147 で既定有効となりました。これで主要なブラウザエンジンがすべて出そろい、2026年時点でおよそ9割の利用環境をカバーする水準に達しています。新しい制作案件であれば、実務で採用できる段階に入ったと言ってよいでしょう。

とはいえ、少し前のバージョンのブラウザを使う利用者が一定数残るサイトもあります。中小企業のサイトで慎重に進めるなら、アンカーポジショニングが効かない環境でも致命的に崩れない設計、たとえば従来の配置を素の状態として残し、対応ブラウザではより洗練された位置決めが効く、という重ね方が現実的です。位置が多少ずれても内容は読める、という状態を保っておけば安全に導入できます。

ツールチップ一つのために外部ライブラリを読み込む時代が、静かに区切りを迎えつつあります。読み込むコードが減れば表示は軽くなり、保守すべき依存も減ります。派手さはないものの、こうした基盤の更新こそ、日々サイトを預かる制作者にとって地味に効いてくる変化だと感じています。

問い合わせフォームやアンケートを作っていると、テキスト入力欄の高さで毎回悩みます。狭くすると長文が書きづらく、広くすると空白ばかりで間が抜けて見えます。落としどころを最初に決めても、実際に届く文章の長さは人によってばらばらで、どこかで無理が出ます。これまでは入力量に合わせて欄を伸ばすのに、文字数や高さを測って調整するJavaScriptを書くのが定番でした。入力のたびに走らせる地味な処理ですが、行数計算や初期化の順番でつまずくと、意外と手のかかる部分でもありました。

この処理をブラウザ側に任せられるCSSのプロパティが、主要ブラウザで使えるようになりました。field-sizingです。MDNによると、field-sizingは2026年に主要4ブラウザ(Chrome、Edge、Firefox、Safari)が出そろい、安心して使える段階を示すBaselineの「新規利用可能」に入りました。数行のCSSで、フォーム部品を中身に応じて伸び縮みさせられます。

fixedからcontentへ切り替えるだけ

field-sizingが取る値は2つだけです。初期値のfixedは、これまでどおり決まった大きさを保つ従来の挙動です。もう一方のcontentを指定すると、部品が中身の分だけの大きさに縮み、文字が増えるほど広がっていきます。使い方も、対象の要素にfield-sizingをcontentと書くだけで、特別な初期化やイベント登録はいりません。

textareaに指定した場合、まず横幅の許す範囲で広がり、幅の上限に達すると今度は行を増やして縦に伸びます。高さの上限まで来ると、そこで初めてスクロールバーが出ます。つまり、入力が短いうちは小さく、長くなるにつれて必要な分だけ育つという自然な動きになります。content指定時はrowsやcols属性は効かなくなり、大きさの決定はCSS側に移ります。

textareaだけでなく入力欄や選択肢にも効く

このプロパティが便利なのは、複数行のtextareaに限らない点です。一行のtextやsearchといった入力欄でも、中身の幅に合わせて欄が伸びます。placeholderを設定しておけば、その文言が収まる程度の幅で表示されます。ただし入力を始めた時点でいったん最小幅まで縮み、そこから中身に合わせて広がっていきます。ファイル選択の入力欄では、選んだファイル名の長さに合わせて幅が変わります。

selectのドロップダウンにも効きます。通常は一番長い選択肢に合わせた幅で固定されますが、content指定なら今選ばれている項目の幅にぴったり合わせて幅が変わります。並びが間延びしがちな選択式の項目を、すっきり見せられます。フォームを構成する部品のほとんどが、同じ一つのプロパティで足並みをそろえられるわけです。

暴走させないための上限指定

中身に合わせて自由に伸びるということは、極端に長い入力で欄がレイアウトを押し広げてしまう心配もあります。そこでmax-widthやmax-heightで上限を、min-widthで下限を添えて、伸縮する範囲を枠にはめておくのが実務的です。上限まで来ればスクロールに切り替わるので、際限なく広がることはありません。逆に、widthやheightで固定寸法を決めてしまうと伸縮の余地がなくなるため、併用は避けます。文字数を制限したい欄では、maxlength属性が上限に達した時点で成長も止まります。

制作現場での使いどころ

中小企業サイトの多くは、問い合わせや資料請求といったフォームが成果につながる入口です。入力欄が窮屈だと、長めの相談内容を書く途中で書きづらさを感じて離脱されることもあります。入力に応じて欄が自然に広がるだけで、書き心地の印象は変わりますし、送信前に全文を見渡せる安心感にもつながります。

これまで数十行のスクリプトで実装していた自動リサイズが、一行のCSSで済むのも見逃せません。JavaScriptが減れば、その分だけ表示の負荷も保守の手間も軽くなります。Firefoxは対応が最後発だった経緯があるため、古い環境も想定する案件では、content指定を土台にしつつ、非対応のブラウザではこれまでどおりの固定サイズで問題なく使えるという前提で組んでおくと安心です。あってもなくても壊れない、あれば快適になるという足し方であれば、今日から少しずつ取り入れられます。ブラウザ標準の機能で書き心地を底上げできる場面は、着実に増えています。

ウェブサイトで外部の画像やフォントを読み込むとき、CSSでは長らくurl()にファイルの場所を書くだけでした。別ドメインからの取得方法や、ファイルが途中で差し替えられていないかの検証といった細かい挙動は、HTML側の属性やサーバー設定に任せるしかありませんでした。読み込みの見た目はCSSで書けるのに、読み込み方の安全面はCSSの外にある、という状態が続いていたわけです。Chrome 150(2026年6月30日公開)で、このurl()に読み込み方法そのものを書き足せる仕組みが正式に使えるようになりました。

url()の後ろに指定を書き足す

新しく加わったのは、url()の中でファイルのURLに続けて指定を書けるという書き方です。CORSの取得モードを決めるcross-origin()、ファイルの中身を検証するintegrity()、参照元の送り方を決めるreferrer-policy()の三つが用意されました。いずれもCSSの値に関する仕様で定められたもので、HTMLの属性でできていたことをスタイルシート側に持ち込む位置づけです。

たとえばbackground-image: url("photo.png" cross-origin(anonymous))と書けば、その画像はCORSの匿名モードで取得されます。これまでこうした制御はHTMLの<img>や<link>の属性でしか指定できず、CSSの中で完結させることはできませんでした。対象は画像だけでなく、フォント、SVGの参照、@importで読み込む別のスタイルシートにも同じ指定が使えます。装飾のためにCSSから直接読み込んでいたファイルほど、恩恵を受けやすい場所だと言えます。

ファイルの改ざんを検知する

三つの中でも制作の現場で注目したいのがintegrity()です。これはHTMLのSubresource Integrity(サブリソース完全性)と同じ考え方で、あらかじめ計算しておいたファイルのハッシュ値を書いておき、実際に取得したファイルのハッシュと一致するかを確認します。ハッシュはSHA-256やSHA-384といったアルゴリズムで求めた値を指定する形で、HTMLのintegrity属性と同じ書式です。一致しなければブラウザはそのファイルを読み込まず、表示にも使いません。

CDNに置いたフォントや、外部サービスから配信される装飾用ファイルが、配信元で差し替えられていないかを検証できるということです。Chromeはこのintegrity()を実際に照合しており、ハッシュが合わないファイルの描画をブロックします。共有のCDNを使う中小企業のサイトでも、想定していないファイルが紛れ込むリスクを一段下げられます。フォントを更新したときはハッシュも合わせて書き直す運用になるため、更新の手順に一つ手間が増える点だけは頭に入れておきたいところです。

CORSと参照元の指定

cross-origin()は別ドメインのファイルを取得するときのモードを指定します。フォントのように、そもそもCORSの許可がないと読み込めない種類のファイルもあり、これまではHTML側で気をつける必要がありました。referrer-policy()はファイルを取りに行くときに送る参照元情報の範囲を決めるもので、どのページから読み込んだかという情報を外部に渡しすぎないよう調整できます。いずれもこれまでHTMLの属性やHTTPヘッダーで設定していた項目を、スタイルシート側に寄せられるのが利点です。読み込みに関わる設定が一か所にまとまるぶん、後から見直すときの見通しもよくなります。

取り入れるときに見ておきたいところ

ブラウザ対応には差があります。Chrome 150は三つとも扱えますが、Safariはcross-origin()とreferrer-policy()を先行して実装した一方で、integrity()にはまだ対応していないとされています。改ざん検知を前提に組む場合は、対応していないブラウザではその検証が効かないことを踏まえて設計する必要があります。

この書き方は既存のCSSに追記する形で使えるため、対応ブラウザでは効き、非対応ブラウザでは従来どおり読み込まれるという形に収まります。まずは重要なフォントや外部の装飾ファイルなど、差し替えられると影響が大きい部分から試すのが現実的です。外部ファイルへの依存が多いサイトほど、少しずつ取り入れておく価値のある機能だと言えそうです。

CSSを書いていて、あるコンポーネントに当てたはずのスタイルが思わぬ場所まで波及してしまった経験は、制作に携わる人なら一度はあるはずです。ページ全体に効くというCSSの性質は便利な反面、扱う要素が増えるほど管理を難しくします。この課題に正面から向き合う@scopeという仕組みが、Safari 26.4の対応で主要ブラウザに出そろい、Baselineの新しく使える機能に加わりました。

これまでのCSS管理が抱えていた悩み

ウェブサイトのスタイルは、原則としてページ全体に対して効きます。あるボタンの色を変えたつもりが、別の場所にある似た要素まで巻き込んでしまう。ページ数が少ないうちは目視で追えますが、扱う画面が増え、複数人で長く運用するようになると、どこに何が効いているのかを把握しきれなくなっていきます。

こうした事故を避けるため、制作現場では長らく命名規則という工夫が使われてきました。BEMのように、クラス名へ役割や階層を細かく書き込む方式です。名前が重複しなければスタイルも衝突しない、という考え方で、多くの現場を支えてきた実績があります。

ただ、この方法はクラス名が長くなりがちで、書き手によって命名の揺れも生まれます。CSSの設計を保つために、人間の側が規律を守り続ける必要がありました。過去にはShadow DOMのように構造ごと分離する手段もありましたが、導入のハードルは低くありません。@scopeは、この範囲を区切るという役割を、CSSの標準機能そのもので肩代わりしようという発想です。

@scopeが実際にどう書けるのか

基本の形はシンプルです。適用範囲の起点となる要素を指定し、その内側だけにスタイルを効かせます。たとえば@scope (.card) { img { border-radius: 8px; } }と書けば、.cardの内側にある画像だけに角丸が当たります。同じimgでも、カードの外にある画像には影響しません。セレクタを.card imgのように長く連ねなくても、範囲を宣言するだけで意図が伝わります。どの要素にどのスタイルが効くのかが宣言の形からそのまま読み取れるため、後から見返したときの分かりやすさにもつながります。

この範囲の起点を、スコープの上限と呼びます。範囲の中で使える:scopeという擬似クラスは、その起点そのものを指し示すものです。囲った領域全体の背景や余白をまとめて整えたいときなど、起点の要素自体にスタイルを当てたい場面で役立ちます。

下限を決めて入れ子の穴をつくる

@scopeのもう一つの特徴は、範囲の下限も指定できる点です。起点と終点の二つを書くと、その間にある要素だけが対象になります。@scope (.card) to (.card__body) { ... }のように書けば、.cardから.card__bodyの手前までが範囲になります。

カードの中にさらに別のコンポーネントが入れ子になっている場面を思い浮かべてください。外側のカード用のスタイルが、内側に置いた小さな部品まで無用に踏み込んでしまうと、見た目が崩れます。下限を切っておけば、その内側は範囲の外として扱われ、影響を受けません。中央に穴が空いたドーナツになぞらえて、ドーナツスコープと呼ばれることもあります。ニュース一覧の中に埋め込みカードが混ざるような、実際のサイトでよくある構造で効いてくる機能です。

制作現場で使うときに知っておきたいこと

便利な一方で、優先度の扱いには注意が必要です。@scopeで囲んでも、セレクタ自体の詳細度が下がるわけではありません。範囲を絞ったから既存のスタイルに必ず勝てる、とは限らない点は押さえておきたいところです。既存のCSSと併用するときは、どちらが優先されるかを確かめながら進めると安全です。

もう一つ、範囲内で複数の起点が競合したときは、DOM上でより近い起点のスタイルが優先されます。この近さによる判定は従来のCSSにない考え方なので、頭で覚えるより、小さなサンプルで実際に挙動を確かめておくほうが早く馴染めます。

命名規則や大掛かりな設計手法に頼らずに、必要な範囲だけへスタイルを届けられる。少人数で長く手を入れていく中小企業のサイトほど、この素直さは効いてきます。既存のCSSをいきなり書き換える必要はありません。まずは新しく作るコンポーネントの一部で、小さく試すところから始めてみてはいかがでしょうか。

見出しやキャッチコピーの文字を、置いた箱の幅ぴったりに収めたい。制作の現場では誰もが一度は悩む場面だが、これまではJavaScriptで幅を測って調整したり、文字数を数えてフォントサイズを手で決めたりと、面倒な手当てが必要だった。専用の小さなライブラリを読み込んで文字を伸縮させたり、どうしても揃わない箇所はテキストを画像にして逃げたりと、割り切りを迫られることも多かった。この地味な悩みに、CSSだけで答える新しいプロパティが登場した。

Chromeの開発者向けドキュメントによると、2026年6月30日に安定版となったChrome 150で text-fit プロパティが使えるようになった。テキストノードのフォントサイズを、それを包む箱の幅に合わせて自動で拡大縮小してくれる仕組みだという。文字が短ければ大きく、長ければ小さく、箱の横幅を埋めるようにブラウザ側が調整する。開発者が文字数を数えて刻む必要も、スクリプトで幅を測る必要もなくなるというわけだ。

可変長のテキストで効いてくる

この機能が生きるのは、入る文字の長さが事前に読めない場面だ。CMSで運用しているサイトの見出し、商品名やキャンペーン名のように毎回長さが変わるテキスト、複数言語で文字量が大きく違うページ。こうした箇所でフォントサイズを一定に保つと、短い文字はスカスカに見え、長い文字ははみ出してしまう。text-fit を当てておけば、どんな文字数でも横幅が揃い、ページ全体の見た目が安定する。

似たことを狙う手段として、これまでは clamp() やビューポート単位でフォントサイズを画面幅に連動させる書き方が使われてきた。ただしそれらはあくまで画面の広さに比例させるもので、実際に入っている文字の量には反応しない。text-fit は箱に収まる文字そのものを見て縮尺を決める点が違い、狙いがより素直だ。中小企業のサイトでも、トップのヒーロー見出しやバナーのコピーは案件ごとに長さがまちまちで、運用の途中で文言が差し替わると崩れやすい。ブラウザが幅に合わせてくれるなら、こうした崩れの心配が減り、入稿の自由度も上がる。

ただし今のところ対応しているのはChromeが先行している段階で、ほかのブラウザはこれからだ。すぐに全環境で頼るのではなく、対応していないブラウザでは通常のフォントサイズで表示されるよう土台を整えたうえで、対応環境だけ恩恵を受ける形で足すのが現実的だろう。導入する際も、極端に長い文言を入れたときに文字が小さくなりすぎて読みにくくならないか、想定される最大の長さで一度確認しておくと安心だ。閲覧者の環境によって見え方が変わる機能なので、主要な組み合わせでざっと表示を見ておく手間はかけておきたい。長らくJavaScriptに任せていた処理が、また一つ標準機能に取り込まれていく流れの一つとして覚えておきたい。

ウェブサイトのレイアウトをグリッドやフレックスボックスで組んだあと、要素と要素のあいだに区切り線を入れたくなる場面は多い。カード一覧の列のあいだに細い罫線を引く、料金表のセルを線で仕切る、といった演出だ。ところがこれまでのCSSには、こうした隙間そのものに線を引く手段が用意されていなかった。Chrome と Edge の149で使えるようになった gap decorations は、その長年の空白を埋める機能になる。

これまでは擬似要素や枠線で工夫していた

グリッドやフレックスボックスの gap プロパティは、要素のあいだに余白を作れるが、その余白に色や線を付けることはできない。そのため制作現場では、各セルに border を付けて重なりを調整したり、::before や ::after の擬似要素で線を描いたり、背景にグラデーションを敷いて線に見せかけたりといった回り道をしてきた。

どの方法も、セルの数が変わったり折り返しが起きたりすると崩れやすい。線を引きたいだけなのに、レイアウトの計算まで巻き込んでしまうのが悩みどころだった。gap decorations は、この作業を余白側の仕事として切り出してくれる。

column-rule と row-rule で隙間に線を引く

マルチカラムレイアウトには以前から column-rule というプロパティがあり、段組みの段のあいだに線を引けた。新機能は、この column-rule をグリッドとフレックスボックスでも使えるように広げ、さらに横方向の隙間を担当する row-rule を新たに加えたものだ。

書き方は border とよく似ている。線の太さ、線種、色をそれぞれ column-rule-width、column-rule-style、column-rule-color で指定し、まとめて column-rule として一行で書くこともできる。row-rule も同じ構成だ。

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 24px;
  column-rule: 1px solid #ccc;
  row-rule: 1px solid #ccc;
}

大事なのは、これらの線が純粋に見た目だけの装飾で、余白の幅やレイアウトには一切影響しない点だ。線を足しても要素の位置がずれないので、あとから飾りを差し込む使い方に向いている。

フレックスボックスで要素が複数行に折り返すレイアウトでも、行と行のあいだに row-rule の線がきれいに収まる。列数や行数が中身に応じて変わる動的なレイアウトほど、擬似要素で線を管理する手間から解放される効果は大きい。

repeat()で線のパターンを作る

column-rule-width などには、グリッドのトラック指定でおなじみの repeat() が使える。これを使うと、隙間ごとに太さや色を変えたパターンを短い記述で作れる。たとえば数独の盤面のように、細い線を並べつつ何本かおきに太い線を挟む、といった表現だ。

column-rule-width: repeat(2, 1px) 4px repeat(2, 1px) 4px repeat(2, 1px);

線の位置を隙間の中央から少しずらす column-rule-inset のようなプロパティや、どの隙間に線を引くかを選ぶ仕組みも用意されている。縦の線と横の線が交わる交点の見せ方も細かく制御でき、交点で線を途切れさせるか、そのまま突き抜けさせるか、描画の重なり順をどうするかまで指定できる。単なる区切り線にとどまらず、表やカレンダー、価格表といった格子状のデザインを、擬似要素なしで組み立てられるようになる。

使えるブラウザと取り入れ方

gap decorations が正式に使えるのは、いまのところ Chrome と Edge の149からで、2026年6月に登場した。ほかのブラウザではまだ対応が追いついていないため、現時点では装飾の上乗せとして使うのが無難だ。

幸い、この機能は線を描くだけでレイアウトを動かさない。対応していないブラウザでは線が表示されないだけで、要素の並びや余白は保たれる。つまり、線があれば少し見やすく、なくても困らない、という段階的な取り入れ方ができる。地方の制作現場でも、まずは社内サイトや実験的なページで感触を確かめてから、対応ブラウザの広がりに合わせて本番へ持ち込むのが手堅い進め方になるだろう。

ボタンや見出しの背景色を決めたあと、その上に載せる文字を黒にするか白にするかで迷った経験は、制作に関わる人なら一度はあるはずです。背景が濃ければ白、淡ければ黒と感覚で選んでいくものの、配色のパターンが増えるほど組み合わせの管理は地味に重くなります。この「背景に対して読みやすい文字色を選ぶ」という判断を、CSSだけで自動化するcontrast-color()という関数が、主要ブラウザにようやく出そろいました。

背景色から文字色を自動で決める関数

contrast-color()は、引数に渡した色に対して黒と白のどちらがより高いコントラストになるかを判定し、読みやすいほうを返す関数です。色を指定できる場所であればどこでも使えるので、文字色の指定に組み込めば背景色に応じて自動的に切り替わります。

書き方はとてもシンプルで、背景にブランド色を変数で渡しているなら、文字色は次のように一行で済みます。

background-color: var(–brand); color: contrast-color(var(–brand));

判定にはWCAGのコントラスト比の考え方が使われており、読みやすさの最低限を機械的に満たしやすくなります。Chrome 147、Firefox 146、Safari 26と三つのブラウザエンジンが2026年に対応し、安全に使える機能をまとめたBaselineでも新たに利用可能の段階に入りました。ブラウザ間の挙動をそろえるInterop 2026の対象にも含まれており、どの環境でも同じ結果になることが期待できます。

これまでの配色対応との違い

ブラウザが標準で対応する前から、読みやすい文字色を得る方法はいくつかありました。JavaScriptのライブラリで表示時にコントラスト比を計算して色を当てる、Sassの関数であらかじめ対になる色を生成しておく、あるいは単純に人の目で一つずつ黒と白を決めておく、といった具合です。

どれも動きはしますが、手間と保守の負担は残ります。表示時に計算する方法は画面が出るまでにわずかな処理を挟みますし、ビルド時に色を固定する方法は背景色を変えるたびに対の色も作り直すことになります。手作業の指定は、ライトモードとダークモードで色の組を二重に持つことになりがちです。contrast-color()はこの判断をブラウザ側に任せるため、背景色を一か所変えれば文字色もそのまま追従します。

制作現場で効く場面

恩恵が分かりやすいのは、背景色が一定しない場面です。ブランド色をボタンに使うコンポーネントなら、色だけ差し替えれば文字の見やすさは自動で保たれます。ホバーで背景を明るくする演出を入れた場合も、必要に応じて文字色が白から黒へ切り替わります。

ライトとダークの切り替えとも相性がよく、prefers-color-schemeで背景の変数だけを入れ替えれば、文字色の組を別々に書く必要がなくなります。color-mix()などで動的に作り出した色にも追従するため、配色をプログラム的に生成する設計とも噛み合います。デザインシステムのように色をトークンとして一元管理する作り方とも相性がよく、土台の色を一つ変えるだけで関連する文字色がまとめて整うため、配色の調整にかかる手数を減らせます。

地方の中小企業サイトやCMSでは、色の設定を制作者以外が触る場面も少なくありません。管理画面でテーマ色を選ぶと文字色まで適切に決まる、という作りにしておけば、運用する人がコントラスト比を意識しなくても読みにくい配色になりにくくなります。納品後の更新で配色が崩れるリスクを下げられる点は、長く運用するサイトほど効いてきます。

使う前に知っておきたい制約

便利な一方で、現時点の仕様には割り切りもあります。返すのは黒か白のどちらかだけで、中間調の背景に対しては必ずしも最適な結果にならないことがあります。判定の方式を選べる拡張的な書き方も一部ブラウザで試験的に使えるものの、Baselineの範囲ではまだ標準化されていません。

そのため、重要なボタンや本文など可読性が要になる箇所は、自動任せにせず実際の表示で確かめる姿勢は残しておきたいところです。とはいえ、配色の土台を機械的に整える層として置いておく価値は十分にあります。これまで手で管理してきたコントラストの一部を、ようやくCSSそのものに預けられるようになったという意味で、地味ながら実務に効く一歩だと言えます。