平时我都怎么组织CSS

CSS的管理一直是个让人有点头疼的问题，没有绝对的对错，无非就是为了方便管理、修改和多人合作罢了；

网上流行的CSS管理方式讲来讲去无非也就以下几种：

1、对于单个页面那种非常简单的，其实也可以直接把所有的样式写在一个外部文件里就行，或者直接写在页面的头部里，没有必要去纠结繁琐的CSS文件管理

2、读过《精通CSS：高级Web标准解决方案》那本书的人都应该对作者如何去组织、规划和维护样式表有深刻印象：

多个CSS文件可以利用@import导入的页面中，好处是减少HTTP请求数，坏处是导入样式要比链接样式的速度慢，而且导入的文件有顺序的规定，顺序不当常常会出现样式没办法应用等错误，也是让人无比纠结。

而对于全部写在单个文件的，其内部最好有合理的设计结构和注释：

（1）一般性样式：

主体样式；reset样式；链接；标题

（2）辅助样式

表单；通用和错误；一致的条目

（3）页面结构

标题、页脚和导航；布局；其他页面结构元素

（4）页面组件

各个页面

（5）覆盖

然后使用大注释块来分割每个部分

/* @group general styles
---------------------------------------------------------------*/

而小区域可以用小块注释：/*nav*/

这种分割方法虽然明确，但是需要开发人员进行判断，项目很大时，这种判断是需要耗费很多时间去很分析的，好的组织和规划是需要耗时间的...

自我提示：

适当的注释可以为后期的开发有很大的帮助，例如：

/*字体颜色定义说明
@colordef #F00; 红色
*/

也可以使用@tudo来表示某些东西需要后期修改、修复或复查，用@bugfix表示代码或特定浏览器遇到的问题，用@workaround表示并不完善的权宜之技（这些都跟JS的的相似，统称为gotcha）

/*@tudo 网站上线之前记得删除此规则*/
/*@bugfix 解决IE6的双边距问题*/
/*@workaround 我试图去解决这个在IE6下的XXX问题，但它似乎表现的还不够好*/

3、另外网上也流行一种模块化css的文件分类方法：

reset.css // 对阅读 器的默认样式执行 重设
layout.css // 管理页面的布局
typeset.css // 图文的编排与
color.css // 统一管理颜色的搭配
print.css // 打印效果样式
ie.css // 把对ie的hack单独分开

或：

reset.css
header.css // 头部的所有样式
container.css // 除头部/底部外的中间区域样式
footer.css // 底部样式
print.css
ie.css

以上的分类看似合理且仅仅有条，但管理起来很麻烦，也不是每个人都可以百分百了解每个CSS文件里面的内容，所以疑问就来了：

（1）效率疑问 与最终目的

在站点 内容上面，如果改某一个区域的内容，可能要多个 CSS都改。这样一来，本来基本 的一个修改，开始变得复杂起来。并且，如果多个都改，可能会使我们忽略了某些东西，又须要 进一步调试，这样不仅肯使最终目的实现延后，还是一个效率的疑问 。

（2）调用尽可能少的CSS文件

大多楼情况下，一个站点 都是分成头部，中部和底部，并且，一般，要做新的频道/页面之类的东西，都不会变动头部和底部，而只是变动中间部分。这样一 来，所有CSS文件都要调用，因为，HTML和CSS的模块化并不一致。这样，就会导致服务器承受更多的压力。这是一个方面。另一个方面是，如果新页面中 某些元素与其他页面有冲突，我们可能要搞一大堆关于优先性选择的代码，添加 代码量。这些都不是我们想要的。这就为什么要把header.css和 footer.css分开来的原由 。

（3）多人合作上的疑问

如果我们多个人在工作，大家的分工可能是，有人完成头部的导航，有人完成底部的搜索条，有人完成中部新页面的构建。这样一来，大家都同时在改多个 文 件，并且，改的东西不同。如果要更新到服务器，就要先比较 ，再更新。（当然，现在有版本管理这样的软件。但是，同时工作的话，版本也是一个疑问 ，要相信， 或许更新永远都改不上改动 。）

4、第四种就是采用CSS框架了，比如我最喜欢的960 GRID和YUI CSS Framework，大体原理一样：一个css reset一个font定义和一个核心的Grids网格布局文件，然后就是各种布局位置计算,然后自己就可以写页面的其他样式了

5、使用CSS预处理器（Sass、LESS 和 Stylus）帮助简化CSS内容和组织管理，这个可以常见详细

我自己的管理组织管理方法：

之前看过的《编写高质量代码 Web前端开发修炼之道》，作者给出了一个非常通用的css组织方式:base+common+page,但其实也有很多人喜欢把base直接写在common里面，反正也是站点的几乎所有页面都调用，我用的最多的是commom（全站调用）+page（独立页面样式，名字自定义也可）两个文件的方式（也是因为后来项目的原因才慢慢喜欢上的），当然前提是全站风格统一， 可以做得很模块化，需求变动不大；common的的样式权限一定要在应用效果的情况下保持尽可能低，以方便后期需求突变时可以强行覆盖；

其实组织样式考虑因素还是有的，只是一般我比较通用以上那种：

（1）首先当然要看项目的规模和访问量

项目的规模大小是组织样式一个非常重要的参考基准，小网站多几个HTTP请求有何妨,多几个样式也不会有很大的性能变化，而像淘宝、新浪微博、腾讯QQ空间这些大项目就不同了，太多的CSS文件引入页面会有较明显的载入延迟，所以如何去尽量减少css文件的情况下做到尽可能的便于后期维护是重要的，如果有可能可以使用CDN；

参考之前的方法，可以为按功能或页面区块分成多个css文件,然后根据需要利用@import导入到一个文件中，然后再引入页面中

（2）页面实现的复杂度及需求变换程度

页面的复杂程度基本上是如何组织CSS我觉得最重要的考虑因素了，风格统一的网站header和footer不会变，我们可以做成一个模块化方便调用、你可以把它写在common.css里面全站都应用，大家常用的reset也应该写在这里面，完全没必要单独写一个reset.css文件，因为所有的全站都会用到；然后最重要的就是分析页面的其他部分是不是有设计相同的部分，有的话抽离出来放到common里面，全站都可以调用，这个就是所谓的CSS组件化了

还有一个非常纠结的问题，我想做前端时最理想的是：设计师设计好所有的稿然后交给前端“一次性”全部转换为Web页面、多好啊！样式等文件一开始就可以参照设计稿进行全方位的规划组织，想怎么弄怎么弄，清晰明了；可现实就是那么骨干、尼玛有时设计稿变化大到你想吐血，还是半路穿插进来的，你会发现什么头部header和尾部footer又得重写个新的了，之前的模块话也都完全用不上了，而有时又只是一个页面而已（比如专题页），很不情愿为其模块化， 纠结啊！，所以我常常在不破坏整站的整体风格的情况下，会专门定义一个文件夹来存放这些蛋疼页面的CSS样式，我不想让他们共用全站的CSS文件，这个文件里同样有个common.css文件存放诸如css reset、base原子类供所有单独页面调用，然后每个页面会有一个page.css或style.css专门定义页面样式的，而代码冗余不冗余已经不是重点了，管它去死，尽量写得简洁规范高效即可

 

原文链接：http://www.cnblogs.com/guosh/archive/2012/07/19/2599551.html