在關於微互動的文章中，我提過 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——以及這兩個機制之間的分別大到甚麼程度，混用它們是通往不可訪問介面最簡單的一條路。
「讚好」按鈕立即作出反應，心心圖示填滿，數字隨即增加——而伺服器根本還沒有回應。這不只是微互動那篇文章講過的速度錯覺，而是更進一步的事情：介面展示了一個尚未存在的狀態，並且假定它馬上就會成真。本文探討如何安全地實作這種模式——包括假設落空時要如何老實地收回這個謊言，以及為甚麼手寫 setState 加 catch，是 useOptimistic 提供的方案的劣質版本。
工具類 .mt-4 輸給了 .card .card__header .card__title 這條規則，儘管照道理它是後加上去的，應該要贏。這不是巧合——這正是 specificity 按照它原本的設計在運作。@layer 帶來了一條全新的判定優先次序的軸線，它在 specificity 之前起作用，而不是跟它一起運作——而且當中有一個陷阱違反直覺到連網上部分文件都會寫錯。
「use server」看起來就像是呼叫 API route 的 fetch 的語法糖——正因如此，大部分實作都把它當成普通的函式呼叫來對待。這是一個會帶來具體後果的誤解：每一個標記為「use server」的函式，都會變成網絡上一個公開的端點，而建基於這個機制的表單，甚至在 JavaScript 尚未加載完成之前就已經可以運作。本文探討這個指令背後實際發生的事情，以及那些單看文件未必一眼就能看出的陷阱。
表單欄位要在內部 input 無效時變成紅色。聽起來很簡單——只是 CSS 在過去 25 年裡，從來沒辦法讓元素查詢自己內部發生的事，只能反過來做。本文探討 :has() 如何逆轉這個方向、它跟一般組合器有何不同，以及這種新能力在哪些地方真的會犧牲效能。
同一張商品卡片，放在網格裡好端端的，放進狹窄的側邊欄卻整個散開——即使 media query 早已細心調校過。問題不在你的程式碼，而在 media query 問錯了問題：它問的是螢幕有多寬，而不是這個組件實際分配到多少空間。本文探討 container queries 如何把這個問題放回它本該提出的位置，以及當元素變成「查詢容器」時，底層究竟發生了甚麼事。
正確的 HTML 只是起點。本文深入講解可訪問性樹的實際運作方式、ARIA 為何往往弊多於利，並與你一起實作一個真正可用的手風琴組件、一個即時通知區域，以及 Next.js 的焦點處理。
你有沒有想過，為什麼在某些網店將商品加入購物車會感到興奮，而在其他網店卻顯得平淡？關鍵可能在於微互動。這些細微的動畫看似微不足道，但實際上對用戶體驗的影響比你想像的更大。
CSS Houdini 唔係單一技術，而係一堆成熟程度參差不齊嘅規範集合。睇吓邊部分今日真係可以用喺production、@property 同 paint worklet 究竟點運作，以及點解其餘部分至今仍然只係實驗性質。
