在專案開發的過程中，基於有限的時間內保質保量的完成開發任務無疑是一場挑戰。在這場挑戰中我們不但要快速處理自己的問題，還需要與別人協同合作，以避免兩者之間的衝突。

針對於大型專案的開發，css如何組織和管理才能讓我們用更少的時間寫出更強大的功能。這篇文章來表述一些我對css組織和管理的理解。當然，對於 ToC(面向個人) 應用，出於細節和動畫的把控。再加上這種網頁生命週期較短，往往復用性較差，但是針對於 ToB(面向企業) 應用，統一風格往往會贏得客戶的青睞。行列間距，主題樣式等都應該結合統一，而不是每個頁面不同設計。基於此，我們需要組織與管理我們的 css,而不僅僅只是是靠 css injs來為每個元件單獨設計。

BEM 命名約定

BEM 是一種相當知名的命名約定，BEM 的意思就是塊（block）、元素（element）、修飾符（modifier）,是由Yandex團隊提出的一種前端命名方法論。這種巧妙的命名方法讓你的CSS類對其他開發者來說更加透明而且更有意義。BEM 命名約定更加嚴格，而且包含更多的資訊，它用於一個團隊開發一個耗時的大專案。

如 我們在書寫夥伴卡片元件程式碼風格如下:

.partner-card {
}

.partner-card__name {
}

.partner-card__content {
}

.partner-card__content {
}

.partner-card__content--md {
}
 

根據上述程式碼，我們很容易看出當前開發的意圖，同時也很難遇到程式碼重複的問題。當然，我們可以利用Less、Sass、Stylus 這些 css 處理器輔助開發，這裡不再贅述。

計算科學中最難的兩件事之一就是命名，日常開發中如果沒有一些約定，就很容易發生命名衝突，BEM 恰恰解決了這一痛點,我們只需要外層樣式名是一個有意義且獨立唯一，就無需考慮太多。

與 BEM 相對應的還有 OOCSS SMACSS。而這兩種不是直接可見的命名約定，而是提供了一系列的目標規則。這裡不再詳細闡述，大家如果想要了解，可以去看一看值得參考的css理論：OOCSS、SMACSS與BEM。當然了，真正的組織與管理必然也離不開這些目標規則。

同時，使用 BEM 而不是 CSS 後代選擇器進行專案也會有一定效能優勢(可以忽略不計)，這是因為瀏覽器解析 css 時是逆向解析，之前對 css 解析有一定誤區，由於書寫是從前往後，所以認為解析也一定是從前往後，但是大部分情況下，css 解析都是從後往前。

如果規則正向解析，例如「divdivp em」，我們首先就要檢查當前元素到html的整條路徑，找到最上層的 div，再往下找，如果遇到不匹配就必須回到最上層那個 div，往下再去匹配選擇器中的第一個 div，回溯若干次才能確定匹配與否，效率很低。逆向匹配則不同，如果當前的 DOM 元素是 div，而不是 selector 最後的 em 元素，那隻要一步就能排除。只有在匹配時，才會不斷向上找父節點進行驗證與過濾。無需回溯，效率較高。

Atomic CSS

ACSS表示的是原子化 CSS（Atomic CSS），是 Yahoo 提出來的一種獨特的 CSS 程式碼組織方式，應用在 Yahoo 首頁和其他產品中。ACSS 的獨特性在於它的理念與一般開發人員的理解有很大的不同，並挑戰了傳統意義上編寫 CSS 的最佳實踐，也就是關注點分離原則。ACSS 認為關注點分離原則會導致冗餘、繁瑣和難以維護的 CSS 程式碼。

程式碼風格如下所示:

/** 背景色 顏色 內邊距 */
<div class="Bgc(#0280ae.5) C(#fff) P(20px)">
    Lorem ipsum
</div>

<div>
   <div class="Bgc(#0280ae.5) H(90px) IbBox W(50%) foo_W(100%)"></div>
   <div class="Bgc(#0280ae) H(90px) IbBox W(50%) foo_W(100%)"></div>
</div>

<hr>

<div class="foo">
   <div class="Bgc(#0280ae.5) H(90px) IbBox W(50%) foo_W(100%)"></div>
   <div class="Bgc(#0280ae) H(90px) IbBox W(50%) foo_W(100%)"></div>
</div>

計算科學中最難的兩件事之一就是命名，而 Atomic CSS 直接捨棄了命名。一個類只做一件事。yahoo 利用這種方案減輕了很多程式碼。

很多人會抗拒 Atomic CSS，原因在於需要記住一堆的類名，感覺會看起來比較亂。但是事實上，你不需要考慮它的結構等因素，而是它需要什麼樣式就直接提供好了。把腦力運動變成機械的體力運動。

原子 CSS 的優勢的確有很多：

