最近和一程序员合作项目。弄的我头都大了~埋怨我的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
常用标签:
（本文来源于图老师网站，更多请访问https://m.tulaoshi.com/webkaifa/）div:主要用于布局，分割页面的结构
ul/ol:用于无序/有序列表
span:没有特殊的意义，可以用作排版的辅助
h1-h6:标题
h1-h6 根据重要性依次递减
（本文来源于图老师网站，更多请访问https://m.tulaoshi.com/webkaifa/）h1位最重要的标题
label:为了使你的表单更有亲和力而且还能辅助表单排版的好东西
以下是引用片段：
label for="user-password"密 码/label
input type="password" name="password" id="user-password" /
(XHTML 1.0 Strict 下不能通过，可以使用"p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre",
"address", "fieldset", "ins", "del" )
dl dd dt 定义列表,当页面中出现第一行为类似标题/简述，然后下面为详细描述的内容时应该使用该标签
以下是引用片段：
dl
dt猫
dd一种可供饲养的小宠物。
dt蜥蜴
dd通常可在干燥区域发现的爬行动物。
/dl
