CSS属性书写顺序及命名规则
传说中的Mozilla推荐
来源：
在怿飞’s Blog的这篇文章里，又将上面的属性分成了三组：显示属性、自身属性和文本属性。在回复里，inG补充这还和浏览器的解析过程有关：浏览器先对DOM定位，然后解析自身属性，接着再解析内部对象。（没找到相关的英文资料，有知情者还望告知）
在Mozilla官方，其实并没有推荐任何CSS书写顺序。很可能是某个开发者在阅读fantasai的这篇文章 mozilla.org Markup Reference 时，顺便对fantasai的CSS源文件产生了兴趣，因此才有了上面的发现。
字母排序
NETTUTS上时不时有些好文章，这不，前不久，Trevor Davis就分享了一篇：5 Ways to Instantly Write Better CSS. 这篇文章中，推荐CSS的属性按字母排序。
优点是：简单，任何人只要遵守，一看就明白。
缺点是：太简单，缺乏逻辑性。比如position, left, top等，这种紧关联的属性，如果都按字母排序，书写和维护起来都不方便。Andy Ford推荐的排序
Andy Ford是HTML和CSS方面的专家，最近写了一篇文章：Order of the Day: CSS Properties. 文章推荐的CSS书写顺序为：
Andy的顺序大体上和fantasai推荐的顺序保持了一致，但细节上更具可操作性。
SitePoint上还有个很热烈的讨论贴：How do you order your properties within a declaration block?
我喜欢fantasai和Andy的书写顺序，但fantasai的顺序中，“自身”属性有点含混不清，Andy的则太细，难以记住。我觉得可以借鉴CSS 2.1 Specification中对CSS属性的分类，将Andy的顺序稍微调整下：
1. 影响文档流的属性（比如：display, position, float, clear, visibility, table-layout等）
2. 自身盒模型的属性（比如：width, height, margin, padding, border等）
3. 排版相关属性（比如：font, line-height, text-align, text-indent, vertical-align等等）
4. 装饰性属性（比如：color, background, opacity, cursor等）
5. 生成内容的属性（比如：content, list-style, quotes等）
事情永远没那么简单，比如下面这些困扰：
1. 对于shorthand怎么处理？比如 border: 1px solid red; 其中border-width是和盒模型相关的，但border-color是装饰性的。如何组织呢？
2. 考虑到换肤功能，是否应该将color, background, border-color等和颜色相关的都放一块？以方便以后修改。
3. 对于hacks如何处理？单独放到css文件最后面，还是和hack的属性紧挨着好？
4. 维护同事的css文件时，对于新增加或有修改的属性，如何注释？如何书写？
5. 还有，考虑到CSS Sprite, 所有背景图的选择器都放在一起？不过这已经超出本文的话题了：CSS选择器内属性的顺序和组织。
6. 更进一步的讨论是：CSS文件内的结构组织，以及多个CSS文件的组织。
CSS命名规则：
Css和其他程序一样，都是有作用域这个概念，有全局、类局部作用这些方式。
举个例子：
p{background:#f00;}/* 作用域 ：全局 */
.div p{color:#000;}/* 作用域：div类中*/
介绍下Css几种编写方式和权重对比
1）标签：权值为0,0,0,1
2）类：权值为0,0,1,0
3）属性选择：权值为0,0,1,1
4）ID：权值为0,1,0,0
5）important的权值为最高1,0,0,0
相信大家在编写Css的时候，当项目比较大，内容比较多的时候，命名就是一件很头痛的事情，而且一个块里面要表现不同状态的样式 ，这是有掌握命名规则是一把利器，能让你工作起来事半功倍。大致如下：（转载自：http://www.cssforest.org/blog /index.php?id=143，大家可以去这里看，比较多的技术文章）
要避免当状态改变时名称失去意义，最常见的就是用于布局的类名，如“left”、“right”，当左边栏不再是左边栏的时候，“left”这个名就没有实际意义了。这与我们所推荐的 “命名要有意义”就相违背了，使用序号就更加有问题了。好像没错，不过有好长一段 时间都有个问题让我很烦恼，如果一个页面中同个模块出现一次以上，而且细节还不一样，那后面出现的名称应该叫什么呢？难道“one”、“two”就不是序 号？其实我们要避免遇到的情况就是当状态（表现）改变时，对应定义的类名不会失去意义。
所谓的状态（表现）改变，有几种情况：
1. HTML不变，样式定义改变。如果命名使用了表示某一状态的名称，如“red“、“font14“等，必定会引起定义与命名不符的情况，对后继的影响会造成比较大的影响。
2. 样式定义不变，HTML改变。HTML改变意味着类名可更换，也就是如果类名使用了表示某一状态的名称，反而更有利于修改。
3. 样式定义与HTML都改变。只需要考虑不要出现第一种情况的结果就可以了。
而实际情况并不是单纯的某一种情况，更多的时候是混杂着出现的。
规则
[ 模块前缀 ] _ 类型 _ ( 作用 | 状态 ) n _ [ 位置 n ]
图例说明：
* ( 必选 )：必需存在。
* [ 可选 ]：可根据需要选择。
* |：多选一。
* n：可有多个。
名词说明：
模块前缀
模块定义时使用的前缀。
类型
定义类的内容类型。如输入框、文本、段落等等。
作用
定义类的作用，用于对类型的补充。
状态
定义类的状态，用于对类型的补充。
位置
定义类所使用的位置，如首页、导航等等，不排除使用左、右这样的词，但应尽量避免。
* 每项都可有自己的一个缩写表，同一名称的缩写尽量统一。
* 所选用的单词应选择不过于具体表示某一状态（如颜色、大小等）的单词，以避免当状态改变时名称失去意义。
* 由不以数字开头的小写字母（a-z）、数字（0-9）组成。
* 确保类(.class)的重用性与对象(#id)的唯一性，id避免使用保留字。
例：
中文解释 命名 中文解释 命名
文本输入框 .input_tx 段落文本颜色 .c_tx_p
密码输入框 .input_pw 相册弹出的设置层 .pop_set_photo
登录密码输入框 .input_pw_login 日志设置成功提示 .hint_suc_blogset
文本颜色 .c_tx 公共提示 .hint_gb
问几个简单的问题，可以帮助我们完成命名：
1. “什么类型的定义？”——是个输入框，input。
2. “类型补充说明”——如果一个词说明不清楚，那么补充说明类型，文本输入框，input_tx。
3. “在哪使用？”——定义要使用的位置在哪？首页的搜索文本输入框，input_search_index。
结合“模块化”相关的方法去定义，其实所需要定义的名称并不需要很多。 如：“hint_tx”表示提示模块的文字定义，“hit_tx_hint”表示提示里文字强调的定义，至于是改变颜色还是加粗，这个就看不同提示模块的需要了。
/* mozilla.org Base Styles * maintained by fantasai */ /* Suggested order: * display * list-style * position * float * clear * width * height * margin * padding * border * background * color * font * text-decoration * text-align * vertical-align * white-space * other text * content * */ ...
来源：
http://www.mozilla.org/css/base/content.css
在怿飞’s Blog的这篇文章里，又将上面的属性分成了三组：显示属性、自身属性和文本属性。在回复里，inG补充这还和浏览器的解析过程有关：浏览器先对DOM定位，然后解析自身属性，接着再解析内部对象。（没找到相关的英文资料，有知情者还望告知）
在Mozilla官方，其实并没有推荐任何CSS书写顺序。很可能是某个开发者在阅读fantasai的这篇文章 mozilla.org Markup Reference 时，顺便对fantasai的CSS源文件产生了兴趣，因此才有了上面的发现。
字母排序
NETTUTS上时不时有些好文章，这不，前不久，Trevor Davis就分享了一篇：5 Ways to Instantly Write Better CSS. 这篇文章中，推荐CSS的属性按字母排序。
优点是：简单，任何人只要遵守，一看就明白。
缺点是：太简单，缺乏逻辑性。比如position, left, top等，这种紧关联的属性，如果都按字母排序，书写和维护起来都不方便。Andy Ford推荐的排序
Andy Ford是HTML和CSS方面的专家，最近写了一篇文章：Order of the Day: CSS Properties. 文章推荐的CSS书写顺序为：
1. Display & Flow
2. Positioning
3. Dimensions
4. Margins, Padding, Borders, Outline
5. Typographic Styles
6. Backgrounds
7. Opacity, Cursors, Generated Content
例子：
el {
display: ;
visibility: ;
float: ;
clear: ;
position: ;
top: ;
right: ;
bottom: ;
left: ;
z-index: ;
width: ;
min-width: ;
max-width: ;
height: ;
min-height: ;
max-height: ;
overflow: ;
margin: ;
margin-top: ;
margin-right: ;
margin-bottom: ;
margin-left: ;
padding: ;
padding-top: ;
padding-right: ;
padding-bottom: ;
padding-left: ;
border: ;
border-top: ;
border-right: ;
border-bottom: ;
border-left: ;
border-width: ;
border-top-width: ;
border-right-width: ;
border-bottom-width: ;
border-left-width: ;
border-style: ;
border-top-style: ;
border-right-style: ;
border-bottom-style: ;
border-left-style: ;
border-color: ;
border-top-color: ;
border-right-color: ;
border-bottom-color: ;
border-left-color: ;
outline: ;
list-style: ;
table-layout: ;
caption-side: ;
border-collapse: ;
border-spacing: ;
empty-cells: ;
font: ;
font-family: ;
font-size: ;
line-height: ;
font-weight: ;
text-align: ;
text-indent: ;
text-transform: ;
text-decoration: ;
letter-spacing: ;
word-spacing: ;
white-space: ;
vertical-align: ;
color: ;
background: ;
background-color: ;
background-image: ;
background-repeat: ;
background-position: ;
opacity: ;
cursor: ;
content: ;
quotes: ;
}
Andy的顺序大体上和fantasai推荐的顺序保持了一致，但细节上更具可操作性。
SitePoint上还有个很热烈的讨论贴：How do you order your properties within a declaration block?
我喜欢fantasai和Andy的书写顺序，但fantasai的顺序中，“自身”属性有点含混不清，Andy的则太细，难以记住。我觉得可以借鉴CSS 2.1 Specification中对CSS属性的分类，将Andy的顺序稍微调整下：
1. 影响文档流的属性（比如：display, position, float, clear, visibility, table-layout等）
2. 自身盒模型的属性（比如：width, height, margin, padding, border等）
3. 排版相关属性（比如：font, line-height, text-align, text-indent, vertical-align等等）
4. 装饰性属性（比如：color, background, opacity, cursor等）
5. 生成内容的属性（比如：content, list-style, quotes等）
事情永远没那么简单，比如下面这些困扰：
1. 对于shorthand怎么处理？比如 border: 1px solid red; 其中border-width是和盒模型相关的，但border-color是装饰性的。如何组织呢？
2. 考虑到换肤功能，是否应该将color, background, border-color等和颜色相关的都放一块？以方便以后修改。
3. 对于hacks如何处理？单独放到css文件最后面，还是和hack的属性紧挨着好？
4. 维护同事的css文件时，对于新增加或有修改的属性，如何注释？如何书写？
5. 还有，考虑到CSS Sprite, 所有背景图的选择器都放在一起？不过这已经超出本文的话题了：CSS选择器内属性的顺序和组织。
6. 更进一步的讨论是：CSS文件内的结构组织，以及多个CSS文件的组织。
CSS命名规则：
Css和其他程序一样，都是有作用域这个概念，有全局、类局部作用这些方式。
举个例子：
p{background:#f00;}/* 作用域 ：全局 */
.div p{color:#000;}/* 作用域：div类中*/
介绍下Css几种编写方式和权重对比
1）标签：权值为0,0,0,1
2）类：权值为0,0,1,0
3）属性选择：权值为0,0,1,1
4）ID：权值为0,1,0,0
5）important的权值为最高1,0,0,0
相信大家在编写Css的时候，当项目比较大，内容比较多的时候，命名就是一件很头痛的事情，而且一个块里面要表现不同状态的样式 ，这是有掌握命名规则是一把利器，能让你工作起来事半功倍。大致如下：（转载自：http://www.cssforest.org/blog /index.php?id=143，大家可以去这里看，比较多的技术文章）
要避免当状态改变时名称失去意义，最常见的就是用于布局的类名，如“left”、“right”，当左边栏不再是左边栏的时候，“left”这个名就没有实际意义了。这与我们所推荐的 “命名要有意义”就相违背了，使用序号就更加有问题了。好像没错，不过有好长一段 时间都有个问题让我很烦恼，如果一个页面中同个模块出现一次以上，而且细节还不一样，那后面出现的名称应该叫什么呢？难道“one”、“two”就不是序 号？其实我们要避免遇到的情况就是当状态（表现）改变时，对应定义的类名不会失去意义。
所谓的状态（表现）改变，有几种情况：
1. HTML不变，样式定义改变。如果命名使用了表示某一状态的名称，如“red“、“font14“等，必定会引起定义与命名不符的情况，对后继的影响会造成比较大的影响。
2. 样式定义不变，HTML改变。HTML改变意味着类名可更换，也就是如果类名使用了表示某一状态的名称，反而更有利于修改。
3. 样式定义与HTML都改变。只需要考虑不要出现第一种情况的结果就可以了。
而实际情况并不是单纯的某一种情况，更多的时候是混杂着出现的。
规则
[ 模块前缀 ] _ 类型 _ ( 作用 | 状态 ) n _ [ 位置 n ]
图例说明：
* ( 必选 )：必需存在。
* [ 可选 ]：可根据需要选择。
* |：多选一。
* n：可有多个。
名词说明：
模块前缀
模块定义时使用的前缀。
类型
定义类的内容类型。如输入框、文本、段落等等。
作用
定义类的作用，用于对类型的补充。
状态
定义类的状态，用于对类型的补充。
位置
定义类所使用的位置，如首页、导航等等，不排除使用左、右这样的词，但应尽量避免。
* 每项都可有自己的一个缩写表，同一名称的缩写尽量统一。
* 所选用的单词应选择不过于具体表示某一状态（如颜色、大小等）的单词，以避免当状态改变时名称失去意义。
* 由不以数字开头的小写字母（a-z）、数字（0-9）组成。
* 确保类(.class)的重用性与对象(#id)的唯一性，id避免使用保留字。
例：
模块前缀：
* 弹出 pop
* 公共 global,gb
* 标题 title,tit
* 提示 hint
* 菜单 menu
* 信息 info
* 预览 pvw
* Tips tips
* 导航 nav
类型：
* 按钮 bt
* 文本 tx
* 段落 p
* 图标 icon
* input input
* 颜色 color,c
* 背景 bg
* 边框 bor
作用：
* 设置 set
* 添加 add
* 删除 del
* 操作 op
* 密码 pw
* 导入 inc
状态：
* 成功 suc
* 失败 lost
* 透明 tran
位置：
* 公共 gb
* 边框 bor
* 段落 p
* 弹出 pop
* 标题 title,tit
* 菜单 menu
* 内容 cont
* 导航 nav
中文解释 命名 中文解释 命名
文本输入框 .input_tx 段落文本颜色 .c_tx_p
密码输入框 .input_pw 相册弹出的设置层 .pop_set_photo
登录密码输入框 .input_pw_login 日志设置成功提示 .hint_suc_blogset
文本颜色 .c_tx 公共提示 .hint_gb
问几个简单的问题，可以帮助我们完成命名：
1. “什么类型的定义？”——是个输入框，input。
2. “类型补充说明”——如果一个词说明不清楚，那么补充说明类型，文本输入框，input_tx。
3. “在哪使用？”——定义要使用的位置在哪？首页的搜索文本输入框，input_search_index。
结合“模块化”相关的方法去定义，其实所需要定义的名称并不需要很多。 如：“hint_tx”表示提示模块的文字定义，“hit_tx_hint”表示提示里文字强调的定义，至于是改变颜色还是加粗，这个就看不同提示模块的需要了。