样式命名规则

相信大家对样式命名都多少感到困难，特别是想起一个有意义的名，更难。回顾了一下之前写的《 样式命名规则 》（不知道大家使用后有什么感想）结合这段时间使用上发现的一些问题，重新整理了样式的命名规则，希望能更实用些。

要避免当状态改变时名称失去意义，最常见的就是用于布局的类名，如“left”、“right”，当左边栏不再是左边栏的时候，“left”这个名就没有实际意义了（可以看下《 CSS代码命名惯例语义化的方法.. 》中的“CSS类命名的语义化VS结构化方式”部分）。这与我们所推荐的“命名要有意义”就相违背了，使用序号就更加有问题了。好像没错，不过有好长一段时间都有个问题让我很烦恼，如果一个页面中同个模块出现一次以上，而且细节还不一样，那后面出现的名称应该叫什么呢？难道“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 段落文本颜色 .tx_c_p
密码输入框 .input_pw 相册弹出的设置层 .pop_set_photo
登录密码输入框 .input_pw_login 日志设置成功提示 .hint_suc_blogset
文本颜色 .tx_c 公共提示 .hint_gb

问几个简单的问题，可以帮助我们完成命名：

1.“什么类型的定义？”——是个输入框，input。
2.“类型补充说明”——如果一个词说明不清楚，那么补充说明类型，文本输入框，input_tx。
3.“在哪使用？”——定义要使用的位置在哪？首页的搜索文本输入框，input_search_index。
可能无法覆盖到所有的情况，但相信能解决70%~80%的命名问题。如果结合“模块化”相关的方法去定义，其实所需要定义的名称并不需要很多。如：“hint_tx”表示提示模块的文字定义，“hit_tx_hint”表示提示里文字强调的定义，至于是改变颜色还是加粗，这个就看不同提示模块的需要了。