/* GRID-BASED LAYOUT */
body {
  display: grid;
  min-height: 100vh;
  grid-template-columns: 200px 1fr 150px;
  grid-template-rows: min-content 1fr min-content;
}
header {
  grid-row: 1;
  grid-column: 1 / 4;
}
nav {
  grid-row: 2;
  grid-column: 1 / 2;
  padding: 0 10px;
}
main {
  grid-row: 2;
  grid-column: 2 / 3;
  padding: 0 20px;
}
aside {
  grid-row: 2;
  grid-column: 3 / 4;
  padding: 0 10px;
}
footer {
  grid-row: 3;
  grid-column: 1 / 4;
}

雖然結果看起來和基于flexbox的布局一樣，但是CSS在很大程度上得到了改進，它清晰地表達出了期望的布局方式。行和列的大小和形狀在body選擇器中定義，每一項item直接通過他們所在行和列的位置定義。

grid-column 這個屬性你可能覺得不太好理解，它定義了列的起點和終點。這個地方讓你覺得困惑的可能是明明有3列，卻為什么定義的范圍是1到4，通過下面的圖片你就能理解了：

Click here to see a live example

第一列是從1到2，第二列是從2到3，第三列從3到4，所以頭部的grid-column是從1到4占據整個頁面，導航的grid-column是從1到2占據第一列等等

一旦你習慣了grid語法，你會覺得它是一種非常理想的CSS布局方式。唯一缺點就是瀏覽器支持，幸運的是過去一年中瀏覽器的支持又得到了進一步的提高。作為專為CSS設計的第一款真正的布局工具很難描繪它的重要性，從某種意義上來說，由于現有的工具需要太多的hack和變通方式去實現，因此web設計者過去對于布局的創意上一直很保守，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(Ruby)，這門語言主要是讓Sass編譯成正常的CSS，同時你需要安裝Sass gem，之后你就可以通過命令行把你的.sass文件轉成.css文件了，我們先看一個使用命令行的例子：

sass --watch index.sass index.css

這個命令定期把index.sass中的Sass代碼轉為CSS寫入到index.css文件中（--watch參數設定后會實時監聽.sass文件改動并執行編譯，非常方便）

這個過程被稱為構建步驟。這在2006年的時候是非常大的一個障礙，如果你對Ruby這樣的編程語言熟悉的話，這個過程非常簡單。但是當時很多前端開發者只用HTML和CSS，他們不需要類似這樣的工具。因此，為了使用CSS預編譯的功能而讓一個人學習整個生態系統是很大的一個要求了。

2009年的時候，Less CSS預編譯器發布。它也是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;
}

語法上幾乎是相同的（變量的定義使用@替代了$），但是Less和CSS一樣帶有大括號和分號，沒有Sass例子的代碼看起來漂亮。然而，和CSS相近的特性反而讓開發者更容易接受它，在2012年，Less使用了JavaScript（Node.js）重寫了替換了Ruby，性能上比Ruby編譯更快了，并且很多在工作中使用了Node.js的人更容易上手了。

把這段代碼轉化為標準的CSS，你需要安裝Node.js 和 Less，執行的命令行如下：

lessc index.less index.css

這個命令把index.less文件中的Lessz代碼轉化為標準的CSS代碼寫入到index.css文件中，注意lessc命令不能監聽文件的變化（和sass不一樣），這意味著你需要安裝其他自動監聽和編譯的組件來實現該功能，增加了流程的復雜性。同樣，對于程序員來說使用命令行的方式并不難，但是對于其他只想使用CSS預編譯器的人來說還是個非常大的障礙。

汲取了Less的經驗，Sass開發者在2010年發布了一個新的語法叫SCSS（與Less類似的一個CSS超集），同時發布了LibSass，一個基于C++擴展的Ruby引擎，讓編譯更快并且適配于多種語言。
另外一個CSS預處理器是2010年發布的Stylus，使用Node.js編寫，和Sass或者Less相比更注重于清晰的語法。通常主流的CSS預編譯器就這三種（Sass，Less，Stylus），他們在功能方面非常相似，所以你不必擔心選擇哪一個會是錯誤的。

然而，有些人認為使用CSS預處理器開始變得越來越沒必要，因為瀏覽器最終會慢慢實現這些功能（像變量和計算）。此外，還有一種稱為CSS后處理器的方法，有可能會讓CSS預處理器過時（顯然這存在些爭議），我們在后面會詳細介紹下。

