網誌

儀表板上的六張卡片，六個旋轉器，它們不會一起出現——它們一個接一個出現，像骨牌一樣，因為每張卡片只在上面的完成後才開始載入。這就是瀑布，總等待時間不是最慢的請求，而是所有請求的總和。use() 和 Suspense 斷開了這個鏈條——但有趣的是其中的機制：暫停的元件實際上拋出了什麼，以及錯誤順序到達的 HTML 如何最終落在正確的位置。

JavaScript 視差效果總是看起來有點不對——有點脫節，好像圖層在頁面後面半幀漂浮。這不是草率的程式碼。這是因為捲動事件在瀏覽器已經繪製捲動之後才到達 JavaScript。瀏覽器曾經解決了這個問題——當它將粘性標頭變成 position: sticky 時。Scroll-driven animations 是同樣的手法，一次應用於所有捲動綁定的效果。

十年來，將縮圖動畫成英雄圖片只有一種技術：在前後測量元素，用 transform 偽造差異，然後播放。FLIP。每個動畫函式庫都這樣做，每個都在最糟糕的時候以主執行緒的 JavaScript 為代價。View Transitions API 將整個技巧轉移到瀏覽器——自 React 19.2 和 Next.js 16 起，整個合約只需要一個名為 name 的 prop。

在關於微互動的文章中，我提過 transform 和 opacity 是在合成器執行緒上做動畫，所以即使頁面很重，按鈕動畫理論上也不應該卡頓。這句話依然成立——但有一個那篇文章沒有提到的但書：如果主執行緒被一個長時間的 JS 工作阻塞，動畫可能根本沒有機會開始執行，因為連點擊事件的處理函式本身都還在排隊等候。INP 正是量度這個落差的指標——而 scheduler.yield() 是少數能真正把這個落差補上的方法之一。

一千則留言的清單渲染得很慢，於是你搬出 react-window——換來流暢的捲動，卻犧牲了 Ctrl+F、列印頁面，以及部分螢幕閱讀器導覽，因為視窗外的元素在 DOM 中已經不復存在。content-visibility 用另一種方式解決同一個問題：元素仍然留在 DOM 裡，瀏覽器只是暫時跳過為它們計算版面配置與繪製的昂貴工作，直到它們接近可視範圍為止——而且令人意外的是，當你在其中搜尋文字時，它還能暫時把它們顯露出來。

在無障礙設計那篇文章裡，一個用 display:none 隱藏、卻依然存在於可訪問性樹裡的 modal，正是從零開始用 div 手寫 modal 會出現的典型錯誤。真正該問的問題是：一開始為甚麼要從零開始做？本文探討原生 <dialog> 和 popover 屬性能免費送你甚麼——top layer、焦點陷阱、light dismiss——以及這兩個機制之間的分別大到甚麼程度，混用它們是通往不可訪問介面最簡單的一條路。