タグ: ウェブデザイン

ブラウザの更新が続いていて、CSSだけで書ける範囲がまた少し広がっている。9月1日に公開されたFirefox 155と、8月にベータ版へ入ったChrome 153では、これまでJavaScriptを挟んで処理していたことや、回避策を組み合わせて実現していた表現が、スタイルシート側に移ってきた。

もちろん、実装されたばかりの指定をすぐ本番で使えるわけではない。ただ、どの方向に進んでいるかを知っておくと、いま組むサイトの設計や、数年後の書き直しの量が変わってくる。直近の更新から、頭の隅に置いておくと役に立ちそうなものを並べてみる。

HTMLの属性値をどのプロパティでも使えるようになった

CSSの attr() 関数は、これまで content プロパティの中でしか使えなかった。疑似要素にHTMLの属性値を文字として流し込む用途に限られていて、幅や時間の指定に使うことはできなかった。

Firefox 155では、この制限が外れて任意のプロパティで使えるようになった。width: attr(data-size px) のように単位を添えた型の指定ができ、値がなかったときのフォールバックや、名前空間つきの属性にも対応している。コンテナスタイルクエリの条件式の中でも使える。

棒グラフの長さや進捗バーの幅のように、データによって変わる数値をテンプレートから渡したい場面は多い。これまではインラインのstyle属性を書き出すか、JavaScriptで後から当てるかのどちらかだったが、data-属性に数値を入れておけばCSS側で受け取れる形になる。

色の透明度だけを差し替えられる関数

同じくFirefox 155で、alpha() 関数が使えるようになった。色を渡すと、他の成分はそのままに透明度だけを変えた色が返ってくる。関数の中では alpha というキーワードで元の色の透明度を参照できるので、alpha(from var(–brand) / calc(alpha * 0.5)) のように、元の値を基準にした計算も書ける。

ブランドカラーを変数でひとつ持っておき、ホバー時の背景や区切り線をそこから派生させる、といった使い方に向いている。色ごとに半透明版を別の変数として用意して二重に管理する、という手間が減らせる。

値の進み具合を数値として返す関数

progress() 関数も同じ更新で入った。開始値と終了値を渡すと、ある値がその間のどのあたりまで進んだかを数値で返す。opacity: calc(0.4 + progress(100cqw, 300px, 900px) * 0.6) と書けば、コンテナの幅が300pxから900pxへ広がるあいだに不透明度が変化していく。

これまでも calc() と clamp() の組み合わせで近いことはできたが、式が長くなって後から読み解きにくかった。どこからどこまで変化させたいのかが、そのまま式の形に出る。

スクロールの軸を分けて指定できるようにする動き

Chrome 153のベータでは、スクロールまわりの指定がふたつ増えている。ひとつは overflow プロパティで、scroll と clip を軸ごとに組み合わせて書けるようになる。overflow: scroll clip のように指定すると、position: sticky の固定範囲を軸ごとに別の祖先要素へ預けられ、clip を指定した側は動かないまま保てる。

もうひとつは scroll-axis-lock という新しいプロパティ。ブラウザは指やホイールの動きが片方の軸に大きく偏ると、その軸だけにスクロールを固定してしまうことが多い。誤操作を防ぐには合理的な挙動だが、地図や大きな図面のように斜めへ動かしたい領域では、固定がかからない角度から操作を始めないといけない、という不便につながる。この指定で、固定しないようブラウザへ伝えられる。

名前が変わったものと、まだ既定で無効なもの

Firefox 155では font-stretch プロパティが font-width という名前に変わった。旧名は別名として引き続き動くが、算出済みスタイルを列挙すると font-width のほうが返るようになっている。スタイルをJavaScriptから読み取って処理しているところがあれば、影響を受けないか確かめておきたい。

一方で、枠線の描画領域に背景を切り抜く background-clip の border-area や、スクロール量に連動するアニメーションは、Firefox 155では既定で無効のままだ。設定を切り替えれば試せるが、検証記事を読むときは、そのまま出荷されたものなのか、設定で有効にして試したものなのかを分けて見ておいたほうがいい。

ここに挙げたものは、いずれも片方のブラウザで実装が進んだ段階で、主要ブラウザで揃うまでにはまだ時間がかかる。中小企業のサイトで今日から使い始める類の話ではない。それでも、属性値や色や進み具合といった、これまでスクリプトに任せていた計算がCSS側へ降りてきているという流れは共通している。手元の案件で、これは本当にスクリプトが要るのかと一度立ち止まってみると、思ったより短く書ける箇所が見つかるかもしれない。

