我的CSS架构

写在前面

都是自己看别人的架构，自己积累下来的一些东西，这里只是阐述自己的一些观念。借此希望同行交流交流下看法，共勉。

不同架构的CSS

业务流程不同，团队配员不同。会有各种各样的CSS架构。

有的会分为：header.css，body.css，footer.css

有的会分为：reset.css，main.css，content.css

有的会分为：common.css，然后每个种类再单独划分，比如：首页（index.css）,分页（page.css）

有的直接嵌入到HTML代码中

这些处理方式，只能是适不适合，没有真正的对错之分。

之前做的项目CSS架构的一些问题

上一家公司做的是商城网站，最开始刚接手的时候，sAss 编写的。那会还不是很懂sAss，简单的了解下还是挺好上手的。

坑1：每次改的小东西样式，都得先编译下，虽说有自动编译，对小调整开说不够畅快

坑2：当时编译后是合成到一个css文件，最终呈现的130K左右（未压缩）

坑3：看编译后的css文件，会发现编译后的css层级有些会特别长，看你写的代码耦合程度了。

后来我索性就抛弃的Sass（可能还没挖掘到Sass的好处吧）

1、当时的程序目录结构是跟后台的模块控制器一一对应建文件夹的。我css也就根据模块控制器划分。比如：控制器（home）->首页（index），分页（page）...

2、划分为基础的

base.css（包含浏览器reset，网站基本的header、footer、paging。。）

public_home.css（模块home下面通用的样式）

home_active（模块home下面active样式）

3、这么架构的好处（对于这个项目）

每个页面最多只会引入3个CSS文件，相对体积都比较小

对于之后协同办公，不同的人员改不同的模块，不会冲突

相对之前的，css架构没有按照模块划分，要找到响应的点去修改样式的并不是很容易找，按模块划分小块后，比较容易找到对应的代码

新增模块的话，编辑代码的话比较不会和其他的冲突

现在我是如何架构的

现在的话换了家公司做游戏网站，可能比较倾向使用一个css文件，对于class命名规范化，统一标准。

使用单css文件，会不会随着网站页面增加，相对的css大小会增加。其实不然。

网站如果规划好的话，风格一致，css是可以控制到非常小的。但是类似上面说的商城就不适用了。

CSS内部结构划分

下面慢慢阐述细节~~

CSS reset

 

CSS reset，为了是保证各个浏览器的统一。但是有些CSS reset是没必要的，有时太多的重置代码反而会正佳页面的重写（overwrite）。像*｛margin个:0;padding:0｝更是不可取。像上面的reset,我只是针对该项目下常用的标签简单的重置下，有些大网站的reset写的很细，但是很多标签我们并不是都会用到。所以我们只要取我们常用的，需要的设置reset就可以了。样式精简，而且也高效。

base 基础模块

我们网站基本的框架，顶部、头部、底部单独提取出来，统一base命名。获取你会觉得用base_前赘不是增加代码的大小的？

1、我是这么考虑的统一块的编写，方便以后好维护，如果是多人协助，会比较好改动，也比较明确这块css代码主要是做什么用的。

2、减少名字冲突，下面会讲到。

3、如果页面改动的话，方便删除整块的代码。

global公共样式

主要是单一的一段css代码，没有层级。

1、一般我们网站都会有个主体是要居中显示就想上面的global_body三个样式就会经常用。

2、global前缀，不知道是不是有点多此一举。主要思想也是语义话class样式名。

common常用属性

就是所谓的原子类，之前一直挺排斥这种写法的。主要原因也是那时认为这么写的话：有时后改个小样式，都得来回看，没办法找到对应的css块直接在块上面修改。现在想这么写了主要是精简代码：

1、上面的有些样式是不是有些是挺经常用的，何不有及的结合起来，精简CSS大小。

2、html嵌套原子类的话，原则上最好不要超过3个，比如html看起来会显得比较臃肿。

3、实用原子类，有助于统一效果。有时候设计狮设计的 同个色值可能偏差些色系，导致我们吸取的色值不一样。但其实设计的是要统一的。实用原子类，我们吧常用的色值放一起，就比较不会出现整个网站色值不统一...

public公共模块

像类是的侧边模块，很多个页面都会用到，我就会用public_包起来，这个是有层级的。

命名规则

1、命名规则，语义化命名。之后的层级前赘取父级的首字母组合，再下一层级类推；例如：sort_order-》so_class-》soc_active

2、这样的命名，减少层级（下面会讲到少层级的好处）。你可能会问这样不是会很容易命名冲突？其实只有前缀适合，是不会有这问题。我整一个网站下来，还没碰到过。

3、层级明确方便修改，也方便加上html。有时后端的程序员可能不小心把我们的html结构搞乱了，我们可以根据css的层级还原。

4、减少命名困难。

小结

准则1：对网站同样样式使用global_或者原子类（1~3个属性）。

准则2：少层级，提高渲染速度。css渲染速度是从右到左的，减少层级对渲染速度是有提升的。

<div id="test">
    <ul class="test"></ul>
</div>

 

#test test{}，ul.test{}，#test ul{}，.test{}哪个渲染速度最快？

如果单纯的ul与.test PK，我还真拿不定谁的渲染速度更快些。但是，一旦牵扯到层级与标签，我100%确定，.test这种最直接的命名方式渲染效率是最高的。

准则3：无ID，区分开JS与CSS，写js中如果突然想改下ID的名称，有得改CSS是不是很累。

准则4：少标签，li.list{}这样的写法是很慢的。

多说两句

上面写的这些，在我实际项目使用中，暂时还没发现什么问题，现在团队前端只有我一个，代码也考虑到了多个前端的情况。之后有啥改动在来探讨下经验。

上面的结论，都是我个人的一些观点，经验只谈。有什么诧异之处还忘指点一二...

每个人的成长环境不同，工作环境不同，比然会在某些问题的看法上有许不同。

欢迎交流讨论。

 

小tip：css的渲染速度测试：http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/