CSS书写规范与理论

       前端体系的变化可谓是日新月异，短短一年时间，从理论、框架、构建工具、甚至开发语言都发生非常大的变化。 随着新项目就即将启动，我抽时间回顾了一下以往项目的前端架构，零零散散产生了许多想法，尽量一一记录下来，为新的框架搭建做点准备。

       首先来聊聊CSS的的各种规范与理论。回顾过去的代码，首先让我头痛不已的就是那些不知所谓的类名，以及数不清的难以维护的CSS/LESS代码。

       我曾经对自己和前端小组的成员提出过要求，强制使用BEM方法来书写CSS，但是在使用的过程中，也出现了总总问题。     

       它带来的好处是显而易见的，每个元素都被清晰描述出来，这也非常符合自文档化代码的要求。但同时也引发很多诸多问题

• 单纯使用BEM方法，并没有很好的去构建CSS的结构
• 复杂的业务逻辑带来复杂的页面，导致复杂的类名。
• 组件的嵌套以及组件状态使得一个元素上应用大量的类，这让第二个问题更加严重

      在这个过程中，我们开始松懈了要求，这使得我们的CSS代码又回到了混乱无序的原始时代。

      因此我想我必须去重新去探究CSS的各种规范与理论。

一、OOCSS（面向对象的CSS）

　　OOCSS有两个主要的原则：分离结构和外观，以及分离容器和内容。

　　与任何基于对象的编程方法一样，OOCSS 的目的是鼓励代码复用，使得最终的样式可以更快地和更有效地添加和维护。

 　  OOCSS风格的CSS也可以描述为两点：增加class、不使用继承选择符。

<div class="box simple">
    <div class="box-content active">
           <p class="box-title">OOCSS</p>
    </div> 
</div>    

　　上面这段代码是一段遵循OOCSS模式的代码

• • 其中"normal"作为外观和结构分离，例如"simple"可用使用的是直角，我将"simple"换成"complex"，就"box"变成了圆角。
  • 分离容器和内容，是指不再将元素位置作为样式的限定词，比如"box-title"就是文本的样式，无论这个类作用在哪里，都会是相同的样式呈现。

       OOCSS的缺点

• • OOCSS适合真正的大型网站开发，因为大型网站用到的可重用性组件特别的多，如果运用在小型项目中可能见不到什么成效。所以用不用OOCSS应该根据你的项目来决定。
  • 如果没用巧妙的使用，创建组件可能对于你来说是一堆没用的东西，成为一烂摊子，给你的维护带来意想不到的杯具，说不定还是个维护的噩梦。
  • 最好给每一个组件备写一份说明文档，有助于调用与维护

二、SMACSS（模块化架构可扩展CSS）

　　我们把上面的代码用SMACSS风格来再次写出来

<div class="box box-simple">
    <div class="box-content is-active">
           <p class="box-title">SMACSS</p>
    </div> 
</div>   

　　尽管SMACSS和OOCSS有许多相似之处。但不同点是它把样式系统划分为五个具体类别。

• • 基础
    • 如果不添加CSS类名，标记会以什么外观呈现
    • 例如浏览器的 reset 可以写在这里
      

      html {}
      input[type=text] {}
      a:hover {}

  • 布局
    • 把页面分成一些区域，是指整个网站的「大架构」的外观，而非button 这种小元件的 class
    • 通常只有一个选择器，一个 id、或一个 class。

      .header {}
      .articles {}
      .sidebar {}

  • 模块
    • 设计中的模块化、可复用单元，就如同代码中的"box-title"一样，无论这个类作用在哪里，都会是相同的样式呈现
  • 状态
    • 描述在特定状态或情况下的显示方式，代码中的“is-active”就是一个状态类
  • 主题
    • 一个可选的视觉外观层，可以让你更换不同主题　　　
    • 主题可以修改前面4个类别的样式，且应和前面4个类别分离开来（便于切换，也就是“换肤”）。
    • SMACSS的Theme Rules不要求使用单独的class命名，也就是说，你可以在布局中定义.header{ }，然后在主题中也用.header { }来定义需要修改的部分来覆盖前面的样式

三、BEM（块元素修饰符）

　　同样的，使用BEM风格，重写上面的代码

<div class="box box--simple">
    <div class="box__content box__content--active">
           <p class="box__title">BEM</p>
    </div> 
</div> 

　　BEM是一个CSS命名的命名规则，它不涉及如何书写CSS的结构，只是建议每个元素都添加带有如下内容的CSS类名

• • 块名

　　　　　　所属组件的名称

• • 元素

                     元素在块里面的名称

• • 修饰符

　　　　　　任何与块或元素相关联的修饰符

　　BEM模式下，看起来很累赘、很冗余，但是每一个CSS类名都很好的描述了它的作用，在结合LESS或者SASS使用时，会使它的书写复杂程度降低。

四、规则文档　

　　我们往往会非常注重大的方法，而忘记细节，而一份完善的规则文档会时刻提醒我们按照要求书写代码

　　一份好的规则文档，应该遵循以下规范：

• • 中包含不可变的规则，而不是笼统的说明
  • 总是把规则提炼成最简单的表达
  • 总是首先说明规则 是什么，再说明“如果不这样，那么会如何”
  • 每个规则必须包含以下词中的一个——总是、永远不要、只有、每一个、不要、要　　

五、综合方案

　　就像开篇所说一样，单纯的使用BEM并没有很好的解决我们在项目中所遇到能再的问题，反而产生了新的问题。

　　但这并不是BEM的责任，CSS作为前端架构的重要一环，我们必须要针对项目来选择一个合适的解决方案，而不是因为业界流行就去使用它。

　　往往单一的理论是无法支撑起真实需求的，因此，我们必须结合现有的方法来制定一个新的方案。比如继续坚持BEM风格以及js hook，同时引入SMACSS、OOCSS亦或者其他方法，并且用一份严格的规则文档来规范整个项目的细节。

如果喜欢我的文章，可以扫描二维码关注我的微信公众号

争取每天都分享一点我自己的开发和练习体验～
?