WebKitが公開しているSafari Technology Previewの最新版に、文字の見え方を細かく決めるCSSの追加がまとまって並んでいた。先行版のリリースノートは地味な項目の羅列になりがちだが、今回は日本語の組版に直接関わるものが混じっていて目に留まった。正式版に入る前の段階とはいえ、どこへ向かっているかは読み取れる。

ひとつはルビの張り出しを扱う ruby-overhang というプロパティだ。ルビは親文字より横に長くなることがあり、既定でははみ出した分が隣の文字に少しかぶる。指定できる値はこれまで、ブラウザの判断に任せる auto と、はみ出しを一切許さない none の二つだった。リリースノートによると、ここに spaces という値のサポートが加わり、張り出してよい相手を隣り合う空白や約物に限る、という中間的な指定ができるようになった。none は spaces の別名という扱いに変わっている。MDNのリファレンスでも、このプロパティの形式的な構文はすでに auto と spaces の二つで書かれていて、仕様側で進んでいた整理が実装に降りてきた形になる。

あわせて white-space-trim も入った。これは white-space を構成するプロパティのひとつで、要素の前後や内側に残る空白を捨てるかどうかを指定する。値は discard-before、discard-after、discard-inner を組み合わせて使う。テンプレートの改行やインデントがそのまま余白として出てしまう場面を、HTMLの書き方を詰めて回避するのではなく、CSS側で処理できるようにするものだ。MDNの white-space のページには、この構成プロパティはまだどのブラウザにも実装されていない、という注記が残っている。先行版に限った話とはいえ、実装が一つ出てきたことになる。

ほかにも、下線の位置をずらせる text-decoration-inset、箇条書きの記号そのものに content を指定できるようになった ::marker、要素の内側での折り返し方を扱う wrap-inside が並んでいる。修正の側にも、::selection に指定した text-decoration が描画されない問題や、直交する書字方向の子要素を持つブロックの幅がつぶれる問題が挙がっている。どれも派手さはないが、縦組みや細かな文字詰めを一度でも触ったことがあれば思い当たる類の話だ。

いま使うというより、頭の隅に置く段階

ここで挙げたものはSafariの先行版に入った段階で、正式版や他のブラウザで使えるかどうかはこれからの話になる。中小企業のサイトで来週から使う、という性質のものではない。ただ、ルビや余白の詰めは、これまで全角スペースの調整やJavaScriptでしのいできた領域でもある。ブラウザ側で素直に扱える方向へ仕様が動いていることを知っておくと、次に組版で困ったときに探す場所が一つ増える。リリースノートは項目ごとに短くまとまっているので、気になる分野だけ拾い読みしておくのでも十分だろう。

動画や音声を埋め込んだページで、再生が始まったら中央の大きな再生ボタンを消す、読み込み待ちの間だけ画面を少し暗くする、といった切り替えを組んだことはないでしょうか。こうした見た目の出し分けは、これまでJavaScriptで再生や停止のイベントを拾い、要素にクラスを付け外しして実現するのが定番でした。その状態の判定を、CSSの側から直接書ける指定がブラウザに入ってきています。

再生中か止まっているかを見分ける指定

Chromeの開発者向けブログが公開したChrome 152ベータ版の案内には、:playing、:paused、:seeking、:buffering、:stalled、:muted、:volume-lockedという疑似クラスが並んでいます。いずれもaudio要素とvideo要素を、そのときの状態にもとづいて選ぶためのものです。

MDNの説明によると、:playingはメディアが再生されている状態を表します。興味深いのは、いま実際に映像や音が進んでいる場合だけでなく、利用者の意思以外の理由で一時的に止まっている場合も再生中として扱う点です。つまり、回線が細くて読み込み待ちになっている最中も:playingに当てはまります。利用者が自分でボタンを押して止めたときが:paused、というすみ分けになっています。

読み込み待ちや消音といった細かい状態も拾える

:bufferingは、再生を続けたいのにデータが足りず、読み込みを待っている状態を指します。MDNには、:bufferingに当てはまる要素は:playingにも同時に当てはまる、とはっきり書かれています。待機中の表示を出しているあいだも再生中用のスタイルは効いたままになるので、両方が重なる前提で指定を組む必要があります。

