CSS工作組決定開發(fā)內聯條件語句，這一消息在評論區(qū)引發(fā)熱議。一些開發(fā)者對此感到興奮，而另一些開發(fā)者則感到擔憂，他們擔心這會讓CSS的未來變得不確定。這是否會滑向一個地獄般的境地，充斥著濫用CSS的開發(fā)者，他們在本應是樣式語言的地方實現過多的邏輯？不會。即使一些人真的那樣做了，也沒有主流博客會發(fā)表那些假設的瘋子的胡言亂語，他們?yōu)榱俗约旱哪康脑贑SS中加入瘋狂的邏輯。因此，我們知道CSS的未來是安全的。

世界末日？早就結束了

本文的論點進一步證實，內聯條件語句可能並非文明終結的預兆：我認為我們現在可以使用樣式查詢來實現相同的功能，而樣式查詢正在獲得相當好的瀏覽器支持。

如果我是對的，Lea的提議更像是語法糖，有時會很方便，並允許更簡潔的標記。任何關於內聯條件語句會毀掉CSS的恐慌性言論，都相當於誇大其詞地將三元運算符添加到已經支持if語句的語言中。

事實上，Lea談到她提出的語法時說：“就像JS中的三元運算符一樣，對於只有一小部分值變化的情況，它也可能更符合人體工程學。”她還提到，CSS一直都是有條件的。並非CSS中條件語句是被禁止的，而是CSS並不總是擅長處理它。

我想要一個條件Oompa Loompa！

我也是。還有許多其他人，正如Lea精心整理的令人驚嘆的複雜技巧列表所證明的那樣，人們已經發(fā)現了使用當前CSS模擬內聯條件語句的方法。其中一些技巧複雜到我仍然不確定自己是否理解它們，但它們的名字確實很酷。 Lea總結道：“如果您知道任何其他技術，請告訴我，以便我可以添加它們?！?/p>

嗯……我肯定錯過了一些關於這些技巧解決的問題。我注意到Lea有博士學位，而我是一個白癡。所以我向上滾動並重新閱讀，但我無法停止思考：這些人是否正在努力避免在他們的部件周圍添加額外的div並使用樣式查詢？

如果人們想避免DOM中多餘的元素，這是公平的，但Lea的技巧列表顯示，替代方案非常複雜，因此值得嘗試一下使用包裝div的樣式查詢能帶我們走多遠。

有說服力的例子

Lea的例子圍繞著在提示框上設置一個“variant”屬性展開，並指出我們幾乎可以用樣式查詢實現她想要的東西，但這個假設的語法很遺憾是無效的：

<code>.callout { 
  @container (style(--variant: success)) {
    border-color: var(--color-success-30);
    background-color: var(--color-success-95);

    &::before {
      content: var(--icon-success);
      color: var(--color-success-05);
    }
  }
}</code>

她想根據--variant設置容器本身及其子元素的樣式。現在，在這個具體的例子中，我可以使用z-index來修改::after偽元素，以產生它是容器的錯覺。然後我可以設置它的邊框和背景。不幸的是，這個解決方案和我一樣脆弱，在這個其他的例子中，Lea想根據variant設置容器的flex-flow。在這種情況下，我的偽元素解決方案不夠好。

記住，Lea的提案被納入CSS規(guī)範，就像宇宙送給她的生日禮物一樣，所以試圖用我在Temu上買到的那些廉價假容器來代替她的禮物是不公平的。她應該得到一個真正的容器。

讓我們再試一次。

使用包裝器

Lea提案的評論中提到類型研磨，但稱其為“一種非常（我再說一次，非常）複雜但有效的”解決內聯條件語句旨在解決的問題的方法。這不太公平。類型研磨讓我花了一點時間才理解，但我認為它比其他技巧更容易理解，而且缺點更少。儘管如此，當你查看示例時，這種在生產環(huán)境中的代碼會讓人感到厭煩。因此，讓我們咬緊牙關，嘗試構建Lea的flexbox變體示例的替代版本。我的版本不使用類型研磨或任何技巧，而是使用“老式”（並非那麼老式）的樣式查詢以及包裝div，來解決我們無法使用樣式查詢來設置容器本身樣式的問題。

