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

要避免当状态改变时名称失去意义，最常见的就是用于布局的类名，如“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 段落文本颜色 .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”表示提示里文字强调的定义，至于是改变颜色还是加粗，这个就看不同提示模块的需要了。