:mutedは、音を出せる要素が消音されている状態です。似たものに:volume-lockedがありますが、こちらは端末やブラウザ側の設定によって、JavaScriptからは消音の切り替えも音量の変更もできない状態を指します。作り手が制御できる消音と、作り手には手が出せない音量の固定を、別々に見分けられるようになっているわけです。

書き方は素直で、MDNにはvideo:mutedに枠線を付ける例が載っています。video:not(:muted)と組み合わせれば、音が出ている状態との出し分けもできます。利用者が再生コントロールで消音を切り替えれば、その場でスタイルのほうも切り替わります。

状態の同期をスクリプトに任せなくてよくなる

この手の状態管理は、地味に事故が起きやすいところです。イベントの取りこぼし、同じ画面に複数の動画を置いたときの指定の衝突、画面を切り替えたあとに前の状態が残ってしまう、といった不具合は制作の現場ではおなじみでしょう。判定をブラウザ自身が持ってくれるなら、そもそも表示と実態がずれる余地が小さくなります。

地方の中小企業のサイトでも、会社紹介の動画や商品の紹介映像を置くことは珍しくありません。凝った独自プレーヤーを作らない場合でも、再生が始まったら重ねていた説明の見せ方を控えめにする、読み込みが長引いているときだけ待機中の表示を出す、といった調整はCSSの側だけで書けるようになります。スクリプトを増やさずに済む分、表示の軽さにも保守のしやすさにも効いてきます。

いまの対応状況と現実的な取り入れ方

ただし、すぐにどこでも使えるわけではありません。MDNの各ページには限定的な対応と表示されていて、広く使われているブラウザの一部では動かないためBaselineには達していない、と明記されています。手元のブラウザで動いたからといって、すべての来訪者に同じ見え方を届けられる段階ではない点は押さえておきたいところです。

一方でChromeの案内では、これらの疑似クラスがInterop 2026の重点分野の一つに挙げられています。Interopはブラウザごとの実装のばらつきを揃えていくための取り組みなので、そこに入っているということは、対応が広がる方向で足並みが揃いつつあると読んでよさそうです。

現実的な取り入れ方は、これまでどおりの作りを土台に置いたうえで、対応しているブラウザでは見え方がもう少し気の利いたものになる、という上乗せの形でしょう。動かないブラウザでも困らない範囲から試してみると、次にプレーヤーまわりを触るときの引き出しが一つ増えます。

グリッドやフレックスで要素を並べたあと、そのすき間に細い線を入れたくなる場面は多い。カード一覧の区切り、料金表の縦線、記事リストの横罫。デザインとしてはごく普通の表現なのに、CSSで素直に書ける指定がなく、制作側が毎回それらしい形に組み立ててきた領域だった。ここへ来て、その部分がブラウザ側で片付きはじめている。

すき間に線を引くために、これまでやってきたこと

いちばん多かったのは、並べた要素そのものに枠線を付ける方法だろう。カードの右側にだけ線を引き、行末の要素は擬似クラスで線を消す。三列で組んだグリッドなら、三の倍数番目を狙って消していく。動くには動くが、列数がブレークポイントごとに変わると、消す対象も一緒に書き換えなければならない。

フレックスで折り返す並びだと事情はもっと厄介になる。何番目で折り返すかは中身の幅次第なので、要素の番号を狙う書き方が成り立たない。仕方なく擬似要素を絶対配置で置いたり、親に背景色を敷いてすき間だけ透かして線に見せたり、要素の背景色との差で線を演出したりしてきた。どれも見た目は作れるが、線の色を変えたいだけの依頼で三箇所直すことになる。

背景色を敷いて線に見せる手も、条件がそろえば見た目はきれいに決まる。ただし親の背景が写真やグラデーションだと途端に成立しないし、余白の値を変えると線の太さまで一緒に動く。ダークモードの切り替えを入れると、線の色ではなく背景色を二重に管理することになり、あとから読む人には何が線で何が下地なのか分かりにくい。

要するに、線を引くための仕掛けが、線とは関係のない場所に散らばっていた。すき間そのものを指定できる手段がなかったからで、これは書き手の工夫が足りないという話ではなかった。

もともと段組みだけのものだった指定が広がった

CSSには以前から column-rule という指定がある。ただしこれは段組みレイアウト専用で、グリッドやフレックスでは効かなかった。線を引く指定は存在するのに、いちばん使いたいレイアウトでは使えない状態が続いていたわけだ。

今回入ったのは、この column-rule をグリッドとフレックスにも広げ、さらに横方向のすき間に線を引く row-rule を新しく用意する、という変更になる。Chromeの開発者向けブログによると、ChromeとEdgeのバージョン149から既定で有効になった。段組み、グリッド、フレックスのいずれでも同じ書き方が通る。

