談談BEM規范（含代碼）

css規范之BEM規范

前言

引用一句經典名言在編程的世界里其中一件最難的事情就是命名，不管是設計到編程語言還是標記語言都會有命名的需求。今天聊的就是關於css的命名規范的發展過程以及演變。

命名的發展變化過程

• 非組件化項目css命名原則
  • 復用性 全局性
  • 以jquery為代表的時代，我們項目都是獨立的html文件，此時為了讓我們的項目更好的維護，在寫樣式的時候，通常我們會將一些通用的樣式單獨提取到一個css文件，每個頁面使用的時候可以引入使用，比如reset.css,common.css。
  • 每一塊功能塊的樣式都是獨立的，之間無法復用，可以復用的樣式全部提取到全局樣式。
• 組件化項目命名原則
  • BEM規范
  • 以vue和react為代表的時代，我們項目都是組件化的，組件內的樣式都是獨立的作用域scope來限制，組件之間是可以相互引入使用的，一個組件可以拆分成多個小組件，此時樣式命名規范就需要使用BEM規范，從而達到組件樣式的獨立性。

BEM的規范

• BEM規范是css命名規范，主要適用的范圍是組件化開發的模式。
• 規范介紹（B__E--M）
  • B 代表block,也就是塊，每一個塊都是一個獨立的功能，塊之間可以相互嵌套。
    • 塊的命名可以由多個單詞組成，每個單詞之間以-鏈接
    • 塊的作用只是起到一個隔離的作用，一般不會在塊里面實現具體組件的樣式，對於塊修飾樣式比如尺寸，位置可以通過修飾符設置
    • 塊與修飾符之間通過--鏈接
  • E 代表element,也就是元素，元素是依賴於塊存在，不能獨立存在，必須嵌套在塊內部。
    • 元素的命名可以由多個單詞組成，每個單詞之間以-鏈接
    • 元素的樣式必須依賴塊存在，元素是塊的具體實現,塊與元素之間通過__鏈接
    • 元素里面可以定義每個元素自身的樣式，對於元素修飾樣式比如尺寸，狀態可以通過修飾符設置
    • 元素與修飾符之間通過--鏈接
  • M 代表modifier, 也就是修飾符，修飾符一般是對於元素或者塊的狀態和外觀進行修飾。
    • 修飾符的命名可以由多個單詞組成，每個單詞之間以-鏈接
    • 修飾符可以修飾塊和元素的狀態、行為、尺寸等
• 代碼演示
  • 評分組件 源碼地址

      <div class="qf-rate">
          <span class="qf-rate__item qf-rate__item--active">
          </span>
          <span class="qf-rate__item">
          </span>
          <span class="qf-rate__item">
          </span>
          <span class="qf-rate__item">
          </span>
          <span class="qf-rate__item">
          </span>
      </div>
  

      .qf-rate{
          width: 300px;
          height: 40px;
          display: flex;
          justify-content: center;
          align-items: center;
      }
      .qf-rate__item{
          width: 48px;
          height: 48px;
          cursor: pointer;
          background: url('./img/star.png');
      }
      .qf-rate__item--active{
          background: url('./img/star_active.png');
      }
  

• BEM不推薦寫法
  1. 不推薦采用標簽或者id作為選擇器，全部采用類名作為選擇器
     • id因為權重的問題，而且針對於spa的項目會出現id的重復情況
     • 標簽選擇器當我們需要修改組件解構的時候，同時還需要維護組件樣式
  2. 不推薦使用並列選擇器，使用修飾符來實現
  3. 不推薦使用偽類選擇器，使用修飾符來實現
     • 此處一般通過js控制狀態，添加修飾類
  4. 不推薦使用全局的css樣式比如rest.css common.css
     • 但是針對於一些格式化的樣式還是可以使用，一切目的都是為了方便維護

總結

BEM規范只是前端組件化發展過程中的規范，都是為了組件化服務，並不是唯一的規范，是否采用這個規范目的是為了團隊協作和更好的維護迭代，不是為了規范而規范。