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
分享到微信 
分享到微博
