最近和一程序员合作项目。弄的我头都大了~埋怨我的CSS命名看不懂~得按照他的来。结果我打开他的页面，看了看,从头第一个开始就是contentCommon，下面全部是content****. 我说明了我的理由，过了半会，似乎是接受了，却突然来一句:“不要用H标签嘛!还有不要用UL来定义导航等“。对于很多合作过的程序员，大多都是这样，命名规范大多是自成一派。对于制造标准更是视而不见。抱着只照顾IE正常浏览的态度叫嚣着”让FIREFOX和SAFARI见鬼去吧!”

　　命名全部使用小写字母，如果需求多个单词，单词间使用“-”分隔，比如content-title

　　直观命名

　　当在设计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的采用这样的命名方式就显得愈加适当，由于无论它出如今页面的哪一边，这个名字仍然对开发人员来说直观易懂。

　　惯例

　　最常用类/id名称的示例列表:

• header
• content
• nav
• sidebar
• footer

　　常用标签:

　　div:次要用于规划，分割页面的结构

　　ul/ol:用于无序/有序列表

　　span:没有特殊的意义，可以用作排版的辅助

　　h1-h6:标题

　　h1-h6 依据重要性顺次递减

　　h1位最重要的标题

　　label:为了使你的表单更有亲和力而且还能辅助表单排版的好东西

　　(XHTML 1.0 Strict 下不能通过，可以使用"p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre",

　　"address", "fieldset", "ins", "del" )

　　dl dd dt 定义列表,当页面中出现第一行为类似标题/简述，然后下面为详细描述的内容时应该使用该标签