我對新的動畫 API 一向有點矛盾：demo 看得很開心，輪到正式專案又怕它只是增加干擾。Chrome 147 的區域 View Transitions 倒讓我比較有興趣，因為它不是叫整個網站飛來飛去，而是處理列表重排、卡片換位這種使用者真的需要看懂「東西去了哪裡」的小變化。
View Transitions 最早比較像整個頁面切換時使用的動畫。Chrome 147 加入 element-scoped 的做法後，可以把轉場限制在某個區域，不需要整頁都參與。
例如購物車裡調整商品順序、看板拖動卡片，或照片列表切換排列方式，都可以只讓那個元件內的元素平順移動。這比自己計算每個元素的位置簡單，也比較容易保留原本的頁面狀態。
動畫仍然應該是輔助，而不是讓使用者等它播完。也要記得尊重 prefers-reduced-motion，讓不適合大量動態效果的人可以減少動畫。
這項 API 有趣的地方是它保留了正常 DOM 更新方式。我們還是照原本流程改 class、排序陣列或切換狀態，瀏覽器負責補上前後畫面的過渡。比起為動畫另外維護一份位置狀態，程式會比較接近日常 UI 邏輯。
目前使用時仍要把沒有 View Transitions 的情況當成正常路徑。功能不支援時，DOM 應該照樣完成更新，只是少了動畫。這種 enhancement 很適合逐步導入，不需要為了舊瀏覽器準備另一整套互動。
我會先從「動畫能幫忙理解位置變化」的地方用，而不是每次 state change 都加。看板卡片換欄、篩選後項目重新排列很適合；按下儲存後讓整張表單飛走，可能只是在搶注意力。好的 transition 應該讓使用者更容易回答「剛才那個東西去哪了」。
測試也別只錄順利路徑。快速連點、資料回來前再次排序，以及 transition 中途 route change，才比較容易碰到狀態和動畫不同步的問題。