第
CSS语法检查利器之csslint
前段时间研究使用YUICompressor压缩项目里的js和CSS文件，研究了两天之后，终于在周三晚上把YUICompressor集成进了打包流程中；于是周四（2015-11-12）早晨一到办公室，第一件事就是把相关的构建脚本提交至配置库。
从诡异的问题开始
刚高兴没多久，测试MM就发现一个Bug，有个页面的样式出了问题，导致自动化用例执行失败，要求开发尽快处理。
起初没太注意，感觉只是个小问题，于是直接让对应特性的开发责任人去定位。一个小时之后，测试MM过来问进展，我才发现小问题不简单，一个小时过去了，但开发人员并没有找到问题原因。
开发人员很无奈，因为现象确实比较奇怪：
目前发现仅在Linux部署的那套环境上出现了样式出错的现象；
在开发人员、测试人员本地搭建的环境上，并没有类似的现象；
开发人员定位的结果，页面引用的样式文件中，从某个定义开始，后面的样式全部都未生效；
出问题的页面本周有新特性开发，但引用的样式文件本周并没有人做过更新；
对于现象本身，有来自测试人员进一步的反馈：
自动化用例验证昨天的版本时，并没有发现样式的问题；
测试人员反馈，早晨升级Linux环境前，人工验证时并没有发现样式的问题；
结合这些信息，突然想到上午我才把css压缩相关的构建脚本合入配置库，而出现问题的版本正好是使用更新过的构建脚本打包出来的，那么会不会是压缩工具引入的问题？带着这个疑问登录到Linux部署环境上，使用vim查看对应的css文件，有如下发现：
样式文件被压缩至一行；
在某一个字符后的内容，没有高亮，感觉像是vim的语法高亮似乎有问题；
由于文件内容压缩之后查看实在辛苦，于是打开eclipse查看问题相关的css文件。这时在开发人员反馈的样式定义附近，找到一处如下的css代码。
#wrapper{
display:block;
margin:0auto;
text-align:left;
min-width:720px;看到这行代码的问题了吗？
max-width:1000px;
问题找到了，原来是开发人员定义样式时，本意是书写min-width:720px;，但在min-width后面多打了一个，于是成了min-width:720px;。
找到这里，我有一个猜测，对于未压缩的样式，浏览器在加载到前述样式定义时，会直接忽略掉min-width的定义，但max-width和后续的样式定义还是有效的；但当样式文件被工具压缩到一行之后，min-width的错误会导致后续的样式定义全部被忽略掉，于是出现了前述测试MM反馈的问题。
为了证实我的想法，决定拿问题环境做个实验，直接在环境上修改css文件。
于是登录Linux环境，使用vim修改对应的css文件，将多余的删除掉，这时vim的语法高亮恢复了正常。然后使用浏览器登录页面，清除缓存后访问之前有问题的页面，发现页面的样式恢复正常。
问题解决之后
问题虽然解决了，但问题本身值得回味。
css是脚本，和js不同，浏览器在加载css时不会校验语法，遇到错误不报错，反而会安静的忽略。这次的问题发现了，解决了，那么下次呢？下次也要花费三人时来定位和解决吗？这就纠结了，毕竟类似前述的问题靠人眼来检查css文件的语法，其实挺痛苦的。
那么有没有什么工具可以检查css的语法，在开发时就能提前发现问题，避免类似问题发生？在网上搜索了一圈，找到了csslint。
csslint
什么是csslint
如下截取自项目主页。
CSSLintisatooltohelppointoutproblemswithyourCSScode.Itdoesbasicsyntaxcheckingaswellasapplyingasetofrulestothecodethatlookforproblematicpatternsorsignsofinefficiency.Therulesareallpluggable,soyoucaneasilywriteyourownoromitonesyoudontwant.
代码主页/CSSLint/csslint，在线检查工具。
项目的官方文档非常详细，由此可见项目的开发人员非常用心。从文档看，csslint的使用很简单。
命令行方式
进入命令行，执行如下命令，将检查test