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

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

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

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

來(lái)看個(gè)具體例子。假設(shè)你想給列表項(xiàng)的標(biāo)記符加點(diǎn)花樣：

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

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

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

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

怎么解決？作者提了三個(gè)可能的方案。第一個(gè)是擴(kuò)展and運(yùn)算符，讓開(kāi)發(fā)者能組合檢測(cè)：

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

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

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

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

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

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

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

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