CSS近期新增了許多酷炫特性，例如自定義屬性和新函數(shù)。這些特性雖然能簡化我們的工作，但也可能與Sass等預(yù)處理器產(chǎn)生有趣的交互問題。

本文將探討我遇到的問題、解決方法，以及我為何至今仍認為Sass必不可少。

遇到的錯誤

如果您使用過新的min()和max()函數(shù)，在處理不同單位時可能會遇到類似這樣的錯誤消息：“不兼容的單位：vh和em”。

這是因為Sass擁有自己的min()函數(shù)，并忽略CSS的min()函數(shù)。此外，Sass無法使用兩個單位之間沒有固定關(guān)系的值進行任何計算。

例如，cm和in單位之間存在固定關(guān)系，因此Sass可以計算出min(20in, 50cm)的結(jié)果，并且在代碼中使用時不會報錯。

其他單位也是如此。例如，角度單位之間都存在固定關(guān)系：1turn、1rad或1grad始終計算為相同的deg值。同樣，1s始終為1000ms，1kHz始終為1000Hz，1dppx始終為96dpi，1in始終為96px。這就是為什么Sass可以在它們之間進行轉(zhuǎn)換，并將它們混合在計算和函數(shù)（例如它自己的min()函數(shù)）中。

但是，當(dāng)這些單位之間沒有固定關(guān)系時（例如前面em和vh單位的例子），就會出現(xiàn)問題。

這不僅僅是不同的單位。嘗試在min()內(nèi)部使用calc()也會導(dǎo)致錯誤。如果我嘗試類似calc(20em 7px)這樣的代碼，則會收到“calc(20em 7px)對于min不是一個數(shù)字”的錯誤。

當(dāng)我們想要在CSS過濾器（例如invert()）中使用CSS變量或數(shù)學(xué)CSS函數(shù)（例如calc()、min()或max()）的結(jié)果時，還會出現(xiàn)另一個問題。

在這種情況下，我們會收到“`$color: 'var(--p, 0.85)' 不是invert的有效顏色”的提示。

grayscale()也會出現(xiàn)同樣的問題：“$color: 'calc(.2 var(--d, .3))' 不是grayscale的有效顏色”。

opacity()也會導(dǎo)致同樣的問題：“$color: 'var(--p, 0.8)' 不是opacity的有效顏色”。

然而，其他過濾器函數(shù)——包括sepia()、blur()、drop-shadow()、brightness()、contrast()和hue-rotate()——都可以與CSS變量正常工作！

事實證明，發(fā)生的情況與min()和max()問題類似。Sass沒有內(nèi)置的sepia()、blur()、drop-shadow()、brightness()、contrast()、hue-rotate()函數(shù)，但它確實有自己的grayscale()、invert()和opacity()函數(shù)，并且它們的第一個參數(shù)是$color值。由于它找不到該參數(shù)，因此會拋出錯誤。

出于同樣的原因，當(dāng)我們嘗試使用列出至少兩個hsl()或hsla()值的CSS變量時，也會遇到麻煩。

另一方面，color: hsl(9, var(--sl, 95%, 65%))是完全有效的CSS，并且在沒有Sass的情況下也能正常工作。

rgb()和rgba()函數(shù)也會發(fā)生完全相同的情況。

此外，如果我們導(dǎo)入Compass并嘗試在linear-gradient()或radial-gradient()內(nèi)部使用CSS變量，即使在conic-gradient()內(nèi)部使用變量也能正常工作（如果瀏覽器支持的話），我們也會收到另一個錯誤。

這是因為Compass帶有linear-gradient()和radial-gradient()函數(shù)，但從未添加過conic-gradient()函數(shù)。

所有這些情況下的問題都源于Sass或Compass具有同名函數(shù)，并假設(shè)這些是我們打算在代碼中使用的函數(shù)。

糟糕！

解決方法

這里的訣竅是記住Sass區(qū)分大小寫，但CSS不區(qū)分大小寫。

這意味著我們可以編寫Min(20em, 50vh)，Sass不會將其識別為它自己的min()函數(shù)。不會拋出錯誤，它仍然是有效的CSS，并且按預(yù)期工作。類似地，編寫HSL()/HSLA()/RGB()/RGBA()或Invert()可以避免我們前面遇到的問題。

至于漸變，我通常更喜歡linear-Gradient()和radial-Gradient()，因為它更接近SVG版本，但在其中使用至少一個大寫字母也能正常工作。

為什么？

幾乎每次我發(fā)布任何與Sass相關(guān)的推文時，都會有人告誡我，現(xiàn)在有了CSS變量，就不應(yīng)該再使用Sass了。我想解決這個問題，并解釋我為什么不同意。

首先，雖然我發(fā)現(xiàn)CSS變量非常有用，并且在過去三年中幾乎將它們用于所有方面，但需要注意的是，它們會帶來性能成本，并且使用當(dāng)前的DevTools追蹤在calc()計算迷宮中出現(xiàn)錯誤的地方可能會很痛苦。我盡量避免過度使用它們，以免陷入使用它們的缺點超過好處的境地。

一般來說，如果它像一個常量一樣工作，不會逐元素或逐狀態(tài)變化（在這種情況下，自定義屬性絕對是最佳選擇），或者減少編譯后的CSS數(shù)量（解決由前綴創(chuàng)建的重復(fù)問題），那么我將使用Sass變量。

其次，變量一直是我使用Sass的原因中很小的一部分。當(dāng)我在2012年末開始使用Sass時，它主要用于循環(huán)，這是我們目前在CSS中仍然沒有的功能。雖然我已經(jīng)將部分循環(huán)轉(zhuǎn)移到HTML預(yù)處理器（因為它減少了生成的代碼，并且避免了以后必須同時修改HTML和CSS），但我仍然在很多情況下使用Sass循環(huán)，例如生成值列表、漸變函數(shù)內(nèi)的停止列表、多邊形函數(shù)內(nèi)的點列表、變換列表等等。

(以下內(nèi)容與原文一致，略去重復(fù)部分，避免冗余)

以上是當(dāng)Sass和New CSS功能相撞時的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！