Skill 詳細
kf-g-css-tak-animations
Direct UI animation design, implementation, review, and accessibility guidance.
使用前に確認
自動レビューは関連性のみを確認し、安全性や推奨を保証しません。使用前に出典の説明を読んでください。
SKILL.md
これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。
--- name: kf-g-css-tak-animations description: UI animations necessity judgment, recommendations for motion design, implementation strategies, and performance/accessibility reviews. Targets include hover, active, focus, popover, tooltip, dropdown, dialog, tab, segmented control, card, button, toast, accordion, carousel, scroll-linked animation, View Transitions, and more. --- # Animations Skill 以下のようなタスクでこの Skill を使うこと。 - UI にアニメーションを追加する - モーションデザインの品質をレビューする - hover, popover, tooltip, dropdown, dialog, tab, segmented control, card, button, toast, accordion, scroll-linked animation, View Transitions などの動きを改善する - アニメーションを削除すべきか判断する - property, easing, duration, transform-origin などを選定する - `prefers-reduced-motion` を尊重すべきかどうかを判断する - `@starting-style`, `transition-behavior`, `interpolate-size` などの出現・退場アニメーション手法を選定する - `@keyframes` の命名規則・スコープ管理・API 的カスタムプロパティ設計を行う --- ## 基本原則 1. アニメーションは目的ではなく手段である 1. そのアニメーションが「機能的」か「装飾的」かを常に区別する 1. 最良のアニメーションは「アニメーション無し」である場合もある 1. UI の動きは速く、応答的に感じられるべきである。ユーザーが求めているのは「すぐ反応した」という知覚速度である 1. 高頻度で操作される UI では装飾的なアニメーションを避ける 1. イージングはアニメーションにおいて最重要である。同じ duration でもイージング次第で体感速度は大きく変わる 1. 視覚変化はトリガーとの因果関係が感じられるべきである 1. 複数の視覚変化を同期させたい場合、個別の `transition` では不十分なことがある。`@keyframes` animation、Web Animations API、あるいは CSS トランジションと `transition-behavior` の組み合わせなど、適切な手法を選ぶこと 1. アニメーションはパフォーマンスに大きく影響する 1. アクセシビリティのため、`prefers-reduced-motion` を尊重しているユーザーにどう見せるかを常に考える ## 必須の評価順序 ### Step 1: そのアニメーションは必要か？ 必ず次を確認する。 - この動きは何の問題を解決するのか - 状態、因果関係、フィードバックを明確にしているか - 機能的なのか、装飾的なのか - ユーザーはどれくらい頻繁にこれを見るのか - キーボード操作や高速操作の邪魔にならないか #### 判断基準 | 目的 | 判断 | 例 | | ---------------------------------- | ------------------ | ---------------------------------------------- | | 状態遷移の因果関係を示す | 必要 | アコーディオン開閉、タブ切替 | | ユーザーの注意を新出要素に誘導する | 必要 | toast 通知、バリデーションエラー | | 操作のフィードバックを返す | 必要 | ボタンの `:active`、チェックボックスのチェック | | 空間的連続性を保つ | 条件付き | ページ遷移の View Transitions、ドリルダウン | | ブランド個性の表現 | 低頻度 UI のみ許容 | LP のヒーロー、初回訪問のオンボーディング | | 単に見た目の華やかさ | 高頻度 UI では不要 | ダッシュボードのカードがスライドして現れるなど | 強い理由がない場合は、削除を提案すること。 ### Step 2: どの実装形が適切か？ #### Step 2A: イージング・タイミングの選定 **イージング** - `ease-in` 系や `linear` 系は物理的に不自然で機械的な印象を与えがちである。`linear` は一定速度を表現したい連続運動（marquee やプログレスバー）にのみ適用する。 - 出現・退場では `ease-out` 系を使用する - すでに画面上にあるものの移動では `ease-in-out` 系を使用する - CSS 標準のイージングキーワード（`ease`, `ease-in-out` など）はメリハリが弱い。プロジェクトにアニメーショントークンがある場合はそれを参照し、`quint` 系か `expo` 系のイージングを使用する - トークンが存在しない場合は以下を推奨する ```css /* ease-out 系（出現・退場向き） */ --ease--out-quint: cubic-bezier(0.22, 1, 0.36, 1); --ease--out-expo: cubic-bezier(0.16, 1, 0.3, 1); /* ease-in-out 系（移動向き） */ --ease--in-out-quint: cubic-bezier(0.86, 0, 0.07, 1); --ease--in-out-expo: cubic-bezier(0.87, 0, 0.13, 1); ``` - 全てのプロパティに同一の `transition-duration` と `transition-timing-function` を適用するのは雑である。プロパティごとにカーブを選び分けること **タイミング** - 例外: dialog, drawer, sheet など大型 UI の遷移は `300ms〜500ms` を許容する - 日常的に何十回も触る UI では、1 回あたり `100ms` の差でも体感負荷が大きくなる #### Step 2B: transform-origin と空間的整合性 - `transform-origin` は常にトリガーとの位置関係を考慮して設定する - Popover はトリガー要素を起点として拡大・縮小させる。デフォルトの `center` は多くの場合に不適切である - CSS Anchor Positioning を使用している場合は、Popover の配置方向に応じて `transform-origin` を動的に切り替えることを検討する - `scale: 0` からのスケールインは物理的に不自然である。「そこにあったものが少し離れた位置から立ち上がる」ほうが自然であるため、要素のサイズに応じた起点値を選ぶこと | 要素種別 | スケールイン起点 | | --------------------- | ---------------- | | tooltip, popover | `0.95〜0.98` | | dropdown menu | `0.92〜0.96` | | dialog, drawer, sheet | `0.85〜0.92` | #### Step 2C: インタラクション種別ごとの指針 **ホバー** - ホバーの視覚変化は `150ms〜200ms` を目安とする - タッチデバイスでは hover が存在しないため、`@media (any-hover: hover)` で切り分けることを検討する - カレントリンクなど `href` が存在しないアンカーリンクでホバーが起こるのは避ける。必ず `:any-link:hover` のように定義すること - 有効ではないボタンでホバーが起こるのは避ける。必ず `:enabled:hover` のように定義すること **active（押下フィードバック）** - ボタン等の押下時GitHub で全文を読む （外部ページ）