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

       首先来聊聊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亦或者其他方法,并且用一份严格的规则文档来规范整个项目的细节。

 

 


 

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

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

 

内容来源于网络如有侵权请私信删除
你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!