プロンプトとスコープ
あなたはクロスブラウザ対応のカードコンポーネントを担当しています。モダンブラウザは bevel、scoop、および squircle をレンダリングできますが、古いブラウザは border-radius のみを認識します。corner-shape の前提条件、フォールバック、視覚面およびインタラクション面の受け入れ基準を説明してください。
これは CSS の幾何学、プログレッシブエンハンスメント、コンポーネント設計力をテストするものです。corner-shape は既存の border-radius によって生成された角を変更するものであり、半径が 0 に解決される場合は効果がありません。回答では描画（painting）、コンテンツレイアウト、ポインターのヒットエリアを切り離して説明してください。
面接官がテストしていること
優れた回答では、実用的な border-radius のベースラインを維持し、機能クエリ（feature query）の内側に拡張機能を配置します。1 つから 4 つの値による角の順序指定、正および負の superellipse() 曲率、対向する角が重なるときの半径の制約、およびどの描画効果が形状に追従するかを説明します。
また面接官は、この形状をコンテンツのクリッピングとして扱わないことも求めています。MDN が指摘するように、コンテンツは元のボックスに対して配置され、ホバーは可視コーナーの外側でも適用され得るため、フォーカスの視認性とヒットテストには個別の検証が必要です。
明確化のための質問
古いブラウザでどのような外観を維持する必要があるか
角丸カードで十分な場合は border-radius を維持します。ブランドの幾何学的形状を厳密に一致させる必要がある場合、SVG や擬似要素によるフォールバックはメンテナンスとレンダリングのコストを増加させます。
形状がインタラクション境界を定義するか
リンク、ボタン、ドラッグ対象が視覚的な輪郭と一致する必要があるかを確認します。CSS の角形状は必ずしもコンテンツやイベントのヒットテストを変更するわけではないため、スクリーンショットだけでは不十分です。
アニメーションと RTL の対応が必要か
対象ブラウザが superellipse() を補間するか、また reduced-motion を尊重するかを確認します。物理的な左上をインライン開始位置と見なすのではなく、多言語レイアウトには論理プロパティ（logical longhands）を優先します。
30秒で答える要約
「border-radius をベースラインとして設定し、corner-shape を @supports 内に階層化します。このプロパティはコンテンツのレイアウトではなく既存の半径の描画を変更します。対向する角が重なる場合ブラウザは半径を制約するため、極端なサイズでテストします。フォーカスリング、ヒットエリア、オーバーフローを個別に検証し、アニメーションには機能と reduced-motion のフォールバックを提供します。」
ステップごとの解決策
ステップ 1: デグラデーション可能なベースラインの確立
まずベーススタイルを記述し、新しいプロパティがなくてもカードがボーダー、背景、シャドウ、角丸を保持するようにします。その上で機能クエリの中に拡張を追加します。
.card {
border-radius: 24px;
background: var(--surface);
box-shadow: 0 8px 24px rgb(0 0 0 / 18%);
}
@supports (corner-shape: scoop) {
.card {
corner-shape: scoop notch;
}
}未対応のブラウザは未知の宣言を無視し、ベースラインを維持します。コントラスト、読みやすいテキスト、重要な指示などをエンハンスメント層だけに配置しないでください。
ステップ 2: 値のマッピングと前提条件の説明
1 つの値は 4 つすべての角に適用されます。2 つの値は対角線のペアを形成します。3 つの値は 3 つ目を右下に割り当てます。4 つの値は時計回りに左上、右上、右下、左下をマッピングします。corner-shape は border-radius に依存するため、半径が 0 の場合は形状が生成されません。
superellipse() の数値は曲率を制御し、正と負の方向によって凸形状と凹形状を生成します。面接では、構文名はデザインツールのラベルから推測するのではなく、対象ブラウザでレンダリングされた出力に対して確認する必要があると言及してください。
ステップ 3: 重なりと描画境界の処理
対向する角の半径と形状が重なる場合、ブラウザは幾何学的な衝突を避けるために半径を制約します。テキスト、背景、ボーダー、シャドウの一貫性が保たれるよう、幅の狭いカード、極端なパーセンテージ半径、密度の高いコンテンツでテストします。
背景、ボーダー、アウトライン、ボックスシャドウ、オーバーフロー、バックドロップフィルターは通常、角の形状に追従します。コンテンツは依然としてボックスモデルに従います。画像やインタラクション領域でクリッピングが真に必要な場合は、個別の clip-path、マスク、またはセマンティックなヒットレイヤーを使用します。
ステップ 4: インタラクションとアクセシビリティのテスト
フォーカスリングは常に視認可能でなければならず、キーボード順序、フォーカス状態、ポインター領域はサポート環境とフォールバック環境の間で一致する必要があります。リンクであるカードの場合、完全に矩形のヒットエリアの方がピクセル単位で正確な輪郭よりも使いやすいことがよくあります。このトレードオフを視覚テストに記録します。
ステップ 5: アニメーションと論理方向の考慮
キーワードは同等のスーパーエリプス値を介して補間される場合がありますが、実装のサポート状況を確認してください。ホバー、フォーカス、状態変化に明示的な持続時間を設定し、prefers-reduced-motion: reduce ではそれらを無効化または短縮します。RTL で意図した形状が反転しないよう、多言語コンポーネントでは論理プロパティを使用します。
ステップ 6: 互換性マトリクスの構築
サポートのある Chromium、部分サポートまたは未サポートのブラウザ、狭小幅、長文テキスト、画像、シャドウ、キーボードフォーカス、タッチヒットテスト、視覚効果の削減をカバーします。エンハンスメント状態とフォールバック状態の両方をキャプチャし、宣言が適用されているか、レイアウトが変化していないか、イベントターゲットの一貫性が保たれているかを記録します。
模範的な高水準の回答
私は border-radius をプロダクトのベースラインとし、corner-shape を @supports 経由で階層化します。古いブラウザでも実用的なカードが得られ、サポート環境では新しい形状によって見た目が向上します。半径が 0 でないことを検証し、1〜4 個の値のマッピングを説明し、重なり制約のために狭いカードや極端な半径でテストします。
角の形状をコンテンツのクリッピングとして扱うことはしません。背景、ボーダー、シャドウは通常形状に追従しますが、コンテンツのレイアウトとポインターのヒットテストには個別の検証が必要であり、フォーカスリングは可視状態を維持する必要があります。アニメーションには reduced-motion の分岐を用意し、RTL には論理プロパティを使用し、互換性マトリクスでは単一のモダンブラウザのスクリーンショットに依存せず、視覚、レイアウト、キーボード、タッチの動作を比較検証します。
よくある間違い
- 症状 →
border-radiusなしでcorner-shapeを宣言する → 失敗の原因 → 有効な半径がないため形状が生成されない → 修正方法 → まず角丸のベースラインを提供する。 - 症状 →
corner-shapeを画像のクリッピングとして使用する → 失敗の原因 → コンテンツは依然として元のボックスに従う → 修正方法 → クリッピングが必要な場合は overflow、clip-path、またはマスクを使用する。 - 症状 → 可視の角によってヒットエリアが縮小されると仮定する → 失敗の原因 → イベントは元のボックスをターゲットにし続ける可能性がある → 修正方法 → キーボード、タッチ、イベントターゲットを個別にテストする。
- 症状 → 1 つの幅でのみテストする → 失敗の原因 → 狭いコンテナでは対向する半径が制約される場合がある → 修正方法 → 極端なサイズや長文テキストを含める。
- 症状 → 未対応ブラウザで空白のカードを表示する → 失敗の原因 → エンハンスメントが必須のスタイリングとして扱われていた → 修正方法 → 安定したベースラインの上に機能クエリを使用する。
フォローアップの質問と回答
フォローアップ 1: border-radius がパーセンテージを使用するとどうなりますか？
パーセンテージを推測で固定ピクセルに変換するのではなく、対象ブラウザの計算結果を検証します。いくつかのアスペクト比をキャプチャして、重なりやシャドウの連続性を確認します。ブランド形状を安定させる必要がある場合は、ベースのフォールバックを維持しながら、エンハンスメント層で制御された半径を使用します。
フォローアップ 2: フォーカスリングを形状に追従させるにはどうすればよいですか？
まず視認性とコントラストを確保し、その上で outline や擬似要素で形状を合わせることを検討します。ある手法でリングがクリップされてしまう場合は、キーボードフィードバックを犠牲にするのではなく、矩形のリングを維持します。
フォローアップ 3: corner-shape と border-shape の両方が宣言されている場合はどうなりますか？
W3C と MDN の仕様では、border-shape は border-radius を無効化しますが、corner-shape は border-radius に依存します。これらを代替の幾何学的パスとして扱い、それらが重ね合わされると仮定するのではなく、使用しないパスに明確なフォールバックを提供します。
フォローアップ 4: このプロパティを避けるべきケースはどのような場合ですか？
ブラウザのカバレッジが不十分な場合、形状が必要なクリッピングに悪影響を及ぼす場合、またはチームが視覚的フォールバックを維持できない場合は使用を避けます。アクセシビリティとパフォーマンスの目標がすでに満たされている場合は、安定した border-radius、SVG、または擬似要素の方が適した選択肢となることがあります。