特意上网搜索了一下，关于div，说法很多。

　　把div看成是规划元素这种观点我想是最多的，类似有“用div代替table进行规划”、“实战CSS+DIV规划”等等等等，太多了，还有不少人延用Dreamweaver的定义，称div为层，按Photoshop的层的概念来使用……有朋友干脆就直接称div和span为辅助规划元素。

　　怎样说呢？虽然我很想说对div类似的这种认识是错误的，div不是一个规划元素，没有一个tag是用来规划的，但是我是对的吗？我也不知道。几乎所有人对div的宣传都是规划，不管是‘民间’的还是‘官方’的，但是如果我们找本源，中文中，div是一个结构化标签，是一个块级元素。好吧，我们首先看看div拥有的语义，division（分隔），按语义它的作用是将两个部分分隔开来。然后我们再回到w3去看看怎样定义div和span的：The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content.

　　留意到我上面加粗的一句话了吗？W3可没说是 for layout，而是for structure，是结构！由于分隔从而产生（定义）一个代码结构。我想，结构和规划应该是两个概念吧。或许，由于table确实被用于规划了，所以这种根深蒂固的规划思路又自然而然的转嫁到div上，我曾在很长一段时间里也是这么理解的。但是，如今我要说，这绝对是一个错误并且，这是极度严重的错误！！！这纯粹团体观点团体理解，本人取舍好了。

　　为什么严重？理解的错误直接导致的就是使用的错误。由于如果按照这个思路，把div作为规划元素使用，那么我认为：

　　你永远无法固定xhtml！永远陷在css的怪圈中！永远不会去思考和理解结构！永远擦不干净table烙下的痕迹！永远无法接近神（貌合神离的神哈，呵呵）……

　　或许把div称为规划元素还是为了更好的推行标准，但是却将人们从一个错误带向了另一个错误。两年前我刚接触标准时就在《重构之美》首篇中迷惑过关于改版的事情，虽然随着理解的深入好像有了突破，在我写下xhtml后不变动，然后通过css的技巧来完成新版面。比如像著名的csszengarden。但是很快我又有新的迷惑，一团体这样做好像没什么问题，团队呢？比如如果同样的内容，设计成两个版式，然后交给不同的两团体来写xhtml，会一样吗？就像如果把csszengarden的方式颠倒一下，基于同一份数据先做好100个设计稿，让100团体按照这个设计稿写100份xhtml，会一样吗？我想按照div规划模式，对于同样的版式，不同人不同的页面分析都会产生不同的xhtml，更何况不同的版式呢？但是既然表现与结构无关，那么同样的内容不应该有2份以上的xhtml。不要小看这个问题，对于团队中前后台的无效分离与快速协同，这是关键！我在培训中提出一个观点：最理想的境界是前台闭着眼睛都能知道后台输出的是什么样的xhtml结构代码。那么问题出在哪里？div规划！尤其是在理解了h系列标签不合理之后，体会更深刻。

　　上篇文章我提出的关于结构该当分为两种：语义结构和代码结构。理解了这两个结构之后，那么div的用途就比较明朗了，稍稍动动脑筋就能想到，用于组织代码结构。所以hx标签的问题我认为经典呢，不要说html了，即便对于xhtml，大部分的人关怀的仍是如何表现，小部分人关怀语义结构，很少人去关怀代码结构，似乎xml有了，xhtml就不需求代码结构了。但是从hx系列的问题可以看出并延伸知道W3可不断在关怀代码结构，从1.0，1.1直到2.0，不断希望xhtml拥有xml般严谨的代码结构。说到这里再多看xhtml 2.0的另一个变化，br不再被推荐，应该很好理解了，br的语义是产生一个截断（break），但实际作用是产生一个行，语义结构上仍不完满，所以使用line进行替代<line>this is one line</line>。同样br也无代码结构可言，如果我想提取第三行的数据如何操作？所以很有可能类似br、hr这类标签都将被废弃。我揣摩着，xhtml1.x是W3清理表现，将人们往语义结构[Semantic]的方向牵引，而xhtml 2.0则是展现和突出代码结构[structure]。呵呵，您说我揣摩得对吗？瞎猜瞎猜。^_^

　　回过头来，那么怎样组织？首先对于一个设计稿，一定要不被设计所迷惑和左右，只提取看得见和看不见的数据，然后就扔掉设计稿，先完成数据的语义结构，再添加代码结构（adding structure to documents.），完成xhtml后，最后一步才是重新拾起设计稿打开css，还原。当然实际做的时候不可能不看设计稿，但是怎样看？只提数据！再说一点，数据在文档中的先后顺序由什么定？当然是由文档而定，不是由设计稿所定。举个例子，假如有两个栏目，旧事头条和普通旧事。谁在前谁在后，很显然在文档中应该是头条在前普通在后，这是由UE（用户体验）和栏目轻重的综合考虑决定。但是按照div规划的话，是按照设计稿上前下后左前右后的顺序来决定的，那么如果设计稿中将普通旧事栏目设计在左栏，头条设计在中栏，文档中普通旧事就跑到头条旧事上面去了。所以我打开一个Web标准站点文档浏览，如果文档的先后顺序是按照页面规划上前下后，左前右后的顺序而定的，那么我……特例一点，如果一个单屏设计的网站，标题和导航设计在页面下方，那你的文档岂不是最下面才是标题和导航，这是什么UE？这不是扯蛋嘛。div，div规划的恶果——文档结构仍然在为表现所左右！貌合神离！！

　　代码结构怎样做？大处按照上篇文章所写，用h系列划分大结构。那么小处呢？这里就要牵涉进div的另外一个概念：块级元素。什么块？模块！用div模块化小处。举例：

<div>
    <h3><span>用户登陆</span></h3>
    <div>
       <label for="name">用户名</label>
       <input id="name" />
    </div>
    <div>
        <label for="pw">密码</label>
        <input id="pw" />
    </div>
    <p><button /></p>
</div>

　　这个在[复杂表单]中提到过的例子，我们来详细分析div在小处如何模块化运用。其实很简单，h3/lable/p是语义结构，然后，对于用户名和相应的输入框显然是不可分割的全体，那么好了，div将其标识为一个块，对应的密码部分同理。最后，两者一同与标题和按钮又构成一个不可分割的登陆全体，div之。这样拥有很好的语义结构和代码结构。好的代码结构不只仅可以便于固定xhtml，便于程序操作节点，还对css提供了很高的自在度。如上例结构，我只需求给最外div一个class，比如"loginarea"。那么：

　　我可以这么按节点/路径层层定义下去：.loginarea label{} .loginarea input{} .loginarea div label{} .loginarea div input。如果我需求横向登陆，只需求定义一个关键点：.loginarea div{float: left}，如果纵向则去掉这个关键点，模块化的登陆就这么简单。这样还可以省写不少class，尤其对于有些看似复杂的结构其实模块化设计好了，模块内部是简单的，一个路径定义过去，基本无需class还不会惹起款式冲突和干扰，css的可读性也很好。当然这里会涉及到css的技巧，我认为css的技巧最重要的就是分析页面，页面分析的好，写出来的css简单明了充分利用tag还有多以备扩展，否则class一大堆复杂冗长还会觉得tag不够用又去添加破坏结构。复杂表单那套系统的css我写了48k，还未做最后优化，全部图片总共只要5K，还全是无损PNG格式。整套系统几十个大模块