一文帶你快速瞭解現代的CSS

一文帶你快速瞭解現代的CSS

做者｜Peter Jang譯者｜覃雲相信你們已經熟悉通常的 CSS，如今咱們將從 CSS 預處理器開始介紹改善 CSS 語言自己工做體驗的構建工具。使用 CSS 預處理器獲取新語法

CSS 預處理器容許你使用不一樣的語言編寫樣式，將其轉換爲瀏覽器能夠理解的 CSS，這在瀏覽器實現新功能速度很是緩慢的時候是極其重要的。第一個主要的 CSS 預處理器是 2006 年發佈的 Sass，它具備新型的簡潔語法（縮進代替括號、沒有分號等），並增長了 CSS 中缺乏的高級功能，例如變量、輔助函數和計算。如下是使用帶變量的 Sass 的示例：

$dark-color: #4a4a4a $light-color: #f9f9f9 $side-color: #eee body   color: $dark-color header, footer   background-color: $dark-color   color: $light-color main   background: $light-color nav, aside   background: $side-color

請注意，如何使用 $ 符號定義可重用變量，並消除括號和分號，使語法更清晰簡潔。雖然 Sass 的語法簡潔是一件好事，但當時變量是革命性的功能特性，由於它們爲編寫簡潔且可維護的 CSS 開闢了新的可能性。

若是使用 Sass，你須要安裝 Ruby，這是用於將 Sass 代碼編譯爲常規 CSS 的編程語言。而後，你須要安裝 Sass gem，而後在命令行中運行將.sass 文件轉換爲.css 文件的命令，如下是一個示例：

sass --watch index.sass index.css

這個命令會將一個名爲 index.sass 常規 CSS 的文件中的 Sass 代碼轉換成一個名爲 index.css（在任什麼時候候，--watch會提示它保存更改的內容，這很方便）。

這個過程稱爲構建步驟，這在 2006 年但是一個重大的難題。若是你能熟練使用 Ruby 這樣的編程語言，那麼這個過程將會很是簡單。但當時許多前端開發者只使用不需任何此類工具的 HTML 和 CSS，所以，對開發者來講，學習整個生態系統以得到由 CSS 預處理器提供的功能是一個很高的要求。

2009 年，CSS 的 Less 預處理器發佈，它也是用 Ruby 編寫的，而且提供了與 Sass 相似的功能。主要的區別在於語法，其語法的設計儘量接近 CSS，這意味着任何 CSS 代碼都是有效的 Less 代碼，下面是使用 Less 語法編寫的示例：

@dark-color: #4a4a4a; @light-color: #f9f9f9; @side-color: #eee; body {   color: @dark-color; } header, footer {   background-color: @dark-color;   color: @light-color; } main {   background: @light-color; } nav, aside {   background: @side-color; }

它們幾乎是相同的（@前綴代替 $ 變量），只是不像 Sass 示例那樣漂亮，但它與 CSS 具備相同的大括號和分號，這種與 CSS 類似的特色使得開發人員更容易接受它。2012 年，JavaScript（特別是 Node.js）代替 Ruby 用於重寫和編譯 Less。這讓 Less 比那些使用 Ruby 的同類速度要快，而且這讓 Less 在那些已在工做流程中使用 Node.js 的開發人員中更受歡迎。

要將此代碼轉換爲常規 CSS，首先你須要安裝 Node.js，而後安裝 Less，最後運行以下命令：

lessc index.less index.css

這個命令會將名爲 index.less 文件中的 Less 代碼轉換爲 index.css 中的常規 CSS。請注意，Lessc命令並無提供查看文件以及進行文件更改的方式（這與 Sass 命令不一樣），這意味着你須要安裝不一樣的工具來自動監視和編譯 .less 文件，這爲進程增長了複雜性。不過，這對於習慣使用命令行工具的程序員來講，並非一件難事兒，但對於其餘只想使用 CSS 預處理器的人而言，這是一個難以跨越的障礙。

伴隨着 Less 在乎識層面上得到很大的承認，Sass 開發人員在 2010 年增長了一種名爲 SCSS 的新語法（能夠認定爲 CSS 的高配版，與 Less 相似）。他們還發布了 LibSass，這是 Ruby Sass 引擎的 C / C ++ 端口，它的做用是使其加速，而且可以支持多種語言。