CSS后處理器使用JavaScript分析并轉換你的CSS為合法CSS，從這方面來看和CSS預處理器很相似，你可以認為是解決同一個問題的不同方式。關鍵的不同點是CSS預處理器使用特殊的語法來標記需要轉換的地方，而CSS后處理器可以解析轉換標準的CSS，并不需要任何特殊的語法。舉一個例子來說明下，我們用最初定義的header標簽樣式來看一下吧：

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

粗體部分的屬性成為廠商前綴，廠商前綴是瀏覽器廠商對CSS新功能的實驗和測試使用的，在正式實現前提供給開發者使用CSS新屬性的一種方式。-ms代表IE瀏覽器，-moz是火狐瀏覽器，-webkit是基于webkit內核的瀏覽器。

定義這些不同瀏覽器廠商的前綴屬性是非常煩人的，盡量使用生成工具自動添加廠商前綴。我們可以使用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語句都被替換成與之匹配的@mixin中的CSS。總體來說，這個解決方案也不差，但是你仍然要為每個需要廠商前綴的的CSS屬性定義一個mixin，這些mixin的定義將需要不斷的維護，比如當瀏覽器支持了某個CSS屬性后你就要在你的定義中移除掉該屬性。

比起寫mixin的方式，直接正常寫CSS然后由工具自動識別添加需要廠商前綴的屬性的方式顯然更優雅些。CSS后處理器就恰好能完成這樣的功能。比如，如果你使用 PostCSS 和 autoprefixer 插件，你就可以直接寫正常的CSS并不需要指定瀏覽器廠商前綴，剩下的工作全交給后置處理器去處理：

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

當你使用CSS后處理器運行這段代碼的時候hyphens: auto; 將被替換成包含所有瀏覽器廠商前綴的屬性，這意味著你可以正常寫CSS不用擔心各種瀏覽器兼容性問題，豈不是很棒！
除了PostCSS的autoprefixer插件還有很多有意思的插件，cssnext 插件可以讓你體驗下一些實驗性質的CSS新功能，CSS modules 可以自動改變class的名字避免名稱沖突，stylelint 能檢查出你CSS代碼中一些定義錯誤和不符合規范的寫法。這些工具在過去一兩年里開始流行起來，給開發者提供了從未有過的工程化流程。

然而，進程的發展總是有代價的，安裝和使用CSS后處理比CSS預處理器更復雜。你不僅要安裝、執行命令行，還需要安裝配置各個插件并且定義好各種復雜的規則（比如你的目標瀏覽器等）。很多開發者不再直接使用命令行運行PostCSS了，而是通過配置一些構建系統，像Grunt 、Gulp 、webpack，他們可以幫助你管理前端開發工作中需要的各種構建工具。

值得注意的是對于CSS后處理器存在些爭議，有人認為這個術語有些讓人迷惑（一種說法是建議都應該叫CSS預處理器，還有一種說法是應該都簡稱CSS處理器，等等），有人認為有了CSS后處理器完全可以不需要CSS預處理器，有人則主張兩者一起使用。不管怎么說，去了解下CSS后處理器的使用還是非常值得的。

CSS預處理器和CSS后處理器讓CSS開發體驗有了巨大的提升，但是單靠這些工具還不足以解決維護大型項目CSS代碼的問題。為了解決這個問題，人們編寫了一些關于如何寫CSS的指導方針，通常被稱為CSS規范。

在我們深入分析CSS規范前，首先要搞清楚是什么讓CSS隨著時間推移變得更加難維護，關鍵點是CSS是全局性的——你定義的每個樣式都會全局應用到頁面的每個部分，用一個命名約定來保證class名稱的唯一性或者有特殊的規則來決定指定樣式應用到指定元素。CSS規范提供了一個有組織性的方式來避免大量代碼時出現的這些問題，讓我們按照時間順序來看看主流的一些規范吧

OOCSS（面向對象的CSS）是在2009年首次提出的，它是圍繞兩個原則建立的規范。第一個原則是結構和樣式分離，這意味著定義結構（布局）的CSS不應該和定義樣式（顏色、字體等）的CSS混雜在一起，這樣我們就可以很簡單的為一個應用定義新的皮膚了；第二個原則是容器和內容分離，把元素看成是一個可重用的對象，關鍵核心點是一個對象不管用在頁面的任何位置都應該看起來是相同的。

