プロンプトとスコープ
クロスブラウザ対応のデザインシステムにおいて、新しいCSS at-ruleがサポートされている環境では自然な入場アニメーションやビュートランジションを提供し、それ以外の環境では静的な体験を維持したいと考えています。ある2026年のChrome Web UIアップデートでは、@supports内で特定のat-ruleを検出することが説明されています。ファーストペイント、アクセシビリティ、テーマの一貫性を維持するロールアウトを設計してください。
面接官がテストしていること
面接官は、構文の認識と完全な動作を区別できているか、そしてカスケードレイヤー、フォールバック、視覚効果の抑制（reduced-motion）の処理、サーバーレンダリング、モニタリングを設計できるかをテストしています。優れた回答では、機能テストとしてブラウザ名をハードコーディングすることを避けます。
最初に明確にすべき質問
- その機能強化は装飾的なものですか、それともインタラクションがトランジションの完了に依存していますか？
- 新しいルールがサポートされていない場合の最小限の許容体験は何ですか？
prefers-reduced-motion、ハイコントラスト、キーボード操作の優先順位はどのようになっていますか？- ロールアウトは埋め込みWebView、古いブラウザ、およびSSRのファーストペイントをカバーする必要がありますか？
30秒の回答
「デフォルトのCSSでベースのレイアウト、状態、インタラクションを完全に構築し、その上でat-ruleの機能クエリの背後にオプションのスタイルを追加します。機能検出は拡張を有効にするかどうかを決定するだけであり、ランタイムの状態やアクセシビリティチェックを置き換えるものではありません。また、視覚効果の抑制が常に最優先されます。古いブラウザにはアニメーションなしの安定したパスが提供され、対応ブラウザにはトランジションが提供されます。拡大展開する前に、実際のブラウザマトリックス、ビジュアルリグレッション、キーボード操作、ファーストペイントのメトリクスを検証します。」
ステップバイステップの解決策
1. ベースライン体験を定義する
デフォルトレイヤーには、アニメーション終了イベントに依存することなく、完全なレイアウト、フォーカススタイル、エラーフィードバック、操作可能な状態を含める必要があります。アンマウント、ルート変更、ネットワーク障害が発生した場合でも、ターゲット状態に直接到達できなければなりません。
2. 機能と状態を分離する
at-ruleのサポートはCSS機能レイヤーに保持し、オープンや退出中などのコンポーネントの状態はクラスや属性に保持します。機能クエリはブラウザがルールを解析できるかどうかに答え、状態の選択はコンポーネントが今何を表示すべきかに答えます。これらは1つのブラウザ分岐ではありません。
3. カスケードとフォールバックを整理する
最初にベースルールを読み込み、次に@supports内に拡張ルールを追加します。拡張はオプションのプロパティのみをオーバーライドする必要があります。解析に失敗した場合、未知のブロックはベーススタイルを損なうことなく無視されるべきです。拡張によって重要なベースの寸法や色がリセットされないようにしてください。
4. モーション設定を尊重する
拡張レイヤー内では、フォーカス、閉じる動作、エラーフィードバックを明確に保ちながら、トランジションを短縮または無効化することでprefers-reduced-motion: reduceを尊重します。ビュートランジションのサポートがユーザーの設定を上回ることは決してありません。
5. SSRとWebViewをカバーする
最初のHTMLはクライアント側の検出を待つべきではありません。ベースライン構造をサーバー上でレンダリングし、クライアントがオプションの拡張を追加できるようにします。埋め込みWebView、古いブラウザ、部分的なサポート、無効化されたアニメーションをテストして、空白画面やレイアウトシフトを排除します。
6. 検証とリリース
ブラウザと機能のマトリックスを構築し、ビジュアルリグレッション、キーボードおよびスクリーンリーダーのチェック、CLS/LCPの比較、サンプリングされたエラーログを実行します。まずは1つのコンポーネントまたは低リスクなページでカナリアリリースを行います。リグレッションや苦情が増加した場合は、拡張スイッチを削除してベースラインパスを維持します。
模範解答
まず、新しい構文を使用せずに完全なベースラインレイアウト、状態モデル、アクセシビリティ動作を実装し、その上で@supports at-ruleクエリの背後にオプションのアニメーションを追加します。クエリは解析機能をチェックし、コンポーネントの状態はクラスや属性に残し、視覚効果の抑制をより高い優先順位とします。SSRはベースラインHTMLを出力するため、拡張に失敗しても無視されます。リリース前に、CLS/LCPとエラーフィードバックを監視しながら、古いブラウザ、WebView、SSR、キーボード操作、ビジュアルリグレッションをテストします。1つのコンポーネントをカナリアリリースし、失敗した場合は拡張スイッチのみを無効化します。
よくある間違い
- ブラウザ名での分岐 → ユーザーエージェントの乖離と誤分類 → 機能（capabilities）をクエリする。
- 解析サポートを完全な動作として扱う → 部分的な実装で差異が生じる → 実際のブラウザマトリックスとリグレッションスイートを実行する。
- 拡張によってベースの寸法をオーバーライドしてしまう → サポートされていないブラウザでレイアウトが崩れる → オプションのプロパティのみをオーバーライドする。
- 視覚効果の抑制を無視する → ユーザーが制御を失う → 拡張レイヤーでメディアクエリを再度処理する。
- ファーストペイントの前にクライアント側の検出を待つ → 空白画面やレイアウトシフトが発生する → ベースライン体験をSSRする。
フォローアップの質問と回答
@supportsのサポートがあれば、その機能を信頼するのに十分ですか？
いいえ。パーサーが条件を受け入れたことしか示していません。対象ブラウザで特定のat-rule、イベントのタイミング、フォールバックパスを検証してください。
なぜ古いCSSを削除しないのですか？
新しい機能は、WebView、エンタープライズブラウザ、支援技術環境には存在しない場合があります。ベースラインは永続的な契約であり、拡張は個別に削除可能である必要があります。
視覚効果の抑制はどのようにテストしますか？
自動テストおよび手動テストでprefers-reduced-motion: reduceを有効にします。アニメーションを短縮または削除しても、フォーカス、状態、閉じる操作が明確なままであることを確認します。
拡張機能はいつデフォルトにできますか？
目標のカバレッジ、視覚およびアクセシビリティのリグレッション、パフォーマンスメトリクス、エラー率が品質基準（gates）を満たし、ベースラインフォールバックが引き続き利用可能な状態になって初めて可能です。