組織和管理 CSS

時間 2020-12-09

標籤 css html 前端 webpack git 程序員 github web 瀏覽器 sass 欄目 CSS 简体版

原文原文鏈接

在項目開發的過程當中，基於有限的時間內保質保量的完成開發任務無疑是一場挑戰。在這場挑戰中咱們不但要快速處理本身的問題，還須要與別人協同合做，以免二者之間的衝突。css

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

BEM 命名約定

BEM 是一種至關知名的命名約定，BEM 的意思就是塊（block）、元素（element）、修飾符（modifier）,是由 Yandex 團隊提出的一種前端命名方法論。這種巧妙的命名方法讓你的CSS類對其餘開發者來講更加透明並且更有意義。BEM 命名約定更加嚴格，並且包含更多的信息，它用於一個團隊開發一個耗時的大項目。前端

如咱們在書寫夥伴卡片組件代碼風格以下:webpack

.partner-card {
}

.partner-card__name {
}

.partner-card__content {
}

.partner-card__content {
}

.partner-card__content--md {
}

根據上述代碼，咱們很容易看出當前開發的意圖，同時也很難遇到代碼重複的問題。固然，咱們能夠利用 Less、Sass、Stylus 這些 css 處理器輔助開發，這裏再也不贅述。git

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

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

同時，使用 BEM 而不是 CSS 後代選擇器進行項目也會有必定性能優點(能夠忽略不計)，這是由於瀏覽器解析 css 時是逆向解析，以前對 css 解析有必定誤區，因爲書寫是從前日後，因此認爲解析也必定是從前日後，可是大部分狀況下，css 解析都是從後往前。web

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

Atomic CSS

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

代碼風格以下所示:

/** 背景色 顏色 內邊距 */
<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',
        }
      }
    }
  }

若是未來某一天我的須要從頭編寫本身的組件庫，我必定會使用它。相信該庫會給我帶來更好的開發體驗。

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 變量的利弊以及新奇玩法。

工程實踐

實際開發每每不止須要考慮某一方面，只考慮本身手上要作的東西，須要更高維度查看項目乃至整個開發體系。

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

針對於項目團隊，任何同樣事務能生存下來，都有其本身的優點，固然萬物有得就必有失。這是相互的，至於咱們前端人員，或者一個團隊如何取捨，仍是須要從自已或團隊力量出發，有利用之，無利就不用了。我認爲我最近看的一篇博客《程序員修煉之道》中的一段廢稿能夠表述正交性問題，事實上，不管式團隊仍是一段代碼，正交性越差就越難以治理。

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