• 變化是可以預見的由於單一職責原則（一個類==一種樣式），很容易預測刪除或新增一個類會做什麼。
• CSS是精益的，幾乎沒有冗餘，也沒有自重（所有樣式都與專案相關）。
• 範圍有限,不依賴於後代/上下文選擇器-樣式是在“特異性層” 內部完成的。
• 初學者友好，原子 CSS 在設計好的情況下，甚至不需要編寫樣式表。 對於 css 不夠擅長的開發人員更友好（這個也不一定是一件好事，css 學習是必需的）
• 越大型的系統，對當前設計越熟悉，對庫開發越熟練的開發人員，編寫程式碼的時間和程式碼量就會越少。

如果一件事情只有利好而沒有弊病那也是不可能的：

• 需要記住一堆沒有意義的原子類，對於不同的團隊，類名難以重用。
• 對於初學者有一定影響，可能只會記得原子類
• 沒有結合設計意圖，原子類太細。

tailwind

如果 ACSS 這個框架令人難以接受，那麼不久前拿到 200w 投資的tailwind框架則是更優秀的選擇。雖然該庫也是原子化 CSS，但是它更具可讀性。

<div class="md:flex bg-white rounded-lg p-6">
  <img class="h-16 w-16 md:h-24 md:w-24 rounded-full mx-auto md:mx-0 md:mr-6" src="avatar.jpg">
  <div class="text-center md:text-left">
    <h2 class="text-lg">Erin Lindford</h2>
    <div class="text-purple-500">Product Engineer</div>
    <div class="text-gray-600">erinlindford@example.com</div>
    <div class="text-gray-600">(555) 765-4321</div>
  </div>
</div>

如果你重度使用 Bootstrap，那麼我認為直接上手 tailwind 沒有什麼問題。 對比於 BootStrap，他做的更少，不會提供元件，僅僅提供樣式。

• 自適應前置，我們在使用其他 UI 庫書寫自適應前端網頁時，往往會攜帶 -md -xs 諸如此類的類。而 Tailwind 則以 md:text-left lg:bg-teal-500 開頭佈局響應式風格。在書寫時候，讓程式碼更加自然。
• 程式碼量可控，雖然 Tailwind CSS 的開發版本未壓縮為1680.1K，但是它可以輕易與webpack結合剔出沒有使用的 css。
• 結合設計意圖

  // tailwind 配置項
  module.exports = {
    theme: {
      screens: {
        sm: '640px',
        md: '768px',
        lg: '1024px',
        xl: '1280px',
      },
      fontFamily: {
        display: ['Gilroy', 'sans-serif'],
        body: ['Graphik', 'sans-serif'],
      },
      borderWidth: {
        default: '1px',
        '0': '0',
        '2': '2px',
        '4': '4px',
      },
      extend: {
        colors: {
          cyan: '#9cdbff',
        },
        spacing: {
          '96': '24rem',
          '128': '32rem',
        }
      }
    }
  }

如果將來某一天個人需要從頭編寫自己的元件庫，我一定會使用它。相信該庫會給我帶來更好的開發體驗。

http://www.ssnd.com.cn 化妝品OEM代加工

MVP.css

Mvp.css是一個簡約的html元素樣式表庫，雖然它不屬於 css 組織與管理，但當開發 ToC 專案時候，我們也可以把這種做法看作一種簡約的模式。

這個微型庫結合 css 變數進行專案開發。不過也許有人會認為他是一種前端反模式，因為他的樣式掛在在 元素之上。不過如果面對專案較小，且需要整齊的風格體驗，也可能是一個不錯的方案。

:root {
  --border-radius: 5px;
  --box-shadow: 2px 2px 10px;
  --color: #118bee;
  --color-accent: #118bee0b;
  --color-bg: #fff;
  /* 其他變數 */
}

/* Layout */
article aside {
  background: var(--color-secondary-accent);
  border-left: 4px solid var(--color-secondary);
  padding: 0.01rem 0.8rem;
}

body {
  background: var(--color-bg);
  color: var(--color-text);
  font-family: var(--font-family);
  line-height: var(--line-height);
  margin: 0;
  overflow-x: hidden;
  padding: 1rem 0;
}

關於 css 變數的一系列知識點，可以檢視我之前的部落格玩轉 CSS 變數。該文章詳解了 css 變數的利弊以及新奇玩法。

工程實踐

實際開發往往不止需要考慮某一方面，只考慮自己手上要做的東西，需要更高維度檢視專案乃至整個開發體系。

團隊合作永遠是統一高於一切

針對於專案團隊，任何一樣事務能生存下來，都有其自己的優勢，當然萬物有得就必有失。這是相互的，至於我們前端人員，或者一個團隊如何取捨，還是需要從自已或團隊力量出發，有利用之，無利就不用了。我認為我最近看的一篇部落格《程式設計師修煉之道》中的一段廢稿可以表述正交性問題，事實上，無論式團隊還是一段程式碼，正交性越差就越難以治理。

最後，在這裡介紹一些本文沒有介紹的工具。

• Design token 輔助庫theo來編寫多端變數。
• 去除未使用的 Css 樣式uncss
• 通過 url 提取關鍵 CSSminimalcss,提升初始渲染速度
• 高效能的 CSS-in-js庫Emotion