CSS 代码的编写规范
更新日期:
在很多开发人员眼里，编写 CSS 不但简单有时还会显得很繁琐-相同的属性得一个劲不停地写。为此，曾经自己也迷惑过也遇到过不少问题，但随着写&读的前端代码渐渐增多，慢慢体会到，“能写”和“会写”之间还是有一定距离的。很多时候，你可以“这样做”，但并不意味着“你应该”这么做。
合理地编写CSS，可以让代码看起来更专业。即便是很简单的几行代码，也要写的有性格。嗯~用饱含工匠精神的态度去写码，你一定会在苦逼中作乐的。
以下整理些从别人那读到学到的，同时自己认可的琐碎的点，供实战中践行。
属性的值
- 对于以逗号分隔的属性值：每个逗号后，都应该插个空格。eg. background-image: url(…), url(…);
- 值内部的多个属性之间：不要加空格
- 避免为0指定单位：margin:0 即可
- 值小于1的，省略小数前面的0：即 -.5px代替 -0.5px，.5代替0.5
- 16进制尽量简写：eg. #fff 而不是#ffffff
- 选择器中的属性：建议都加双引号，为了一致性（而且还有其他原因）
声明
- 每条声明-最好独行：更准确的错误报告
- 若有选择器分组，每个单独成行
- 空格：声明的左花括号之前；属性值前
- 所有声明语句后，都写分号 <虽然最后一条声明语句后的分号;是可选的>
声明顺序
相关的属性声明归为一组，按照下面的顺序排列：
- 定位 positioning：可以从正常的文档流中移除元素，还能覆盖盒模型的相关样式，所以首位。
- 盒模型 box model：决定了组件的尺寸和位置，所以第二位。
- 排版类 typographic
- 视觉类 visual
简写属性
在需要显示地设置所有值的情况下，应尽量限制使用简写的属性声明。
常见的滥用：
padding, margin, font, background, border, border-radius 【？？这不就是我经常简写的么】
大部分情况下，我们不需要为简写形式的属性声明指定所有值。
例如，HTML 的 heading 元素只需要设置上、下边距（margin）的值，因此，在必要的时候，只需覆盖这两个值就可以。
过度使用简写形式的属性声明会导致代码混乱，并且会对属性值带来不必要的覆盖从而引起意外的副作用。
class命名
- 只能出现：小写字符 和 波折号-（破折号应该用于相关的class命名，类似于命名空间） 而不是下划线也不是驼峰
eg. .btn .btn-danger - 避免过多简写，比如 .btn 代表 button，但是 .s 就啥也不是
- class应尽可能短 & 意义明确
- 要有意义：要有组织+有目的，不要用表现形式
- class的前缀：基于最近的父或基 作为新class的前缀
- 用js-的class：来标识行为，与样式相对：且不应用到css中（同理：纯css样式的，也尽量不要用于脚本-不便于维护）
CSS 选择器
- 对于通用的元素，用class：有利于渲染性能的优化
- 经常出现的组件，避免使用属性选择器：影响浏览器性能 【各个选择器的性能如何？？】
- 尽可能短：建议不要超过3个
- 只有在必要的时候，才将class限制在最近的父元素内（及后代选择器） 【选择器并非越长越好】
代码组织
- 以组件为单位组织代码段。
- 如果使用了多个 CSS 文件，将其按照组件而非页面的形式分拆，因为页面会被重组，而组件只会被移动。 【页面会被重组，而组件只会被移动】
- 制定一致的注释规范。
- 使用一致的空白符将代码分隔成块，这样利于扫描较大的文档。
代码注释
- 代码要：自描述（嘿嘿，这个时候就可以少点注释了）
- 好的注释：传达上下文关系、代码目的 （而不是很苍白地重申些废话）
- 可以英文注释（长的写完整句子，短的就可以写短语）
其他
因为用的少，所以。。。仅仅是知道，但还没使用场景。
- 不要使用@import
因为：@import指令要比标签慢很多（不光增加了额外的请求次数，还会导致不可预料的问题）
可替代的方法：
a.用多个
b.通过Sass或Less类似的CSS预处理器将多个CSS文件编译成一个文件
c.将CSS文件合并 - 媒体查询的位置 【移动开发会较多】
建议：将放在尽可能相关规则的附近
不要将它们打包放在一个单一样式文件 or 文档底部 - Less和Sass中的嵌套 【表示…不曾用过】
避免非必要的嵌套：你可以使用，但并不意味这应该使用
什么时候用嵌套：限制在父元素内（即后代选择器）+ 多个需要嵌套时才用
参考
编码规范 by @mdo
关于shorthand properties 的文章：对于不太熟悉简写属性声明及其行为的用户很有用