CSS Modularization

August 19, 2012  ☕️ 2 min

我今天要草率的把我的一些关于css的草率的想法和实践草率的写出来,所以就叫猜。

我之前一直苦于我的css代码基本就是样式堆砌的丑陋代码。即使是分了reset, common, page也无济于事。

less可以一定程度上避免代码的堆砌,因为它可以样式规则的嵌套。 但是样式规则嵌套不能过深,否则会导致选择器性能问题。

增加逻辑层次是一个合理放置代码的解决办法,比如模块。当然模块的初衷显然不是为了解决css代码混乱的, 模块化的好处除了增加代码可读性外,更重要的是它具有可重用的能力。其实也算是代码规范的功劳了, 其实代码规范好的话,可以解决很多问题。我甚至觉得架构这个东西,就应该是用代码规范来解决的。。。

基于less的css规范,我自己的实践原则是这样的,很简单:

纵向上是

模块1(名字空间) {  /* 比如 .speak-dialog */
    类1;         /* 比如 h1,h2,h3 {} */
    类2;         /* 比如 .hd {} */
}

模块从全局空间开始,按照html树的层级,下面可能就到aside,main这级,然后再细化到内部的模块。到不能再细分模块的时候就以传统的css写法写。 这种模块+类在html结构上应该象是这样:

CSS Module

横向上是

[{layout, style}, {layout, style}, ...]

layout包含会影响模块定位的属性,包括size,margin,border,float,position,padding,line-height,display等 (padding需要注意,因为当设置了width/height时,也padding会影响占位,所以虽然padding的语义是控制内容空间,但还是要放在布局的级别上)。 这些应该是对应render中的layout阶段的。

style则是剩下的元素显示效果,对应render中的paint阶段。

所以大体的顺序应该是:

  1. 全局名字空间的layout(nav,footer,header,section,main,aside,h1,h2,h3,h4等等的布局样式)
  2. 全局名字空间的style(nav,footer,header,section,main,aside,h1,h2,h3,h4等等的效果样式)
  3. aside,main,nav,header,footer等模块的layout
  4. aside,main,nav,header,footer等模块的style
  5. aside内模块的layout
  6. aside内模块的style

对于一些模块间共用的样式,可以单独抽离出来成为独立的模块放到全局环境中去

乍看这样可能会写出很多重复的选择器,就比如layout和style或许没必要分这么开。但个人的实践中,layout和style的选择器的重复部分似乎并不大, 比如.a模块中设置了h1的layout,并不意味着就也要设置它的style,因为它已经继承了全局的设置了,所以单独再样式集内分离layout,style意义不大,还是需要在整体代码上分离开来。

而且layout与style也是独立的,基本上写css都是先layout再style这个先繁后简的流程。

关于css的其他想法

通用原子类?

http://book.douban.com/people/houkanshan/annotation/4881987/

其实也看到一些同学这样做了。

我是比较反对通过直接在html上加具有样式意义的class来修改html的样式的,尤其是在css预处理器出现之后。 这些工作完全可以在预处理阶段完成。说是开发上快速,其实没有什么区别。在html模板上修改样式会很爽么?

更重要的就是破坏内容样式分离,有优先级被覆盖的问题,弄乱了html,也弄乱了css。

即使是为了javascript处理交互效果时方便加class,也不应该这样做。最容易出现优先级的问题。 而且,既然做selected的时候用的是给selected单独css,为什么在设置浮动的时候又要用base里面的东西而不能直接多写一点样式呢? 而且写在css里面就可以让人知道这个元素将来可能的表现了。

一个做过前端的妹子某次问我最近再做什么,然后问我写css不无聊么。

这真不好回答,其实我还想写点css,虽然最后编译出来的东西都是那么一坨。。。

以上,请指责。