另外一種替代 CSS 預處理器的是 Stylus，它於 2010 年推出，採用 Node.js 編寫，與 Sass 或 Less 相比，它更注重語法的清潔度。通常說來，談論最多的三種 CSS 預處理器是 Sass、Less 和 Stylus。它們在提供的功能方面都很是類似，因此不管你選擇哪一個，都不算選錯。

然而，有些人認爲 CSS 預處理器變得不那麼重要了，由於瀏覽器最終會實現它們的一些特性（例如變量和計算）。此外，還有一種稱爲 CSS 後處理的方法，可能會使 CSS 預處理器過期（顯然有爭議），咱們將在後面介紹這些方法。

使用 CSS 後處理器實現轉換功能

CSS 後處理器使用 JavaScript 來分析並將 CSS 轉換爲有效的 CSS。從這個意義上講，它與 CSS 預處理器很是類似，你能夠將其視爲解決相同問題的不一樣方法。關鍵的區別在於，雖然 CSS 預處理器使用特殊語法來標識須要轉換的內容，但在無特殊語法下，CSS 後處理器能夠解析常規 CSS 並對其進行轉換。下面這個例子來最好地說明了這一點。讓咱們來看看用上面最初定義 CSS 的一部分去設計標題標籤的樣式：

h1, h2, h3, h4, h5, h6 {   -ms-hyphens: auto;   -moz-hyphens: auto;   -webkit-hyphens: auto;   hyphens: auto; }

粗體的部分稱爲瀏覽器前綴，在瀏覽器試驗性地添加或測試新的 CSS 功能時會被用到，它爲開發人員使用 CSS 的新特性提供了一種方法。-ms前綴是指 Microsoft Internet Explorer，-moz 前綴是指 Mozilla Firefox，-webkit 前綴是指使用 Webkit 渲染引擎的瀏覽器（如 Google Chrome、Safari 和 Opera 的新版本）。

請注意，添加全部這些不一樣的瀏覽器前綴以便使用 CSS 的新特性是很是麻煩的。若是有自動添加瀏覽器前綴的工具的話，將會很省心，咱們能夠用 CSS 預處理器來解決這個問題。例如，你能夠用 SCSS 作這樣的事情：

@mixin hyphens($value) {   -ms-hyphens: $value;   -moz-hyphens: $value;   -webkit-hyphens: $value;   hyphens: $value; } h1, h2, h3, h4, h5, h6 {   @include hyphens(auto); }

在這裏，咱們使用了 Sass 的 mixin 功能，這個功能容許你在定義了一個 CSS 塊後，能在其餘地方重用。當這個文件被編譯成常規的 CSS 時，任何 @include 語句都將被替換成與之匹配的 CSS @mixin 語句。總的來講，這並不是是一個糟糕的解決方案，可是你須要爲任何須要瀏覽器前綴的 CSS 屬性在首次定義 mixin 時負責。這些 mixin 定義須要維護，由於在瀏覽器更新其 CSS 兼容性以後，你可能但願刪除一些你再也不須要的特定瀏覽器前綴。

不是使用 mixin，而是隻寫常規的 CSS，並使用一個工具自動識別須要前綴的 CSS，並相應地添加前綴，在這方面，一個 CSS 後處理器就可以作到。例如，若是你將 PostCSS 與 autoprefixer 插件一塊兒使用，則能夠在沒有任何瀏覽器前綴的狀況下編寫常規的 CSS，並讓後處理器完成剩下的工做：

h1, h2, h3, h4, h5, h6 {   hyphens: auto; }

當你在此代碼上運行 CSS 後處理器時，結果會是hyphens: auto，行將被替換爲相應的瀏覽器前綴（正如 autoprefixer 插件中定義地那樣，並不須要你直接管理）。也就是說你能夠只寫常規 CSS 而沒必要擔憂任何兼容性或特殊語法，這是一件很是好的事。

除了用於 PostCSS 的 autoprefixer 外，還有一些插件可讓你作很酷的事情。cssnext 插件容許你使用 CSS 的試驗性功能，該 CSS 模塊插件能夠自動改變類來避免名稱衝突，stylelint 插件識別 CSS 中的錯誤和不合常規的行爲。這些工具在過去的一兩年內纔開始起步，爲開發人員展現了從未有過的工做流程！