書き味としては枠線の指定とほとんど同じで、太さと線種と色をまとめて渡すだけでいい。要素の何番目かを数える必要はなく、折り返しが増えても減っても、すき間があるところに線が入る。列数をブレークポイントで切り替えても、線の指定はそのままでいい。この一点だけでも、日々のCSSの見通しはかなり変わる。

交差やはみ出しをどこまで決められるか

実際にやってみると気になるのが、細部の扱いだ。縦線と横線が交わるところをどうするか、線をすき間いっぱいまで伸ばすのか少し余らせるのか、中身の入っていない列にまで線を出してしまわないか。この手の判断は、これまで擬似要素の位置調整でごまかしてきた部分でもある。

新しい仕様では、そこにもそれぞれ指定が用意されている。交差点の処理は column-rule-break と row-rule-break、線をどこまで伸ばすかは column-rule-inset と row-rule-inset、空の行や列に線を出すかどうかは column-rule-visibility-items と row-rule-visibility-items が受け持つ。開発者向けの試用段階では伸縮の指定が別の名前だったが、仕様の側に合わせて整理された経緯がある。

加えて、線の太さや色、伸縮の量はアニメーションの対象になる。マウスを載せたときにだけ区切り線をうっすら出す、といった演出が、余計な要素を足さずに書けるということでもある。細かい話に見えるが、ここまで決められるかどうかで、回避策から本当に卒業できるかが分かれる。

使えるブラウザと、いまの構え方

現時点で対応しているのはChromiumを土台にしたブラウザで、SafariとFirefoxはまだ入っていない。ここは正直に見ておいたほうがいい。日本の中小企業サイトだとiOSのSafariの比率が高い案件も珍しくないので、いますぐ全面的に頼れる指定ではない。

ただ、この機能は使えなかったときの壊れ方が穏やかだ。対応していないブラウザでは、すき間に線が出ないだけで、レイアウトそのものは何も崩れない。区切り線が装飾として効いている程度の場面なら、対応済みのブラウザで少し丁寧に見える、という積み増しの使い方ができる。線がないと情報の区切りが読み取れない、という設計になっている場合だけ、従来の手法を残しておけばいい。

従来の手法を残す場合も、両方を無条件に書くと対応済みのブラウザで線が二重になる。対応しているかどうかで書き分ける @supports を挟んでおくと、この衝突は避けられる。新しい指定が使える環境では新しい書き方を、そうでない環境では今までの回避策を、という形にしておけば、数年後にSafariとFirefoxが追いついた時点で、古いほうのかたまりを削るだけで済む。移行の作業を先に用意しておく、という考え方に近い。

未対応のブラウザ向けのポリフィルも開発が進んでいるとされている。ただ、装飾のためにスクリプトを足すのは本末転倒になりやすいので、まずは飾りとして入れて様子を見る、という順番が現実的だと思う。

見た目の細部がCSS側に寄っていく流れ

この変更を単体で見ると、便利なプロパティが増えた、という話で終わる。ただ、ここ一年ほどのCSSの動きを並べると、同じ方向を向いた変更が続いていることに気づく。

たとえば、並んだ要素に少しずつ時間差を付けて動かす書き方は、長らく要素の番号を手で書き並べるか、スクリプト側で遅延を計算するしかなかった。それが、自分が何番目の兄弟かをCSSの中で数えられる関数として一部のブラウザに入りはじめている。枠線の形をもっと自由に扱うための border-shape のような提案も議論が進んでいて、CSS-Tricksあたりでは繰り返し取り上げられている。

共通しているのは、見た目のために増やしていたマークアップやスクリプトを減らす方向だということだ。区切り線のための空の div、時間差のための番号付きクラス、位置合わせのための擬似要素。こうしたものは、書いた本人以外には意図が読み取りにくく、引き継いだ制作者が触りにくい部分でもあった。指定として名前が付くと、少なくとも何をしたかったのかは残る。

受け継いだサイトを触る側から見ると

制作会社としてありがたいのは、新規で作るときの快適さより、あとから触るときの読みやすさのほうかもしれない。他社が作ったサイトを引き継いで直す仕事では、擬似要素で引かれた線の位置が微妙にずれている、といった相談がわりとよくある。中身を追うと、当時の列数を前提にした番号指定が残っていて、その後の改修で列数だけが変わっていた、という筋書きだ。

