- 原文地址:On the Growing Popularity of Atomic CSS
- 原文做者:OLLIE WILLIAMS
- 譯文出自:掘金翻譯計劃
- 本文永久連接:github.com/xitu/gold-m…
- 譯者:Cherry
- 校對者:Tina92、ClarenceC
即便你自認爲是 CSS 方面的專家,也極可能在某一大型項目中,處理一個錯綜複雜而且愈來愈龐大的樣式表,它們中一些樣式表看起來就像一張相互繼承而且混亂纏繞的網。css
級聯的做用很是強大。微小的改變可能會引發很大的改變,這就致使了很難知道下一秒會發生什麼。重構、更改和移除 CSS 都是高危動做,由於很難知道這個 CSS 在哪裏被引用。前端
你何時能夠作到改變 CSS 不引發沒必要要的改動? 答案是不管在何種狀況下,你都不多有這種想法。android
在我有限的經驗中,其中的一種狀況是,在大型團隊的大型代碼庫中,給人的感受是 CSS 太大了以致於團隊的成員開始對 CSS 很敏感而且對 CSS 感到懼怕,可是實際上只是讓你增長 CSS。ios
由此產生一個工具,它能作的事情遠遠少於 CSS,可是在某種程度上(在你學會以後),沒有人在對其感到懼怕,我認爲這很是棒。git
我不在須要去考慮如何組織個人 CSS。我也不須要考慮如何給個人組件起名,也不須要考慮將一個組件和另外一個組件徹底分離,應該將其放在哪裏,最重要的,當有新的需求是怎麼進行重構。github
原子 CSS 提供了一套直接、明顯而且簡單的方法論。類是不可變的,你不能夠改變類名。這使得s使用 CSS 是可預見的和可靠的,由於類老是作徹底相同的事情。在 HTML 文件中添加或者移除一個有做用域範圍的公用類是明確的,它讓你確信你不會破壞其餘任何東西。這能夠減小認知負荷和精神負擔。後端
給組件命名是出了的困難。想出一個既有意義又足夠通用的類名費時又費力。緩存
計算機科學中只有兩個難題:緩存失效和命名問題。bash
– Phil Karltonapp
提出適當的抽象是困難的。相比之下,命名工具類就簡單直接一些。
/* 工具類命名 */
.relative {
position: relative;
}
.mt10 {
margin-top: 10px;
}
.pb10 {
padding-bottom: 10px;
}
複製代碼
原子的類從名字就能夠知道它們的功能。意圖和效果顯而易見。而包含無數類名的 HTML 會顯得很亂,HTML 比一個龐大而且錯綜複雜的樣式要容易一些。
在一個先後端混合的團隊中,可能參與開發的後臺人員對 CSS 知識有限,不多有人將樣式表搞亂。
工具類 很是適合處理小的樣式差別。雖然設計系統和模式庫如今可能風靡一時,可是你要意識到將會有不斷的新需求和變化。全部組件的可重用性每每不是體如今設計模擬。雖然實現和設計稿一致是最好的,可是一個大型網站繁多的上下環境必定會有不少的不可避免的不一樣。
Medium 的開發團隊已經不使用 BEM 了,在 他們的博文中 有提到。
若是咱們但願組件經過簡單的方式和另外一個組件只有細微的差異,該怎麼去作呢?若是你使用的 BEM 的命名方式,修飾符類極可能會不起做用。無數的修飾符每每只有一個效果。咱們以邊距(margin
)爲例。不一樣組件的邊框大部分都不相同,讓全部組件的邊框保持一致也不太可能。這個距離不只取決於組件,還取決於組件在頁面中的位置和它相對於其餘元素的相對位置。大部分的設計都包含類似可是不徹底相同的 UI 元素,使用傳統的 CSS 很難處理。
這是質疑原子 CSS 的人常常會問到的問題。長期以來你們都認爲行內樣式不利於實踐,自 Web 時代初期就不多有人使用了。**那些批評者將原子 CSS 與行內樣式等同也是有道理的,由於行內元素和原子 CSS 有相同的弊端。**舉個例子,若是咱們想要將全部的 .block
類中的 color
改變爲 navy
會怎樣?若是這樣作:
.black {
color: navy;
}
複製代碼
很明顯,這是不對的。
如今的編輯器很複雜。使用查找和替換將全部的 .black
類換成一個新的 .navy
類十分的簡單,可是倒是很危險的。問題是,你只是想將 某些 .block
類變爲 .naby
類。
在傳統的 CSS 方法中,調整組件的樣式和在一個 CSS 文件中更新一個類的一個值同樣簡單。使用原子 CSS,這就變成了一項單調乏味的任務,它經過搜索每一塊 HTML 來更新所述組件的每個實例。然而全部的高級編輯器都是這樣。即便你將標記分離爲可重用的模板,這仍然是一個主要缺點。也許這種手動操做對於這種簡單的方法是值得的。用不一樣的類更新 HTML 文件可能很乏味,但並不困難。(雖然有一些時候我在手動更新時遺漏了相關組件的某些實例,暫時引入了風格不一致)。若是改變了設計,你可能須要從 HTML 中手動編輯類。
雖然原子 CSS 和內聯樣式同樣有很大的缺陷,可是這不是一種退後。工具類以各類方式優於內聯樣式。
原子類能夠建立抽象類,內聯樣式不行。
<p style="font-family: helvetica; color: rgb(20, 20, 20)">
Inline styles suck.
</p>
<p class="helvetica rgb202020">
Badly written CSS isn't very different. </p> <p class="sans-serif color-dark"> Utility classes allow for abstraction. </p> 複製代碼
當改變設計的時候,上面例子的前兩個須要手動的修改和替換。第三個例子能夠只調整一處樣式表。
CSS 社區已經建立了不少用於行內樣式的無用的工具例如:Sass, Less, PostCSS, Autoprefixer 等。
與其寫出冗餘的行內樣式,倒不如像原子 CSS 同樣寫出簡潔的聲明縮寫。相比之下少打了一些字符:mt0
和 margin-top: 0
,flex
和 display: flex
,等等。
這是一個有爭議的話題。若是一個類或者行內樣式僅僅只作一件事情,那麼你是否但願它只作一件事情,不少人提倡使用 !importent
來保證不被其餘的除了 !important
的樣式重寫,這也就意味着這個樣式確定會被應用。可是,一個類自己是足夠具體的,能夠覆蓋其餘的基本類。和行內樣式相比,原子類特異性較低是一件好事。它容許更多的通用性。均可以使用 JavaScript 來改變樣式。若是是行內樣式的話就比較困難。
行內樣式不支持媒體查詢、僞選擇器、@supports
和 CSS 動畫。也許你有一個單獨的懸停效果你想要應用在不一樣的元素而不是一個組件。
.circle {
border-radius: 50%;
}
.hover-radius0:hover {
border-radius: 0;
}
複製代碼
簡單的可重用媒體查詢規則也能夠轉換成實用的工具類,其經常使用的類名前綴表示小型、中型和大型的屏幕尺寸。下面有一個 flexbox 類的實例,只能對中型和大型屏幕尺寸有效:
@media (min-width: 600px) {
.md-flex {
display: flex;
}
}
複製代碼
這在內聯樣式中是不可能的。
你是否是想要一個可重用的有僞內容的圖標或標籤?
.with-icon::after {
content: 'some icon goes here!';
}
複製代碼
行內樣式能夠作任何事情。這過於自由以致於很容易致使顯示效果混亂和不一致。經過每個預約類,原子 CSS 能夠保證必定程度的風格一致。而不是雜亂的顏色值和不肯定的顏色值,工具類提供了一個預約義設置選項。開發者從有限的設置中選擇單一功能的工具類,這種約束既能夠消除日益增長的樣式問題,保持視覺的一致性。
咱們來看一個 box-shadow
的例子。一個行內樣式能夠隨意使用偏移量、範圍、顏色、透明度和模糊半徑。
<div style="box-shadow: 2px 2px 2px rgba(10, 10, 250, .4)">stuff</div>
複製代碼
使用原子方法,CSS 做者能夠定義首選樣式,而後簡單應用,不可能出現風格不一致。
<div class="box-shadow">stuff</div>
複製代碼
毫無疑問,像 Tachyons 這樣的原子類框架愈來愈受歡迎。然而,CSS 方法並非互斥的。不少狀況下,工具類並非最好的選擇:
原子類能夠和其餘樣式方法共存。咱們應該將設置一些基礎類和穩健的全局樣式。若是你繼續複製工具類的類似字符串,這些樣式極可能被抽象爲一個類。你能夠在組件類中將其合併,可是你只能在知道它們不會被重用時才能夠這樣。
以組件爲先的方法去寫 CSS 意味着你建立一個組件事物即便他們不會再被重用。這種過早的抽象就是使樣式表變得冗餘和複雜的緣由。
單位越小,它的可重用性就越強。
看一下 Bootstrap 的最新版本,如今提供了一整套的工具類,仍然包括其傳統的組件。將來,愈來愈多的流行框架採用這種混合方法。
掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。