2026年Web標準：Baseline分割とCSS Anchor Positioningの実装作例
Web標準が「使える」基準を書き換えた
2026年春、Google Chrome、Safari、Firefoxの3大ブラウザがそれぞれ新機能をリリースした。特に注目すべきは2点。Baselineの再定義と、CSS Anchor PositioningのSafari対応完了だ。これにより、開発者は「どのブラウザで動くか」ではなく「いつから安全に使えるようになったか」で判断できる時代に入った。
Baselineはもともと、主要ブラウザすべてで利用可能になった機能を「Baseline 2023」「Baseline 2024」といった年度で区切っていた。ところが2026年4月のアップデートで、Baselineは「baseline-low」と「baseline-high」に分割。新機能が最初の2ブラウザでサポートされた段階を「low」、3ブラウザすべてで揃った時を「high」と定義し直した。この変化は、開発者の実装判断に直接影響する。
なぜBaselineを分割したのか——実務的な理由
従来のBaselineは「全ブラウザOK」の一点指標だった。しかしChromeが先行実装し、SafariやFirefoxが追従するまでに数ヶ月から1年かかるケースが増えた。たとえばCSSのcontainerクエリや:has()疑似クラスは、Chromeが先にサポートした後もSafariが追いつくまで実戦投入しづらかった。Baselineが「low」を示せば、少なくとも2大ブラウザで動く保証が得られる。開発者はモバイルファーストの戦略をとる場合、iOS SafariとChromeの2環境を基準にコードを書けば良い。
実際のところ、多くのプロジェクトではiOS SafariとChromeがユーザーの90%以上を占める。Firefoxのシェアが小さい領域なら、baseline-low の機能を積極採用できる。ただし、公共性の高いサイトやアクセシビリティが厳格に問われるプロジェクトでは、引き続き baseline-high を待つべきだ。判断基準が明確になったことで、プロジェクトごとに「どのレベルのBaselineで実装するか」を事前に合意しやすくなった。
CSS Anchor Positioning：Safari対応のインパクト
CSS Anchor Positioning（anchor() 関数と position-area プロパティ）は、従来JavaScriptでしか実現できなかった、動的な要素の相対配置をCSSだけで制御する仕組みだ。たとえばツールチップをトリガー要素に自動追従させ、ビューポートからはみ出た場合に裏返す動作もCSSのみで記述できる。
従来はChromeとFirefoxのみの対応だった。2026年4月、Safari 18.4が anchor() と position-area をサポートしたことで、3大ブラウザすべてでAnchor Positioningが使えるようになった。ただし注意点もある。Safariの実装はinset-area ではなく position-area を採用しており、プロパティ名がChrome/Firefoxと異なる。現時点では position-area で統一されているため、ベンダープレフィックス不要だ。ただ、Safariのバージョンが18.4未満ではサポートされない。利用する前に @supports (position-area: bottom) で確認が必要。
実装上の3つの落とし穴
- パフォーマンス:
anchor()関数を多用するとレイアウト計算が増加する。動的に変化する要素に100個以上のアンカーを設定すると、スクロール時にカクつく可能性がある。SVG要素やCanvas内では使えない。 - アクセシビリティ: ツールチップをAnchor Positioningで実装した場合、スクリーンリーダーが正しい順序で読み上げるとは限らない。
aria-describedbyなどで明示的に関連付けが必要。 - フォールバック: Safari 18.3以下ではAnchor Positioningが完全に無視される。ポップアップやメニューはJavaScriptで代替実装を用意する必要がある。ただし、プログレッシブエンハンスメントの観点では、JavaScriptフォールバックは十分に軽量に書ける。
Baseline-low と Anchor Positioning を組み合わせる戦略
具体的な実装判断として、以下のフローを推奨する。
- ターゲットブラウザのシェアを確認。Chrome + iOS Safari + Android Chromeで95%をカバーするなら
baseline-lowを採用。 - Anchor Positioningを使いたい機能を選別。ツールチップやポップオーバーはフォールバックが容易。一方、ナビゲーションの配置など構造に関わる部分は
baseline-highを待つ。 @supportsで機能をチェック。非対応ブラウザ向けにはCSS GridやFlexboxの古典的手法で代替を記述する。
この戦略をとれば、開発者は「最新機能を安全に使いながら、非対応環境でも最低限のUXを保証できる」。結果的にコードのメンテナンスコストを下げられる。
2026年後半の展望
次に来るのは、View Transitions APIのクロスドキュメント対応と、CSSのscroll-driven animationsの標準化だ。View TransitionsはすでにChromeとSafariで部分サポートが始まっている。2026年中にbaseline-lowに入る可能性が高い。また、::checkmark 疑似要素（CSS-Tricksが紹介）は現在Safariのみサポートだが、ChromeとFirefoxが追随するか注目される。チェックマークを装飾で表現したい場合、現時点では ::before + content で代用するのが無難。
開発者は「機能が使えるか」だけでなく「いつから安全に使えるか」を常にウォッチする必要がある。Baselineのredefinitionはそのための羅針盤になる。
参照
この記事を書いた人
理人と理子
ギフプロのブログを運営している理人（リト）と理子（リコ）です！理は知性を表す漢字でもあるので、AIを連想させる名前にしてもらいました。ブログの内容はAIで作成しているところもありますが、読者の方にとって有意義な情報になるように完全自動化ではなく、人の目も通して作成しています！