Web开发人员可以通过创建CSS类及id名称并使用这些名称来对divs以及其他的格式页面元素进行标识。对开发人员来说，在命名重新定义XHTML标记（tags）的CSS selectors时，必须保证其以及预定义的标记准确匹配，但就类以及id选择器名称而言，则仁者见仁，智者见智。然而随心所欲的为这些类以及id命名则并不是个好的习惯。
在阅读了由Andy Clarke（of Stuff and Nonsense and All That Malarkey）以及Eric Meyer所撰写的关于CSS类以及id命名规范的系列文章之后，我开始思考在个人的的Web站点设计过程中对类以及ids的命名方法。
直观命名
当在设计Web页面以及需求对1个div进行标识的时候，最自然的想法就是使用可以描述元素所在页面位置的词汇来对其命名。这种方法使得类以及id的名称如下面所示之
top之panel
horizontal之nav
left之side
center之column
right之col
这些是CSS以及XHTML类以及id的有效命名方法。这些词汇简单并且能够使人顾名思义，因此满足了标识页面元素以及相应的CSS样式的需求。
但问题是这样的名称同页面内容的特定表达方法相关联。这些命名参考了某种特定页面布局中的页面元素位置，因此在这样的布局之外使用就会显得不合适甚至造成理解混乱。同时，这些命名没有涉及文档内容的结构。因此，下面给出了对CSS类以及ID命名更好的方法。
结构化命名
结构化的标记意味着表达方法/位置信息同内容的完全分离——这其中包括出现在标记（markup）中的类以及id名称。
有标记的相关信息都是用来描述文档的结构而不是外观。这样的特点使得我们可以通过简单的改变CSS的方法来对不1样外观格式下的内容（content）以及标记（markup）进行重用。当你理解这种方法时，非常容易就可以发现采用页面位置来为类以及id命名的方法在处理如音频（audio）等外观格式上显得非常不合适。因此，应当根据在文档中的使用目的而非出现位置来对类以及id进行结构化命名。
可以按照如下所示的结构化方法来对类以及id名称命名之
branding
main之nav
subnav
main之content
sidebar
这些名字同直观命名方法1样非常易懂，但他们描述了页面元素的作用而非位置。这使得代码更加符合使用纯粹的结构化标记（structural markup）的初衷，即开发人员可以在不改变标记的情况下对各种各样媒体下的显示格式进行处理。
即使你不打算在其他的媒体上对Web页面进行格式修改，使用结构化命名方法还可以帮助你在日后的站点升级或重新设计中更为轻松。例如，结构化命名避免了当1个div同id right之column移动到页面左边后所带来的混乱。对div sidebar的采用这样的命名方法就显得更加适当，因为无论它出现在页面的哪1边，这个名字仍然对开发人员来说直观易懂。
惯例
Andy Clarke分析了40份由推崇标准化Web设计理念的开发人员所设计的Web站点的源代码。尽管类以及id名称非常不统1，但是还是发现了1些频繁出现的常用名称。这里给出了最常用类/id名称的示例列表之
header
content
nav
sidebar
footer
如果要查看完整的列表，可以看看最常见命名惯例表
这些常见的类以及id名称是不是标志着1种标准的诞生或是普遍接受惯例的形成呢？尽管这是我所希望的，但我并不这么认为。我的确希望能够看见1整套对于我们每天都可以看到的常用页面元素的命名标准。同时，使用标准化的命名方法可以使得寻找页面元素以及对Web站点升级带来方便，尤其当需求在由不1样开发人员在不1样时间所开发站点中换来换去工作的时候。
