網誌

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

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

工具類 .mt-4 輸給了 .card .card__header .card__title 這條規則，儘管照道理它是後加上去的，應該要贏。這不是巧合——這正是 specificity 按照它原本的設計在運作。@layer 帶來了一條全新的判定優先次序的軸線，它在 specificity 之前起作用，而不是跟它一起運作——而且當中有一個陷阱違反直覺到連網上部分文件都會寫錯。

表單欄位要在內部 input 無效時變成紅色。聽起來很簡單——只是 CSS 在過去 25 年裡，從來沒辦法讓元素查詢自己內部發生的事，只能反過來做。本文探討 :has() 如何逆轉這個方向、它跟一般組合器有何不同，以及這種新能力在哪些地方真的會犧牲效能。

同一張商品卡片，放在網格裡好端端的，放進狹窄的側邊欄卻整個散開——即使 media query 早已細心調校過。問題不在你的程式碼，而在 media query 問錯了問題：它問的是螢幕有多寬，而不是這個組件實際分配到多少空間。本文探討 container queries 如何把這個問題放回它本該提出的位置，以及當元素變成「查詢容器」時，底層究竟發生了甚麼事。

CSS Houdini 唔係單一技術，而係一堆成熟程度參差不齊嘅規範集合。睇吓邊部分今日真係可以用喺production、@property 同 paint worklet 究竟點運作，以及點解其餘部分至今仍然只係實驗性質。