在北方每当春回大地，丁香花便不甘寂寞，也会兴致匆匆竟相开放，把他那扑扑幽香……丁香花色繁多有紫色，红色，白色等在没有梅雨的六月里散发着香水般芳菲的气息。天坛公园有个丁香林，置身其中，人真会有些要被花香熏晕的感觉多么忧郁的花。多么娇嫩的花。院子里栽满丁香花。开满紫色美丽的鲜花。丁香花小，一簇一簇的，有白有紫，路边的丁香花已孕育花苞，树下围了不少人指着花苞吵吵嚷嚷，别着急呀，只等春雷一响就会竞相绽放。
Web开发者（也就是您）可以通过创建CSS类及id名称并使用这些名称来对Div以及其他的页面元素、标签进行标识。对开发人员来说，在命名重新定义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站点升级带来方便，尤其当需要在由不同开发人员在不同时间所开发站点中换来换去工作的时候。
到此这篇关于思考Web站点设计对类以及id的命名方式就介绍到这了。人生之间，有些偶遇，因为行色匆匆，我们擦肩而过；有些机缘，因为缺少珍惜，我们失之交臂。有时由于任性，我们错失了一段光华；有时太过冲动，我们错过了一生的相守。有些人，因为陪你走的时间长了，你便淡然了，漠视了，其实是他们给你撑起了生命的天空；有些人，分开了，就忘了吧，残缺是一种大美。更多相关思考Web站点设计对类以及id的命名方式内容请查看相关栏目，小编编辑不易，再次感谢大家的支持！
