網(wǎng)頁開發(fā)者都熟悉@supports這個CSS規(guī)則——它用來檢測瀏覽器是否支持某個CSS特性，支持就應(yīng)用樣式，不支持就跳過。聽起來很靠譜，對吧？但實際情況是，這個"檢測器"本身就有bug，而且是個讓人頭疼的設(shè)計缺陷。

按照CSS規(guī)范，@supports只能寫在最外層，或者嵌套在另一個條件規(guī)則（比如@media）里面。但現(xiàn)實中，瀏覽器對下面這種寫法照單全收：

.my-class {@supports (property: value) {}

這種嵌套寫法理論上是無效的，但Chrome、Safari、Firefox全都認(rèn)了。問題就出在這里——瀏覽器怎么處理這種"非法"嵌套，直接決定了你的代碼會不會出岔子。

來看個具體例子。假設(shè)你想給列表項的標(biāo)記符加點花樣：

li::marker {@supports (content: " - ") {content: " - ";color: red;}

這段代碼想表達(dá)的是：如果瀏覽器支持content: " - "，就把列表標(biāo)記改成紅色的" - "。Chrome和Firefox確實這么渲染了。但Safari呢？它顯示的是一個紅色圓點。

詭異之處在于，Safari明明不支持::marker偽元素里的content屬性，@supports的檢測結(jié)果卻返回了"支持"。開發(fā)者看到的是嵌套結(jié)構(gòu)，瀏覽器執(zhí)行的卻是另一套邏輯——它把@supports提到了最外層，檢測的是"這個聲明語法上是否有效"，而不是"在這個具體場景下是否真的能用"。

說白了，@supports檢查的是語法合法性，不是上下文兼容性。它不會問"這個屬性在這個選擇器里能不能用"，只會問"這個屬性我認(rèn)不認(rèn)識"。

怎么解決？作者提了三個可能的方案。第一個是擴展and運算符，讓開發(fā)者能組合檢測：

@supports selector(::marker) and (content: " - ")

第二個是引入新運算符（比如xand），強制要求兩個條件在特定上下文中同時成立。第三個更直接——新增一個rule()函數(shù)，直接檢測整條規(guī)則的有效性：

@supports rule(::marker { content: " - " })

這些方案的核心思路都一樣：讓@supports能判斷"這條聲明在這個地方是否真的有效"，而不是只判斷"這條聲明我認(rèn)不認(rèn)識"。

當(dāng)然，還有個簡單粗暴的備選方案：瀏覽器直接禁止嵌套@supports，檢測到就報錯。但這會打破大量現(xiàn)有代碼，代價太高。

作者也提到了現(xiàn)有的變通方案——容器查詢（container queries）和樣式查詢（style queries）。不過這兩者目前支持度有限，而且只能檢測自定義屬性，沒法直接檢測普通CSS聲明。能用，但不夠徹底。

這個案例暴露了一個深層問題：CSS的"漸進(jìn)增強"工具本身就不夠漸進(jìn)。開發(fā)者以為自己在寫防御性代碼，實際上寫的可能是"在部分瀏覽器里靜默失效"的代碼。更麻煩的是，這種失效不會拋錯，不會警告，只是樣式不對——等你發(fā)現(xiàn)的時候，可能已經(jīng)上線很久了。

對于天天跟瀏覽器兼容性打交道的前端工程師來說，這不算新聞。但每次遇到這種"規(guī)范說一套、瀏覽器做一套、檢測工具還幫倒忙"的情況，還是會讓人想嘆氣。畢竟，連"檢測支持不支持"這個功能都不完全支持，這本身就很CSS。