然而，這一過程須要付出代價。與使用 CSS 預處理器相比，安裝和使用 PostCSS 之類的 CSS 後處理器更爲重要。你不只須要使用命令行來安裝和運行工具，還須要安裝和配置各個插件並定義一組更復雜的規則（例如，面向哪些瀏覽器等），而不是直接從命令行中運行 PostCSS，許多開發人員將其整合到可配置的構建系統中，如 Grunt、Gulp 或 webpack，這些可幫助你管理在前端工做流程中可能使用到的全部不一樣的構建工具。

注意：若是你之前從未使用過現代的前端構建系統，那麼學習全部的必要組件可能會讓你以爲是一件顛覆的事情。若是你想從頭開始，請查閱個人文章 Modern JavaScript Explained For Dinosaurs，它涵蓋了前端開發人員所需的全部 JavaScript 工具。

值得注意的是，CSS 後處理器的身上存在一些爭議，有人說它們應該統稱爲 CSS 預處理器，還有別的說法認爲它們應該簡單地稱爲 CSS 處理器等，也有一些人認爲 CSS 後處理器徹底不須要 CSS 預處理器，而有些人認爲它們應該一塊兒使用。不管怎樣，很顯然，若是你有興趣更深一步挖掘出 CSS 的潛能，那麼學會使用 CSS 後處理器將值得你去嘗試。

使用 CSS 的方法論進行維護

CSS 預處理器和 CSS 後處理器等工具爲改進 CSS 開發體驗邁出了重要的一步，但單靠這些工具還不足以解決大型 CSS 代碼庫的維護問題。爲了解決這個問題，人們開始記錄關於如何編寫 CSS 的不一樣的指導方針，一般稱爲 CSS 方法論。

在咱們深刻研究任何特定的 CSS 方法論以前，咱們要清楚這麼多年是什麼使得 CSS 的維護變得如此困難？關鍵的問題在於 CSS 的全局性 - 你定義的每種風格都會應用於頁面的每一個部分。想出一個詳細的命名規則來維護惟一的類名或者用特殊規則來決定哪一個樣式應用於給定的元素，這將變成你的工做。CSS 方法提供了一種有組織性的方式來編寫 CSS，以解決大型代碼庫的痛點，讓咱們以時間順序粗略地看一下那些流行的方法。

 OOCSS

OOCSS（Object Oriented CSS）是在 2009 年首次提出的，它遵循兩種原則。第一個原則是將結構和表現隔開，這意味着定義結構（如佈局）的 CSS 不該該與定義表現（如顏色、字體等）的 CSS 一塊兒混用，這使得應用程序更容易重構其表現。第二個原則是將容器和內容隔開，這意味着將元素視爲可重用的對象，並且無論對象在頁面的哪一個位置，看起來都應該是相同的。

OOCSS 提供了成熟的指導方針，但沒有具體的方案。後來的方法如 SMACSS 採用了 OOCSS 的核心概念並增長了更多細節，使其更容易入門。

 SMACSS

SMACSS（Scalable and Modular Architecture for CSS）是在 2011 年推出的，它主要圍繞 CSS 中 5 個屬性展開，包括基本規則、佈局規則、模塊、狀態規則和主題規則。SMACSS 也提供了一些命名規則，對於佈局規則，你能夠用l-或layout-做爲類名稱的前綴。對於狀態規則，你須要在描述狀態的類名加上前綴，好比is-hidden或is-collapsed。

與 OOCSS 相比，SMACSS 有更多的細節，但在決定哪些 CSS 規則應該進入哪一個類別時仍須要慎重考慮。後來像 BEM 這樣的方法避免了作決策的步驟，使其更容易被採用。

 BEM

BEM（Block、 Element、 Modifier）於 2010 年推出，它是將用戶界面劃分爲獨立 Block 的一種方法論。一個 Block 是一個可重複使用的部件（例如搜索表單，定義

）。Element 爲 Block 的一小部分，它不能獨立重複使用（如搜索表單內的 button，Search）。Modifier 是一個實體，定義爲外觀、狀態、Block 或 Element 中的行爲（例如禁用搜索表單裏的按鈕，定義爲Search）。

BEM 很容易理解，它具備特定的命名規則，新手在應用它時無需作出複雜的決策。它的缺點是類名很是冗長，而且不遵循傳統的規則來編寫語義類名。後來的方法如 Atomic CSS 會把這個非傳統的方法帶到了另外一個層面上！

 Atomic CSS