OOCSS提供了成熟的指導規范，但是對于具體的執行規范并沒有明確指出。后來出現的SMACSS采用了它的核心概念，并且添加了更多的細節，使用起來更簡單了。

SMACSS（可擴展模塊化架構的CSS）是在2011年出現的一種設計模式，它將CSS分為5個不同的類別——基本規范、布局規范、模塊、狀態規范和樣式規范。SMACSS也有一些推薦的命名規則，對于布局規范使用l- 或者layout- 作為前綴；對于狀態規范，使用is-hidden 或者is-collapsed 作為前綴。

相比OOCSS，SMACSS有了更多細節上的規范，但是CSS規則該劃分為哪一類別的規范中，這是個需要仔細考慮的問題。后來出現的BEM對這一方面進行了改進，讓它更易使用了。

BEM (塊, 元素, 修飾符)是在2010年出現的規范，它的思想主要是圍繞把用戶界面切分成獨立的塊。塊是一個可重用的組件（舉個例子像表單搜索，可以這樣定義

BEM的規范很容易理解，對于新手來說命名規則上也很友好，缺點就是可能會導致class名字非常長，并且沒有遵循傳統的命名規范。后來出現的Atomic CSS又把這個非傳統方式帶到了一個新的高度。

Atomic CSS (也稱為 功能性CSS)是2014年出現的一個規范，它的思想是基于可視化的方法創建小而功能單一化的class。這種規范與OOCSS、SMACSS和BEM完全相反——它并不是把頁面上的元素看做是可重用的對象，Atomic CSS忽略掉了這些對象，每一個元素使用了可重用的單一功能的class樣式集合。因此像Search 就被替換成這樣的寫法了Search

如果你看到這個例子第一反應是被嚇的退縮了，沒關系你并不是唯一有這想法的人——很多人認為這種方式完全違背了CSS的最佳實踐，但是，關于這個有爭議的規范在不同場景下的應用也產出了一系列精彩的討論。這篇文章很清晰的分析了傳統的分離思想是CSS依賴于HTML創建（即使使用像BEM這類的規范），而Atomic的方式是HTML依賴于CSS創建，兩者都沒錯，但是仔細想想你會發現CSS和HTML徹底分離的想法是實現不了的。

其他的CSS設計模式，像CSS in JS其實也包含了CSS和HTML相互依賴的思想，這也成為了一個飽受爭議的設計規范之一。

CSS in JS 是2014年推出的一種設計模式，它的核心思想是把CSS直接寫到各自組件中，而不是多帶帶的樣式文件里。這種方式在React框架中引入的，最早是使用內聯樣式，后來又進化成了使用JavaScript生成CSS然后插入到頁面的style標簽中的方式。

CSS in JS再一次違背了CSS中關于分離的最佳實踐，主要原因是web隨著時間推移發生了很大的變化。最初web大部分都是靜態網站——這種情況下HTML內容和CSS表現分離是很有意義的，但現在大部分應用都是動態web構建——這種情況下可重用的組件更加有意義了。

CSS in JS設計的目標是定義邊界清晰包含自己HTML/CSS/JS的獨立組件，并且不受其他組件的影響。React是最早采用這種思想的框架，后續也影響到了其他框架像Angular、Ember和Vue.js。需要注意的是CSS in JS的模式相對來說比較新的，開發人員正在不斷的嘗試開發web應用組件時的一些CSS最佳實踐。

五花八門的設計模式很容易讓你不知所措，最重要的記住一點——沒有銀彈。

簡而言之這就是現代CSS。我們介紹了CSS基本排版樣式，浮動布局、flexbox和grid布局，了解了CSS預處理器為CSS提供的新語法，比如變量和mixins，還了解了CSS后處理器的轉換功能，像給CSS添加廠商前綴，并且使用CSS的一些設計模式克服了全局CSS的一些問題。在這里我們沒有時間去挖掘更多CSS其他功能了，CSS覆蓋面太廣了——任何一個說它簡單的人可能只是對它一知半解吧！

現代CSS的多變和快速發展多少讓人感到有些沮喪，但是重要的是要記住web隨著時間推移進化的歷史背景，并且有一群聰明的人愿意為CSS向更好的方向的進化去創建一些工具和指導規范。作為一名開發者是一件幸運的事情，我希望這篇文章提供的信息能作為一個路線圖幫助你更好的暢行在CSS路程中！