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页面以及需求对一个div进行标识的时候，最自然的想法就是使用可以描述元素所在页面位置的词汇来对其命名。这种方法使得类以及id的名称如下面所示：

top-panel

horizontal-nav

left-side

center-column

right-col

这些是CSS以及XHTML类和id的无效命名方式。这些词汇简单并且能够使人顾名思义，因此满足了标识页面元素以及相应的CSS款式的需求。

但问题是这样的名称同页面内容的特定表达方式相关联。这些命名参考了某种特定页面规划中的页面元素位置，因此在这样的规划之外使用就会显得不合适甚至形成理解混乱。同时，这些命名没有涉及文档内容的结构。因此，下面给出了对CSS类以及ID命名更好的方法。

结构化命名

结构化的标记意味着表达方式/位置信息同内容的完全分离——这其中包括出如今标记（markup）中的类和id名称。

有标记的相关信息都是用来描述文档的结构而不是外观。这样的特点使得我们可以通过简单的改变CSS的方式来对不同外观格式下的内容（content）以及标记（markup）进行重用。当你理解这种方式时，很容易就可以发现采用页面位置来为类以及id命名的方式在处理如音频（audio）等外观格式上显得非常不合适。因此，该当依据在文档中的使用目的而非出现位置来对类以及id进行结构化命名。

可以按照如下所示的结构化方式来对类以及id名称命名：

branding

main-nav

subnav

main-content

sidebar

这些名字同直观命名方式一样非常易懂，但他们描述了页面元素的作用而非位置。这使得代码愈加符合使用纯粹的结构化标记（structural markup）的初衷，即开发人员可以在不改变标记的情况下对各种各样媒体下的显示格式进行处理。

即便你不打算在其他的媒体上对Web页面进行格式修正，使用结构化命名方式还可以协助你在日后的站点升级或重新设计中更为轻松。例如，结构化命名避免了当一个div同id right-column挪动到页面左边后所带来的混乱。对div sidebar的采用这样的命名方式就显得愈加适当，由于无论它出如今页面的哪一边，这个名字仍然对开发人员来说直观易懂。

惯例

Andy Clarke分析了40份由推崇标准化Web设计理念的开发人员所设计的Web站点的源代码。虽然类以及id名称很不统一，但是还是发现了一些频繁出现的常用名称。这里给出了最常用类/id名称的示例列表：
 
header

content

nav

sidebar

footer

如果要查看完整的列表，可以看看最常见命名惯例表

这些常见的类以及id名称能否标志着一种标准的诞生或是普遍接受惯例的构成呢？虽然这是我所希望的，但我并不这么认为。我的确希望能够看见一整套对于我们每天都可以看到的常用页面元素的命名标准。同时，使用标准化的命名方式可以使得寻觅页面元素以及对Web站点升级带来方便，尤其当需求在由不同开发人员在不同时间所开发站点中换来换去任务的时候。