Atomic CSS（也稱功能型 CSS）是在 2014 年引入的一種方法，它的主要思想是基於視覺功能建立小而單一用途的類名。這種方法與 OOCSS、SMACSS 和 BEM 徹底相反，它 不是將頁面上的元素視爲可重用的對象，而是徹底忽略了這些對象，並使用可重用的單一實用工具類來對每一個元素的樣式進行設置。因此，你看到不是這樣的：<button>Search</button>，而是這樣的：<button class="f6 br3 ph3 pv2 white bg-purple hover-bg-light-purple">Search</button>。

若是你對這個例子的第一反應是懼怕而退縮，那麼你不是一我的，由於許多人認爲這種方法與現有的 CSS 最佳實踐方案徹底背離。然而，不一樣場景下最佳實踐方案的有效性引發了人們的質疑，在這個過程當中也引發了不錯的討論。這篇文章 作了很好的分析，重點闡述了傳統的關注點分離是如何建立依賴於 HTML 的 CSS（甚至是應當在何時使用 BEM 等方法），而 Atomic CSS 或功能型方法則是基於 CSS 建立的 HTML。二者都沒錯，但通過仔細觀察，你會發現 CSS 和 HTML 之間徹底的分離從未真正地實現過！

其餘的 CSS 方法，如 CSS in JS，實際上包含了 CSS 和 HTML 老是相互依賴的概念，是最具爭議性的方法之一。

 CSS in JS

CSS in JS 是 2014 年推出的一種方法，它的觀點是：不在單獨的樣式表中定義 CSS 樣式，而是直接在每一個組件中定義。它是做爲 React JavaScript 框架的一種方法而引入的（它採用了有爭議的方法，直接在 JavaScript 中爲組件定義 HTML 而不是在單獨的 HTML 文件中）。最開始的時候，它採用內聯樣式，但後來使用 JavaScript 來生成 CSS（使用基於組件的獨一無二的類名），並使用樣式標記將其插入到文檔中。

CSS in JS 再次徹底違背了現有 CSS 最佳實踐中的分離問題，這是由於咱們使用網絡的方式隨着時間的推移發生了巨大變化。最初網站主要由靜態網站組成，那時將 HTML 內容與 CSS 分離頗有意義。現在，Web 用於建立動態的 Web 應用程序，這時，經過可重用組件分離更有意義。

CSS in JS 的目標是可以用 HTML / CSS / JS 封裝的「硬邊界」定義組件，使得每一個組件中的 CSS 不會影響任何其餘組件。React 是最先被普遍採用的框架之一，它們爲這些組件提供了「硬邊界」的支持，隨後影響了其餘主流框架，如 Angular，Ember 和 Vue.js 等。須要注意的是， CSS in JS 是新型的一種方法，在這期間開發人員試圖在 Web 應用程序的組件時代爲 CSS 創建新的最佳實踐，並進行了大量的實驗。

咱們很容易被許多不一樣的 CSS 方法淹沒，但重要的是要記住，沒有一種徹底正確的方法—— 當你面對足夠複雜的 CSS 代碼庫時，你應該將它們視爲幾種不一樣工具做爲備用。通過深思熟慮，爲你的做品選擇一個最佳的工具，而且在這個過程當中進行的每一次試驗都將爲每位開發人員帶來長遠利益！

  結 論  

綜上所述，這就是現代的 CSS。咱們介紹了使用 CSS 進行基礎設計的排版屬性，將 CSS 用於使用浮點、flexbox 和基於網格的佈局，使用 CSS 預處理器以獲取新語法（如變量和 mixins），使用 CSS 後處理器實現轉換功能，例如添加瀏覽器前綴，並使用 CSS 的幾種方法論進行維護，克服 CSS 樣式的全局性。咱們沒有機會深刻了解 CSS 提供的許多其餘功能，例如高級選擇器、轉換器、動畫、形狀、動態變量等。

因爲現代的 CSS 老是在不斷地變化和快速發展，將其用在工做上不免讓人頭疼。但別忘了，隨着時間的推移，網絡也在不斷髮展，很高興有不少聰明的人願意加入這個行列，構建具體的工具和提出有效的方法來提高 CSS 的實踐能力。我但願這些信息能夠做爲路線圖，幫助你踏上旅程！

 原文連接

https://medium.com/actualize-network/modern-css-explained-for-dinosaurs-5226febe3525