マイクロインタラクションの記事では、transformとopacityがコンポジタースレッド上でアニメーションするので、重いページでもボタンのアニメーションがカクつくことはないはずだと書いた。それは今も真実だ——ただし、あの記事が触れていなかった一つの留保がある。メインスレッドが長いJSタスクによってブロックされていれば、アニメーションはそもそも起動する機会すら得られないかもしれない。クリックのハンドラ自体がキューで待たされているからだ。INPはまさにこのギャップを測る指標であり、scheduler.yield()はそれを実際に埋めるための数少ない手段の一つである。
千件のコメントを含むリストのレンダリングが遅いので react-window に手を伸ばす——すると、なめらかなスクロールと引き換えに、Ctrl+F、ページの印刷、そしてスクリーンリーダーのナビゲーションの一部を失うことになる。表示ウィンドウの外にある要素が、DOMから物理的に存在しなくなってしまうからだ。content-visibility はまったく別の角度から同じパフォーマンス問題を解決する。要素はDOMに残ったままで、ブラウザはただ、要素が表示領域の近くに来るまで、レイアウトや描画といったコストの高い処理をその要素に対して省略するだけだ。そして驚くべきことに、テキストを検索したときには一時的にその要素を『見える状態』に戻すことさえできる。
アクセシビリティの記事で取り上げた、`display: none`で隠されているのにアクセシビリティツリーには残り続けていたモーダルは、divをゼロから組み立ててモーダルを作ることに起因するミスの一例でした。本当に問うべきなのは、そもそもなぜゼロから作らなければならなかったのか、ということです。ネイティブな`<dialog>`とpopover属性が無料で提供してくれるもの——top layer、フォーカストラップ、light dismiss——を確認し、この二つの仕組みがどこでどれほど違うのか、その違いを取り違えることがいかに簡単にアクセシビリティを欠いたインターフェースへの近道になるかを見ていきます。
「いいね」ボタンは即座に反応し、ハートが塗りつぶされ、カウンターが増える——サーバーがまだ何一つ応答していないうちに。これはマイクロインタラクションの記事で扱った速さの錯覚よりも一歩踏み込んだものです。インターフェースがまだ存在しない状態を表示し、それがすぐに実現すると仮定しているのです。この仮定が外れたときに本当に嘘を撤回できる、安全な作り方を確認します。そして、手動の`setState`と`catch`が、`useOptimistic`が提供するものの劣化版でしかない理由も見ていきます。
ユーティリティクラス`.mt-4`は、論理的には後から追加された分勝つはずなのに、`.card .card__header .card__title`というルールに負けてしまいます。これは偶然ではなく、詳細度が設計通りの仕事をしているだけです。`@layer`は、詳細度と一緒にではなく、その手前で働くまったく新しい対立解決の軸を導入します——そして、ネット上のドキュメントの一部さえ誤って説明してしまうほど直感に反する落とし穴が一つあります。
「use server」は、APIルートへのfetch呼び出しに対する単なるシンタックスシュガーのように見えます。だからこそ、多くの実装はこれをただの関数呼び出しとして扱ってしまいます。これは具体的な代償を伴う誤解です。「use server」と記されたすべての関数は、ネットワーク上の公開エンドポイントになります。そして、この仕組みの上に作られたフォームは、JavaScriptが読み込まれる前から動作します。このディレクティブの裏側で実際に何が起きているのか、そしてドキュメントを一目見ただけでは分からない落とし穴がどこにあるのかを確認していきます。
フォームのフィールドは、中のinputが不正な値のとき赤くハイライトされるべきである。単純な話に思えるが、CSSは25年もの間、要素に対してその内側で何が起きているかを問い合わせる方法を持たず、その逆しかできなかった。:has()がこの方向をどう逆転させるのか、通常のコンビネータとどう違うのか、そしてこの新しい力が実際にパフォーマンス上のコストを伴う場面はどこかを見ていく。
同じ商品カードなのに、グリッドでは美しく見え、狭いサイドバーでは崩れてしまう——メディアクエリを注意深く選んでいたとしても。問題はコードにあるのではなく、メディアクエリがそもそも何を尋ねているかにある。画面の幅を尋ねているのであって、そのコンポーネントが実際に与えられたスペースを尋ねているわけではない。コンテナクエリがこの問いをどのように本来あるべき場所へ移し、要素が『クエリのコンテナ』になったとき実際に何が起きているのかを見ていく。
正しいHTMLはあくまで出発点にすぎない。アクセシビリティツリーの実際の仕組み、ARIAが思っている以上に害になるケース、そして実際に動くアコーディオン・ライブリージョン・Next.jsのフォーカス制御を一緒に作りながら見ていく。
CSS Houdiniは単一の技術ではなく、成熟度がまちまちな仕様の集合体です。今どの部分が本番投入に耐えるのか、`@property`とpaint workletが実際にどう動くのか、そして残りがなぜ今なお実験段階のままなのかを確認しましょう。
同じ商品、同じサーバー応答時間のふたつのストア。それでも一方は明らかに速く、信頼できるように感じられます。その差を生むのがマイクロインタラクション――ユーザーが画面上の出来事を信じられるかどうかを決める、わずか数百ミリ秒のアニメーションです。トリガー/フィードバックのモデル、ブラウザのレンダリングエンジン内部で実際に起きていること、そしてprefers-reduced-motionまで、基本原理から解説します。