すき間に線を引く指定が一行で済むなら、こうした置き土産は減っていく。すぐに全部を書き換える必要はないし、動いているものを触るリスクのほうが大きい場面も多い。ただ、次にそのブロックへ手を入れるとき、回避策を継ぎ足すのではなく、素直な指定に置き換えられる選択肢ができたのは小さくない。

新しい指定が出るたびに全部追いかける必要はないと思う。それでも、長く回避策で埋めてきた場所が正面から解決されたときは、覚えておくと後で効いてくる。区切り線はまさにその手の場所だった。

Safariの次の版のベータが公開され、58件の新機能と525件の修正が入るとされています。WebKitの発表を読むと、目新しい機能を数多く並べるというより、既存の機能の細かい挙動を揃える作業に重心が置かれているのが分かります。

とはいえ、制作の現場ですぐ効きそうな追加もいくつか含まれています。中小企業のサイトでも出番がありそうなものを、順に並べてみます。

セレクト要素の見た目を組み直せるようになる

フォームのセレクトボックスは、ブラウザごとに見た目が違ううえ、選択肢の並びに手を入れられない部分が長く残っていました。デザインに合わせたい場合、select要素を捨ててdivとJavaScriptで作り直すのが定番の回避策です。

今回のベータではappearance: base-selectに対応し、本来の要素のまま見た目だけを組み直せるようになります。キーボード操作や読み上げ、フォーム送信の挙動は標準のまま残るので、作り直したときに抜けがちな部分を自前で用意しなくて済みます。問い合わせフォームのように、崩れると直接損をする箇所ほど恩恵が大きいところです。

遅れて読み込まれた要素で読む位置がずれない

記事を読んでいる途中で、画面の上のほうにある画像や埋め込みが遅れて表示され、本文が下に押し出される。よくある不快な挙動です。スクロールアンカリングは、こうしたときに表示位置を自動で補正して、読んでいた行を保ちます。

他のブラウザではすでに動いていた機能なので、Safariが加わることで挙動の差が縮みます。ただし、画像に幅と高さを書いておくといった基本の対策が不要になるわけではありません。ブラウザ側の補正はあくまで最後の受け皿と考えておくのが安全です。

見出しをまとめて指定できる疑似クラス

:headingは、h1からh6までをまとめて指す疑似クラスです。これまではセレクタに六つ並べて書くのが普通で、余白や行間を揃えたいだけの場面では冗長でした。

書く量が減るだけの小さな追加に見えますが、見出しの階層が増えたり減ったりする構成では、書き漏らしを防ぐ意味もあります。ブログのように書き手が複数いるサイトでは、想定していなかった深さの見出しが入ることも珍しくありません。

余白まで含めて幅を伸ばすstretchという値

幅や高さの指定にstretchという値が使えるようになります。親の中で余白の分まで含めて伸ばす指定で、これまでcalcを使って余白を引いて調整していた場面を素直に書けます。

あわせてrevert-ruleというキーワードも入りました。そのルールが当たる前の状態まで戻す指定で、後から足したCSSが積み重なって入り組んだサイトの調整に向きます。どちらも派手さはありませんが、既存サイトに手を入れる仕事では出番がありそうです。

画像のsizes属性をブラウザに計算させる

遅延読み込みを指定した画像で、sizes属性にautoと書けるようになります。実際のレイアウト幅をブラウザが測り、srcsetに並べた候補から適したものを選びます。

これまでは画面幅ごとの表示幅を自分で書き並べる必要があり、レイアウトを変えるたびに書き直す手間がありました。書いた値が実際のレイアウトと食い違うと、必要以上に大きい画像を読み込んでしまいます。手作業の当て推量が減るのは、表示速度の面でも助かります。

同じ時期に出たChromeの新しい安定版には、矢印キーでの項目移動を属性の指定だけで有効にできるfocusgroupが入っています。片方は新しい書き方を先に出し、片方は既存の機能の足並みを揃える。方向は違いますが、どちらも自前のスクリプトで埋めていた部分を標準側に寄せる動きです。実務では、対応が片方だけの機能はしばらく補助的に添える程度にとどめ、両方に入ったものから本番へ回すのが無難だと思います。

ボタンやカードの枠線にグラデーションをかけたい、という要望は制作の現場でよく出てきます。ところがこれまでの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割の利用環境をカバーする水準に達しています。新しい制作案件であれば、実務で採用できる段階に入ったと言ってよいでしょう。

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

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