CSS架构的优选和解决方案

背景

上周我厂前端小伙伴们开了一个技术交流会，关于如何优选CSS架构、解决掉平时写CSS时频繁出现的各种问题，这是前端人员老生常谈的问题，但却很少搬上台面，铺开正式地开交流会。这次会议，便是围绕CSS架构以及寻求解决CSS顽疾的解决方案这两个中心点展开。

主题：

1.自己理想中的CSS架构

2.现如今项目中CSS维护存在的问题

3.自动化工具的选择

4.文件结构与命名规范

理想中的CSS架构

1.复用性强，作为组件可引入不同项目，低耦合，对原有CSS无污染

2.结构框架清晰，简单明了

3.命名规范、易懂，有注释，代码阅读无障碍

项目中CSS维护存在的问题

1.因没有事先规范，后期维护困难，无从下手，越维护越臃肿，到最后项目的CSS病入膏肓

2.CSS容易冲突。当修改眼前这个弹层，也许另外几个弹层都受影响，耦合度高

3.CSS表结构没有区分好，混乱

4.CSS拓展性不强

自动化工具的选择

gulp webpack POSTCSS

文件结构与命名规范

这部分内容并入要点

要点

1.全局定义样式时，reset.css和normalize.css推荐选择后者：体积小，在默认的HTML元素样式上提供了跨浏览器的高度一致性

2.命名样式时，不要用特定的属性命名，如字号：f16、f18。当你这么命名，如果需求有修改用f15、f17,这种字号时，无法全局修改（按钮同理，纯粹的btn-ok、btn-cancel无法应对后发需求）。可以用x、s、l、xl这类抽象代号，达到多态效果：同一个样式命名，可以随时更换CSS具体值，不同输出

3.CSS的可拓展性很重要。不要直接用标签定义样式，容易耦合。也不要用通用性高的类名，如title，这种命名率很高，假如你引入插件或者外来样式表，很可能也有这么一个title，发生冲突

4.考虑是否使用某个CSS架构时，要多方面考虑，如果对于团队来说学习成本过高，那么这个架构弊大于利（css-helper）

5.CSS文件表如何区分？先考虑各个模块是什么功能，用来做什么的，把同类别的模块归类，再合并成一个同类的CSS文件，以类别分表

6.CSS命名时，通过样式用途命名，有命名空间的概念。例如c-就是组件，这样当你命名时，可以通过样式名一眼就看出这个样式是干什么的

7.做任何项目之前，都要先定一个大家都来遵守的规范，互相监督。这个规范可以随着项目的实际需要而变化，开发人员一起维护这个规范。当某一条规范不明确或有争议，要抛出问题，先解决问题，再开发。

难点遗留

1.OOCSS、BEM写法有缺陷：解放了CSS但HTML会变得臃肿。这两者如何取到一个平衡点？

2.OOCSS、BEM各有优缺点，能否通过混搭使用，进行互补？

3.随着开发进程，SASS文件会越来越大，在webpack编译中会越来越慢。能否通过使用POSTCSS这个自动化工具来取代SASS？