包裝器對比類型研磨

比較Lea的示例和我的版本的代碼，可以幫助我們理解複雜性的差異。

以下是CSS的兩個版本：

以下是標記的兩個版本：

因此，更簡單的CSS和稍微多一點的標記。也許我們找到了方向。

我喜歡樣式查詢的原因是，Lea的提案使用了style()函數，所以如果她的提案被瀏覽器採用，那麼將樣式查詢遷移到內聯條件語句並移除包裝器似乎是可行的。如果我不提到遷移這種代碼可能是AI的一個可行的用例，這篇文章就不是2025年的文章了。當我們獲得內聯條件語句時，也許AI就不會那麼糟糕了。

但我們有點跑題了。你有沒有嘗試過採用一些在“待辦事項”示例中看起來很優(yōu)雅的炫酷JavaScript框架？如果有的話，你會知道，在簡單的示例中看起來引人注目的解決方案，在真實的示例中可能會挑戰(zhàn)你的生存意志。因此，讓我們看看在更真實的示例中使用樣式查詢的效果如何。

尋求驗證

將我上面的示例與MDN關於HTML5驗證的示例和Seth Jeffery關於變形純CSS圖標的酷炫演示結合起來，然後將它們全部輸入“What If”機器以獲得下面的演示。

如果您使表單有效，則對提示框所做的所有更改都基於一個自定義屬性。此屬性從未直接用於提示框的CSS屬性值中，但它控制設置提示框的邊框顏色、圖標、背景顏色和內容的樣式查詢。我們在.callout-wrapper級別設置--variant屬性。我使用CSS設置它，如下所示：

<code>.callout { 
  @container (style(--variant: success)) {
    border-color: var(--color-success-30);
    background-color: var(--color-success-95);

    &::before {
      content: var(--icon-success);
      color: var(--color-success-05);
    }
  }
}</code>

但是，該變量可以由JavaScript或HTML中的內聯樣式設置，就像Lea的示例一樣。表單驗證只是我使演示更具交互性的方法，以顯示提示框可以根據--variant動態(tài)更改。

總結

我寫一篇文章來反對那些將CSS彎曲到我們意志的技巧，這與我的風格不符，而且我完全贊成“欺騙”語言來做我們想做的事情。但是，在獲得內聯條件語句的支持之前，使用包裝器和樣式查詢可能是最簡單的方法。如果我們想感覺更像生活在未來，我們可以將上述方法作為內聯條件語句的polyfill或使用Parcel插件或PostCSS插件之類的預處理器魔法的基礎——但對於這種妥協(xié)，我的扳機手指總是會渴望Delete鍵。 Lea承認，“如果你可以用樣式查詢做某事，那就盡情使用樣式查詢——它們幾乎肯定是一個更好的解決方案?！?/p>

通過本文中的實驗，我已經說服自己，即使在Lea的例子中，樣式查詢仍然是一個不錯的選擇——但我仍然期待內聯條件語句。與此同時，至少與其他已知的解決方法相比，樣式查詢更容易理解。具有諷刺意味的是，我同意那些質疑內聯條件語句需求的評論，不是因為它會毀掉CSS，而是因為我相信我們現在已經可以用現代CSS實現Lea的例子，而且不需要任何技巧。所以，我們可能不需要內聯條件語句，但它們可以讓我們編寫更易讀、更簡潔的代碼。如果您能想到一些使用樣式查詢而不是內聯條件語句會遇到復雜性障礙的例子，請在評論區(qū)告訴我。

以上是如果機器：將CSS的' IFFY”未來帶入當下的詳細內容。更多資訊請關注PHP中文網其他相關文章！