重构之美－走在Web标准化设计的路上

最近突然遭遇许多复杂表单，于是干上了。

一直有种说法：table用于数据表，对于复杂表单，table也是最好的选择，由于一直没有遇见过也就没有认真去研究，到底复杂表单是否应该使用table。

好了，机会来了，我拿着复杂表单的图样，看来看去都觉得不应该用table呀，除非是有行标和列标的数据表表单。反而类似于登陆这种简单表单，我倒是一直使用table，理由是能够在纯文档的时候对齐文本与输入框，但是对于复杂表单就不一样了，复杂表单涉及到页面布局了。

为什么要研究？因为我希望程序员不要涉及到界面的任何部分，对于页面，他只需要关注结构，而复杂表单如果采用table，很容易就将程序员带进对布局的操作中去。

好，经过一阵艰苦奋斗，还算好，xhtml部分自己觉得还算摸清了一些规律，页面的分析信手捻来，div结构下的复杂表单真是漂亮，但是但是…… css部分……我靠，真是难搞，干了几个复杂表单的css都没摸清规律，太JB麻烦了，尤其是文本长度不一致，表单控件又各种各样交错，还有错误提示隐藏的文本，时不时中间又加个按钮……迷茫了……算了，继续干css，希望最后能得出结论，对于复杂表单到底用table还是div?

先给一个对于登陆界面这样简单的表单，我最常用的xhtml代码，使用table，理由见上：

另外不使用table的如下：

怎么说呢？第一种我视这样的简单表单为2行2列数据，用了table。第二种则是div模块化操作。一般我都使用第一种，除非文本长度一样（比如姓名，密码）才用第二种。当然我觉得第二种是正确的，所以我会优先在文案上先做文章使之长度一致。为什么？因为只有模块化，才能固定xhtml而通过css 随意布局，比如形式上为一行四列之时，第一种就做不到（其实FF可以正确解释对tr的浮动操作，例如2列tr，但是ie不支持，一个tr怎么都得占 table的一行。）。

好了，复杂表单的图样和xhtml部分在公司，明天上班发上，现在睡觉问梦去。

这份表单够份量不？

这里是xhtml部分，做了些必要的删除，没破坏结构就好了。留意我补充的部分，比如h2、h3。

<h1>大便蛔虫的表单标题</h1>
<div>
    <h2>导航</h2>
    <div>
        <button>新增</button>
        <button>刷新</button>
    </div>
    <div>
        <h3>当前批次采用的标准为</h3>
        <div>
            <label>本人补贴</label>
            <asp:label id="" Runat="server"></asp:label>
        </div>
        <div>
            <label>本人工龄补贴</label>
            <asp:label id="" Runat="server"></asp:label>
        </div>
        <div>
            <label>配偶补贴</label>
            <asp:label id="" Runat="server"></asp:label>
        </div>
        <div>
            <label>配偶工龄补贴</label>
            <asp:label id="" Runat="server"></asp:label>
        </div>
        <div>
            <label>特殊补贴</label>
            <asp:label id="" Runat="server"></asp:label>
        </div>
    </div>
    <iewc:treeview id="" ExpandLevel="1" runat="server" AutoPostBack="True"></iewc:treeview>
</div>
<div>
    <h2>表单内容</h2>
    <div>
        <h3>申请人信息</h3>
        <div>
            <label>本人姓名</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>身份证号码</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>本人工龄（年）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
            <asp:regularexpressionvalidator id="REVY" runat="server" Display="Dynamic" ValidationExpression="\d{0,2}" ErrorMessage="必须输入整数"
        ControlToValidate="txt_WorkAge"></asp:regularexpressionvalidator>
        </div>
        <div>
            <label>工作单位</label>
            <asp:label id="" Runat="server"></asp:label>
        </div>
        <div>
            <label>职务或职称</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
    </div>
    <div class="personinfo">
        <h3>现住房信息</h3>
        <div>
            <label>现住房地址</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>建筑面积（平方米）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>其中个人按市场价自购面积（平方米）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>现住房性质</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>补贴住房面积标准（平方米）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>申请住房补贴理由</label>
            <asp:dropdownlist id="" Runat="server"></asp:dropdownlist>
        </div>
        <div>
            <label>申请住房补贴标准</label>
            <asp:radiobuttonlist id="" runat="server" RepeatDirection="Horizontal">
                <asp:ListItem>无房户一次性补贴</asp:ListItem>
                <asp:ListItem>一次性补面积差</asp:ListItem>
            </asp:radiobuttonlist>
        </div>
    </div>
    <div>
        <h3>配偶信息</h3>
        <div>
            <label>配偶姓名</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>配偶身份证号码</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>配偶工龄</label>
            <asp:textbox id="" Runat="server"></asp:textbox>年
            <asp:regularexpressionvalidator id="" runat="server" Display="Dynamic" ValidationExpression="\d{0,2}" ErrorMessage="必须输入整数"
            ControlToValidate=""></asp:regularexpressionvalidator>
        </div>
        <div>
            <label>配偶工作单位</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>职务或职称：</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
    </div>
    <div>
        <h3>享受住房分配或货币补贴情况</h3>
        <div>
            <label>（１）已享受房改购房面积（平方米）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>（２）已享受购房补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>（３）已享受住房补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <asp:button id="" Text="计算" Runat="server"></asp:button>
            <label>本次补贴面积（平方米）</label>
            <cc1:acceptnumber id="" runat="server"></cc1:acceptnumber>
        </div>
    </div>
    <div>
        <h3>住房补贴</h3>
        <div>
            <label>本人补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>本人工龄补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>配偶补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>配偶工龄补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>特殊补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>合计（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>实际发放补贴（元）</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
    </div>
    <div>
        <h3>请申请人根据不同情况填写</h3>
        <div>
            <label>现购房地址</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>售房单位</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>偿还贷款帐号</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
        <div>
            <label>贷款银行</label>
            <cc1:xmldropdownlist id="" runat="server" XmlNodeName="" XmlPath=""></cc1:xmldropdownlist>
        </div>
        <div>
            <label>本人公积金存储号</label>
            <asp:textbox id="" Runat="server"></asp:textbox>
        </div>
    </div>
    <div>
        <asp:button id="" Text="保存" runat="server" CssClass="button"></asp:button>
        <asp:Button id="" Text="退回" runat="server" CssClass="button"></asp:Button>
        <asp:Button id="" Text="删除" runat="server" CssClass="button"></asp:Button>
        <button id="" onclick="javascript:window.close();">关闭</button>
    </div>
</div>

再补充一个，这里有两个部分很明显的表格结构，所以在那里使用了table，而其他部分没有用。

table部分xhtml。css部分还没琢磨出来规律，结论没有，继续琢磨，不过感觉没有用table结构很漂亮也很灵活，但是css确实让人头大，权衡得失中，再补充了。

..
            <div class="personinfo">
                <h2><span>个人信息</span></h2>
                <div>
                    <h3><span>购房人</span></h3>
                    <table>
                        <tr>
                            <td><span>选择</span></td>
                            <td>姓名</td>
                            <td>性别</td>
                            <td>年龄</td>
                            <td>关系</td>
                            <td>户籍所在地</td>
                        </tr>
                        <tr>
                            <td><input type="checkbox" /></td>
                            <td><select /></td>
                            <td><input /></td>
                            <td><input /></td>
                            <td><select /></td>
                            <td><input /></td>
                        </tr>
                    </table>
                </div>
                <div>
                    <h3><span>家庭成员</span></h3>
                    <table>
                        <tr>
                            <td><span>选择</span></td>
                            <td>姓名</td>
                            <td>性别</td>
                            <td>年龄</td>
                            <td>关系</td>
                            <td>户籍所在地</td>
                            <td>工作单位</td>
                            <td>编辑</td>
                            <td>删除</td>
                        </tr>
                        <tr>
                            <td><input type="checkbox" /></td>
                            <td><select /></td>
                            <td><input /></td>
                            <td><input /></td>
                            <td><input /></td>
                            <td><input /></td>
                            <td><input /></td

一个[复杂表单]热了热身，嗯，好，现在开始逐渐进入状态中……

这个副标题让我琢磨了很久，和之前的“随想随说”不一样，重新命名为《重构之美》后就给了我压力，让我认真对待仔细斟酌，这样其实也好。

2006 2 25 Create

Web标准在概念描述上涵盖了三个部分，结构[xhtml]、表现[css]、交互[DOM、ECMAScript]，准确的定义我就不摘抄凑字数了，百度上google一下，遍地都是。这三个部分我认为并非处于同一个等级，xhtml是最重要的部分是第一级，而css和script则并列处于第二级，简单如下图例：

我认为不要小看了这个认识，我觉得这个目前很多人都没有意识到的问题，即便意识到了，行为上也没有跟上。怎么说呢？script不是我所擅长的，所以我基本上不会涉及到Web标准中交互这部分，即便涉及也只是很浅，个人能力有限。css部分会有针对性的涉及到，但不会很多，因为我不想在css上做太多的文章，因为我感觉现在国内Web标准界对css的追捧有点过了，大小介绍Web标准的网站和书籍主要都是在介绍css的各种技巧，而对于xhtml部分的介绍很少，也就泛泛的提及用div代替table进行布局和书写规则，多一点的会提到语义。

有没有深入的理解过？为什么要严格书写？我想大部分的答案是通过认证。再问，为什么要通过认证？答不出来了？好，再来，那又为什么要严格书写？又是认证？这不扯蛋嘛！鬼大爷管你认证与否。那么严格书写需要吗？不需要吗？靠！再来说语义，说起来估计还有很多“Web标准”者连语义这两个字都不知道。我认为语义是xhtml的两个核心之一，另外一个核心就是今天要谈到的结构。比如对表格table的使用，都是这么说的：表状数据还是要用table标记。那么有没有想过什么样的数据是属于表状数据？我说把一个三栏式布局的页面视为一行三列表状数据行不行？我是在扯蛋，那么什么是表状数据？什么时候用 table？现在网上关于xhtml语义理解的文章真的很少，为什么？css啊，从上到下都追捧css去了，以至于那天我在蓝色理想上见回帖：学div+ css，但不准备遵守xhtml……。类似的还有很多，什么花样都有。无语中，我想每个真正理解了Web标准的人都会很无奈的摇头，近2年Web标准的推广演变为Css的推广。Css很重要吗？不重要吗？靠！我说不要Css行不行？你找一大堆完全合理的理由……“行不行？”“行！”那就对了，我说不要你的 Css，我要他的Css，又行不行？那么和xhtml相比，Css重要在哪里？

最后我们来说说关于“用div代替table进行布局”这种说法，这么说吧，如果你是抱着这种思路使用div，我认为是错误的，布局这个概念其实是 table带来的，如果你又把布局加到对div的理解中去，那么对不起，你还是一个“table者”。最典型的，有位朋友针对我上一篇[复杂表单]评论到：你这个表单看似复杂，其实很简单，不过左右两列式布局，左二右六，……。他还提到了“拼装”两个字，然后说我的代码不过是用div代替table，说我是table思路。看看看看他对页面的分析，“左右两列”，“左二右六”，“拼装”，多么熟悉啊，即便他用div实现了这样的布局，你认为他抛开了 table吗？所以我说他完全没看懂我的代码。我只听说过“不要使用table布局”，没有在很官方的地方看见过“用div代替table进行布局”这种说法，都是人为造出来的，或许是为了更好的推广Web标准，但是现在我们要知道，这种说法是错误的！div从来不是布局元素，也没有哪个标记是布局元素。

像上面的图示，xhtml是根基，表现和交互虽然也很重要，但毕竟可以不要表现，也可以不要交互，但是不能不要xhtml，所以在现在，在现在狂热的追捧Css，几乎达到忽略xhtml这个根基的环境下（比如上面我说的那个回帖），我要站出来，振臂一呼：Css，Stop!（不知道有多少人响应我，鄙视我也欢迎，当我是疯子一笑而过也可以。^_^）

回头看上篇文章，确实有点乱，感觉自己像个愤青，怨妇一样。我的意思是不要过多的把关注投向Css，Css并非Web标准的最核心的东西。我认为 Web标准的核心在从html到xhtml这个看似变化很小确意义非凡的事情上。Web标准更多的是思想的变革，思想的重构，而不是技术，而这一点则几乎全部体现在xhtml上。

菩提树朋友在评论中做了个比喻：

XHTML像是一块白肉,不能吃,就算能吃,吃起来,也是十一分难吃。CSS就是那酱料，沾着吃，才有味，SCRIPT就好比加了一道火，烤一下，再吃，原来，完全不一样。

非常感谢你，这个比喻非常好，不过理解重心不一样。

还是这个比喻，我把xhtml视为牛排好不好？一份牛排好吃与否关键在牛肉本身的品质，其价值也体现在这里。甚至牛肉本身的品质可以好到任何外部因素都显多余，生吃是最好的选择。不知道你喜欢烹饪吗？我比较喜欢。首先要肉好菜好，新鲜，其次才是调料、火候、技巧。一堆好菜，不用费什么功夫就能得到很好的效果，而一堆烂菜，怎么掩饰都掩饰不住本质的缺陷。任何厨师都最重视原材料的筛选，事半功倍。话说回来，生存第一位，所以一块白肉哪怕再难吃也强过调料，没别的意思，只是为了说明轻重，应该首先重视xhtml的品质，其次才是css的技巧。By The Way，我很喜欢吃牛排，而且只要3成熟。^_^

我还是继续说下去吧，或许听完后再回头看，就能理解我为什么说：Css, Stop!并非要否定Css，而是指对Css的过度追捧，Stop。

问题：HTML中的六个标题Tag（h1/h2/h3/h4/h5/h6），设计是否合理？理由？解决办法？

这是我在培训中提出的两个问题之一，不知道大家有没有考虑过？或许你要说这个不是我们该考虑的问题，这个是W3的工作。我承认，其实我最初也没主动去考虑过，直到有一天接触了xhtml2.0，我才知道h系列标题的设计是不合理的，在xhtml2.0中，不推荐使用<hx>系列Tag，理由是结构不好，推荐使用这样更合理的结构进行代替：

嗯，好像答案都有了，不合理，结构不好，解决如上。其实我想问的是为什么hx系列结构不好？为什么要这样改？现在你先别急着向下看，试试想想。

琢磨这个问题是因为我想试着去理解W3到底想干什么？现在我们清楚了为什么在xhtml1.1中不认可类似font之类的Tag，xhtml1.1 是2001年的产物，如果当时我们就理解了，那么Web标准早就推广开来了。现在W3如法炮制，在2.0中不推荐现有的h系列Tag，那么会不会在 “2.1”中完全抛弃它，如同抛弃font一样。xhtml2.0尚处于草稿和提议当中，还未被W3正式推荐。当然我无意从中引出Web大标准、超标准之类的东西，我只是希望能对目前的Web标准加深理解有所帮助，实际上我认为我得到了较大启发或者说之前的一些模糊的，不确定的感觉变清晰了，所以我认为这是一个对于目前Web标准非常经典的问题。

好，现在说说我的理解。

首先我们想想h1/h2/h3/h4/h5/h6这六个Tag是什么东西，当然是标题Tag。它们有什么不同？h1页面唯一（一个页面只能存在一个 h1），并且字体最大。h2~h6可以多个，字体逐步减小。曾经有个朋友说他认为h系列都是和表现相关的东西，有可能在以后的xhtml中被删除，所以他从来不用也搞不懂为什么那么多人用。其实他搞错了开头，却猜中了结局。确实已经在2.0中不被推荐，却不是因为表现而是因为结构。不知道还有没有人和他有同样看法？h系列绝对不是类似font的表现Tag，如果因为粗体和大小就算的话，那么所有标签都属于表现标签了，ul还有点，ol还有数字呢，p有间距，div会换行，……那么还需要xhtml干嘛呢？直接XML好了。

xml里的X是指可扩展，也就是可以随意定制标签。而xhtml中的X虽然也叫Extensible可扩展，但是并非可扩展，你不能为xhtml自定义标签，它更多是指xml化，也就是xml化的html。所以，xhtml每个标签都需要有默认的样式来支撑它的语义化，这些样式是最基础的样式，为什么h1和h2不一样？因为它们默认样式不一样。为什么2个div会形成2行，而2个span却在一行上？因为div默认一个display:block的样式。具体的大家有兴趣可以查一下。好了，hx系列Tag的不合理就出在这里，语义和结构。h1~h6的语义通通都是一样的，那就是标题。他们之间有没有结构？有的。同样的语义却设计了6个Tag，为什么？因为结构的存在。hx系列之间的结构（节，俗点叫上下级关系）是靠123456（不同的默认样式来决定），但是这些数字并没有语义的，你说1大还是6大？不同的环境下截然相反，人的判断都如此，作为程序是无法理解凭什么2就是1的子级，3就是2的子级。再有，假如一篇极端的文档需要用到h7，h8……怎么办呢？所以有了以上的改变，语义用h表示，把结构分离出来用section表示，这样一来，程序喜欢不喜欢，我想不用多说了。^_^

2006 2 27 Create

很久以前，我第一次看到IBM网站上《Web 的未来：XHTML 2.0》这篇译文时，第一个反应是怎么把标题Tag搞得这么复杂，再定睛一看，马上就联想到自己的迷惑和一直在追求的东西，真的立刻就有一种醍醐灌顶、豁然开朗、近视眼带上眼镜的感觉。其实早在一年多前，我就有过这样的迷惑：如何固定xhtml文档？后来还在重构之美－迎接Web标准化设计的来临[总结一：网页设计回归？]中对这个问题曾做过这样的总结：

...2、根据规划完成XHTML文档，组织好文档结构，设计纯文档。这里我要提醒，纯文档同样具有UE，它只是没有了UI而已，所以需要仔细推敲标记的选用并确定下最简洁的XHTML文档。...4、根据设计稿为XHTML文档添加样式进行还原，通过样式表的设计技巧尽可能的不修改XHTML，如果UI 实在是复杂，则可以在不影响XHTML文档结构的情况下加入一些额外的标记或者进行一些嵌套。...

可以看到当时的我其实是迷惑的，怎样选用标记？怎样的xhtml文档最简洁又灵活？我一直在努力，去始终好像很难找到一个方法固定xhtml。对于一个页面，不同的人有不同的分析，不同的分析又将产生不同的xhtml文档。哪怕两人在不加载样式表情况下设计出浏览界面完全一样的页面，背后也可能因为分析的不同是两份不同结构的xhtml，也就是语义一样，但结构不一样。语义含有部分结构的概念，却不等于是结构。

~~现在举个例子吧，可能都希望看见实例。下面这个图很简单，大家先试试写出xhtml来，如果懒，构思一下也好。~~

2006 2 28 Update

很早就开始关心纯文档的结构，从最初的关注浏览器中xhtml的浏览结构，慢慢也开始关注xhtml的代码结构。简单说明一下这两个结构吧，希望大家能够多关注一下浏览结构，更多关注一下代码结构，而不是仅仅把目光注视在应用了css后的最终页面效果上。比如：

这段代码的浏览效果如下：

我们可以看到，浏览已经完整了，有了结构，这种结构是通过语义而产生，然而代码结构完整吗？所以我说过，语义带有部分结构的含义，却不等于结构。完整的代码结构我认为如下：

<h1>文档名</h1>
<div>
    <h2>标题1</h2>
    <div>
        <h3>标题1.1</h3>
        <h3>标题1.2</h3>
        <div>
            <h4>标题1.2.1</h4>
            <h4>标题1.2.2</h4>
        </div>
        <h3>标题1.3</h3>
    </div>
    <h2>标题2</h2>
    <div>
        <h3>标题2.2</h3>
    </div>
</div>
上面的代码还不是很合理，有心的朋友应该能看出来，不过意思到了就好。

这有没有觉得这段代码眼熟？回头看看开头xhtml2.0中推荐的标题表达形式。是的，当我看见xhtml2.0的时候马上想起的就是我的这种写法，然后更加坚定的将这种写法延伸使用下去，并且发现似乎找到了固定xhtml的方法：用标题划分代码结构。这样对于同一个页面，不同的人都能写出同样的xhtml结构。例如，对于大部分页面，都可以视为页头，内容，页脚三部分，那么好了，每个人都能写出一模一样的xhtml大结构，而不管页面具体如何设计的，看看：

或许你会说，这样简单了，那么你可以去看我在[复杂表格]中的几段代码，或者看《粗略整理博客圆的页面Xhtml代码》。统统是这样的结构。

这样写优势太多了，因为它不论在哪一方面都吻合xml的要求，不论在写法上还是结构上，程序会非常喜欢，比如无论通过js还是后台编程，我们都可以很轻松的通过xpath查询提出所有的h3或者任何部分。我想这也是xhtml的目标，让html尽可能的靠向xml。xhtml会代替html，但是我想xml不会代替xhtml，至少在浏览器没变革前，xml没有直接的语义，只有结构。xml的语义需要通过程序或者xsl来转换成有直接语义的 xhtml来体现，关于xml这里就不多说了。这种写法是有缺点的，那就是会感觉h不够用，6个h标签，只有3个可用，h4已经显小。那么当我们的结构层次高于3层或者高于4层的时候就麻烦了，所以开始向往xhtml2.0，可以无限层的表达下去，虽然还不清楚它怎么来区分每个h标签。

这样的写法很接近一个结构很好的Word文档，对，就是以写Word文档的方式来写xhtml页面，固定下来。

好了，现在你理解了吗？认可吗？

下一篇继续深入结构，咱们聊聊关于div和span。

追随lpspider的评论，知道他在《刚要玩玩xhtml就被当头一棒》中迷惑于国外在html和xhtml之间的争论，没来得及细看，不过我认为没有太多争论的。

xhtml1.X一定是html，而html则不一定是xhtml1.X。那么如果说IE不支持xhtml就等于说IE不支持html，不会吧。所以IE不支持xhtml一说不知何来之有，不过IE不完全支持Css倒是真的，但是，但是css是表现，表现和结构是无关的。xhtml的产生正是因为在 html中，表现和结构混为一团，不利于向xml平稳过渡。

如果要说担心，xhtml2.0到值得担心，因为有很多新的东西被加入进来，就需要各浏览器作出相应的支持，不像目前xhtml1.x，浏览器不用变化。但是这种担心或许有点早了，又或许多余了。首先xhtml2.0还处于草案和提议与设计中，而1.X还没有被正确普及开来，时间还长着呢。其次，即便xhtml2.0被确定被推荐，由于不能完全向下兼容，还需要等浏览器跟上节奏，这又是一长段时间。所以完全不用着急，我认为的话，即便xhtml是被视为一种过渡技术，但是仍然有着相当的生命力。

说到这里，想起曾经看过这么一篇文章《了解了XHTML2.0后，有感》（实在找不到原出处），文中最后提出的观点：我的意见是，直接做XML的网页！这样的观点我是不认可的。

再来说表现与结构，老生长谈了，2年前我就推荐过阿捷写得一篇《理解表现与结构相分离》，今天我仍要不遗余力的推荐！文中写出的四个部分，数据，结构，表现，行为。上次我给出一个简单的关系图：

现在我再给出一个更为详细的关系图：

数据和结构是无法分割的整体，脱离了结构的数据几乎不能使用。所以纯数据需要用xhtml或者xml来格式化，展示其结构。具体的阿捷比我说得更清楚。我这里着重谈谈结构。在我的理解里，结构目前划分为两部分，一是语义结构，二是代码结构。语义结构是靠语义产生，代码结构则是面向程序的。XML拥有完美的代码结构，但是却因为高度的可扩展和自定义性，很难拥有语义结构，除非在它的基础上定义一个通用的格式，比如现在很火的RSS。所以在目前通过浏览器上网浏览html的模式下，直接应用xml写网页是无法通用的，也是困难的。而xhtml则是一种折中，它不允许扩展，从而继承html的语义性，拥有现代浏览器都可以识别的语义结构以适应目前互联网应用大环境，同时用xml的规则规范它，让它继承完美的代码结构以便以后顺利过渡。所以我说css相对不重要呢，Web 2.0时代一个标志就是数据跟着用户走，这里的数据当然包括结构，语义结构和代码结构。再说了，css这个东西专心学习，我想一个月足以精通。但是并不代表你页面就能做得很漂亮了，那是设计，和css无关，你敢说1个月精通设计吗？我做了6年设计了，仍觉得欠缺太多，设计难啊！所以从重要性上css比不上 xhtml，从技术含金量上，css比不上设计，呵呵好像把css说得一无是处了，我错了我错了，不要骂我了。

至于所谓的xml+xsl，并不是xhtml＋css的升级版本，xsl的意义在于转换而非控制表现，xml过于开放了，所以需要xsl来转换，将 xml中的语义结构和代码结构转换成不同领域相应的标准结构，比如移动中的WML又或者WEB中的XHTML。所以不要说我要xml+xsl，若你不懂 xhtml，转换出看起来像xhtml的html，貌合神离又有什么意义呢。

最后，我认为xhtml一定会代替html（XHTML is aimed to replace HTML），但是不一定被xml所代替，或者就如上所说，有相当的生命力。xml只有数据和结构，它的语义是面向程序的，而不是面向浏览器。如果要全面xml话，首先使用浏览器浏览网页这种上网模式就一定要先转变，再或者浏览器本身的内核会有较大的改变甚至需要重新设计。这两个都不是一蹴而就的事情，所以xml的意义更多在于桥梁，要作为主体目前还不行，不管作为数据的主体（有数据库）还是结构的主体（有xhtml）。因此即便 xhtml被视为过渡技术，2000年出生以来，经历了1.0，1.1，现在仍然在向2.0发展，直到所有条件成熟，xml能够全面接管过来。而 xhtml的作用就是等到xml能够接管之时，顺利平稳过渡。我个人认为现在谈过渡还早，2003年说99％是过时的，现在呢？2006年了，纠正了多少了？那么，我想，xhtml会再存在3、5年或者更久吧。不过互联网谁又知道呢，也许就在明天一切都变了。

未来不可知，明天太遥远，我们只能有个方向，然后全力把握住今天

特意上网搜索了一下，关于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/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格式。整套系统几十个大模块，又有无限级菜单、树、页签、弹出，复杂表单，合同，frame，iframe，报表，控件套控件等等乱七八糟什么都有，css加图片全部表现部分可以做到50K以内。这个项目四个程序员一起开发我一个人顶所有前台，三个月时间，程序员不管任何有关表现部分，我都是玩玩做做就搞定了。中后期，临着交付客户时候我还觉得公司提供的设计不好，又自己花1天重新设计，花不到2天另外写了一个css，整个系统全变了且以前的设计未丢失。功能不变的情况下界面大换，再大的系统也不过一个人几天时间，且程序员不用管。这就是Web标准的威力之一！（因为是内网应用，所以我几乎没考虑和照顾浏览器兼容性，没必要，也是快的一个因素）

所以我认为当前各大网站上以各种方式事先列出什么单行一列，两行一列诸如此类的几行几列的div＋css布局代码，不好说他们不对，你完全可以去理解是如何使用css实现几行几列的布局，然后合理运用到自己的结构上。但是如果你按照他提供的代码去套、去添加内容，那么你就错了。不过话说回来，在被一篇一篇标题着斗大的“布局”两个字的潜移默化下，您还有心思去关心结构吗？所以很多都去琢磨css了，所以这些善意的Web标准推广者还是有错的，包括我在内，我2004年撰写的《重构之美》代码示例部分带有更大的误导性（好在当初我一再强调代码毫无借鉴的意义，也算在文字上有所弥补）。现在呢？我也不知道，在路上，在路上……

修整一个月，我又回来了，好吧，咱继续聊。

上篇文章中主要否定了使用div进行布局这种说法，提出div应当用于组织代码结构，现在我们再深入一点，div拥有语义吗？这个问题前段时间在研究群里曾激烈争论过，当时米随随发问：“什么是语义化WEB，div是什么？”小毅答曰：“DIV表示无意义容器。”我说：“否定。”然后旁边有人嘀咕：“...又要打起来了。”我大笑着进入战斗状态，结果迅速被围攻了。呵呵，总是和主流格格不入的我又一次站在主流的对立面。我还是不赞成将div视为无意义容器。容器这个概念是模糊的，是与设计挂钩的，理解成容器以后又远离结构了。再说每一个不是自我关闭的标签都可以视为容器，有什么区别？难道div可以包含一切（别断章取义哈），于是就可以随意使用了吗？那又如何固定xhtml？所以还是要回到div的语义上来，div是有语义的，只不过它的语义是面向代码结构的，是面向程序的。

division（分割），对了，前段时间浏览w3schools时，看到它是这样定义div的：The div tag defines a division/section in a document. 我想我对div的理解是没错的。在文档中定义一个分割或者节点。我说div用于模块化页面内容，实际上从代码结构角度是展现xml化的节点结构。除了定义一个节点以外，div目前还用于定义一个分割，产生具有结构的行。还是以登陆为例：

最外层的div是作为产生节点使用，而用户名和密码部分实际上是为了产生具有结构的行，这里若使用br同样能够产生行，但是缺乏结构，所以div代替了br。猜到我要说什么了吗？呵呵，又是xhtml 2.0，2.0中的section和line标签，是的，在1.X中，div同时扮演了section和line的角色，因为分割产生节点，因为分割产生行。但是很明显section和line具有比div更为明确的语义，那么我们可不可以认为div的语义和br一样是模糊的，既然是模糊的，br已经被毙了，我们现在大量使用的div会不会落到同样的下场呢？不知道，至少目前的xhtml 2.0中，div仍然存在。看看上面的结构代码在xhtml 2.0中应该如何展示（没考虑XForm）：

所以有些人单纯的认为好像是div在不断嵌套，其实不是的，是没有办法而产生出来的假象。这里再请大家注意一个情况，需要和css结合起来看待，按钮那个部分，在xhtml1.X中我使用了p，严格说从结构上是错误的，很明显按钮不是一个段落，我仅仅是希望它换行呈现，但是如果使用div，那么就必须给予这个div一个class="button"以区分开来，并且在设定css的时候必须先清除公有的样式属性，这样会带来不少麻烦。另外作为节点的 div和作为行的div同样会出现这种问题。示例：如果我定义节点div{width: 300px; padding: 10px;}，那么我就必须在定义行div时要么覆盖要么清除以避免冲突，div div{width: 200px /*覆盖*/; margin: 10px; padding: 0 /*清除*/; color: #333;}，然后在定义div div.button{margin: 0 /*清除*/; color: #F60 /*覆盖*/; background: #999;}的时候再做对行div的样式冲突避免，为了避免这种情况，采用对节点div增加class="loginarea"和p，这样就可以避开两次样式清除和覆盖操作。这样的情况在结构复杂的页面中更为明显，不要告诉我加class就行了，class越多，文档通用性越差，xhtml越难固定。这就是在xhtml1.X 中因为div的语义模糊带来的麻烦，回头在xhtml 2.0的结构中就很好办了，section{}，section line{}，section div{}，无需class也互不干扰，诶诶诶，这里的div貌似很适合它分隔的语义哈，不是行也不是节点，仅仅就是一个分隔，呵呵。

在我认为标签中最难理解的2个之一的div现在应该算是很清楚了。剩下的一个就是span，至今我仍未能理解到span如何产生结构，只好说说自己的迷惑了。

先还是说说div和span的区别，从大的方面来说，div被归类到Structural Module（结构模块），而span被归类到Text Module（文本模块）。小的方面，div是block-elements（块级元素），span是inline-elements（行内元素）。在所有Structural Module中，div是唯一一个语义模糊的，在所有Text Module中，span也是唯一一个语义模糊的，呵呵，两个Tag唯一的共性：语义模糊。

回到span的语义：跨度、范围。这个这个……比division（分割）更为抽象，难以理解。在一阵疯狂google后还是没找到我想要的那种解释，接近的都没有，也许根本就没有，所有的结果都指向表现，无论中英文都是指为字体添加样式，可是可是W3中明文写着The span element, in conjunction with the id, class and role attributes, offers a generic mechanism for adding structure to documents. 这里的for adding structure to documents做何解释？百思不得其解，后来气不过，甚至打开W3的源码查看他是如何使用span的，虽说获得了一些提示，但依旧不足以领悟到 structure的真谛，我想应该是我的XML功力还不够。唉，既然语义上，结构上行不通，那么只好换个角度，从实际应用中试着去理解。span是行内元素，主要应用于文本，这点没什么异议，关键在于如何运用？为什么我始终不认为span是个样式容器，对，又是容器，google的时候发现清一色的容器解释，div是大容器，span是小容器，我郁闷。如果span因为文本的样式而存在，它凭什么存在？一段文本为什么要添加样式？如果你想强调应该使用 em，如果想特别强调应该使用strong，Text Module里还有很多语义明确的标签可以使用。所以span应该不是作为样式容器而存在，就像div不是作为布局容器而存在一样。但是我领悟不到 span的真谛，哭啊！不过我可以抛砖引玉，在有一个地方，我一定会使用span的。那就是表单中。还是以登陆为例，如果登陆的数据需要展现出来，比如很多edit页面和view页面，结构应该完全相同，不同的是在edit页面中是输入框，而view页面中则用span展现数据。类似如下：

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

这样的好处有两点：1、和label区分开来，便于应用样式，如下定义：div div span{}。2、可以通过节点提取所有录入的数据。这是我目前唯一非常明确的使用span的地方，这里除了span好像没有更合适的了，也有点符合它的语义：范围和结构化。这是我抛出的一块砖头，谁能引出玉来，或者知道玉，求之。其他span的运用仍在摸索中，包括从W3源代码中获得的提示。

差不多要说完了，这时我对关于容器的说法又耿耿于怀了，于是再次以容器为关键词疯狂google，凭什么上上下下都说是容器，我要找出根源来，终于在最后，皇天不负有心人，在我执迷不悟的，怀着容器是错误理解的信念下，挖出来了根源。W3在这里对div和span进行了这样的解释：generic language/style container。两者都一样。哦，原来如此，怪说不得所有的中文翻译都是容器，我想很少人去看英文追根到底吧。确实style container应当翻译为样式容器。这一点都没错，错的是请注意，这是html中的div和span！！！而不是xhtml中的div和span，随即我再查到W3在对xhtml中的div和span的解释，已经不一样了：对于div是Define the characteristics of a block，而对于span是Define characteristics of text。对！这才是我的理解，也是我想要的正确解释！！因为这个是xhtml 2.0中的解释，由于2.0中section的存在，所以在对div的解释中，节点的含义被取消了，xhtml1.x的解释我懒得去找了。现在回头看我刚才试着写下的xhtml 2.0登陆结构中的div和最后一句话。嗯，div即便不做节点也不做行，可能还是有用的。

说到这里，问一句，html和xhtml最大的不同在哪里？是语法吗？是名称吗？是严格了，xml化了吗？不不不，本质区别是：html是面向表现的语言，而xhtml是面向结构的语言！所以我们应当从结构的角度去审视和理解与运用xhtml中的每一个Tag。比如容器的理解，在面向表现的html中，是正确的，但是在面向结构的xhtml 中则错了，应该理解为节点。理解直接影响运用，以表现的理解显然无法写出结构化的代码。否则什么合什么离，哈哈哈，忍不住又敲出来了。

好了，span现在总结不出来，只好先对div做个总结收尾：在当前xhtml1.x环境下，我们需要产生节点（section）和行（line）的时候选用div。

阿弥陀佛，最烦人的两个东西总算告一段落，虽然未完，但是遗憾也是美嘛，以后再说了。结构也算告一段落，下篇可以换个口味了，正式进入语义！

在《复杂表单》一文中我提出了表单的标准化设计思路，但并没有什么个人总结，因为当时我也在权衡揣摩研究以及斟酌判断决策之中。^_^。

在复杂表单上，标准的优势吸引着我，标准的劣势折磨着我。坚持住，几个月后，劣势开始变小，优势如我所预料开始展现出来了。

还是先回到《一个简单又不简单的标准化表单设计实例。》这篇文章来，把它解决了。有个朋友评论的署名是onestab，你的CSS写得干净简洁，但是仍不够漂亮，最重要的，不管你是否真的来自曾经给于我过帮助的OneStap，您还是没有给出正确办法，因为：我的“大便蛔虫的表单主标题”部分到哪里去了？你怎能无视它的存在？没有它就简单了，难就难在它存在，又不能定义在body中也不能为它而改变结构增加Tag。当然我相信多想一下你肯定能想出来。好吧，我来说说看。

首先我很遗憾，竟然没有一个人指出：您的结构不完整。我前面呕心沥血写的文章都白写了，一到实例上大家眼中仍然没有关注结构。是的，有人想过这个问题吗？（当然可能大家都懒得理我，^_^）我记得以前在标准群中提这个问题的时候，小毅第一句话就是：你的结构不完整。仍我怎么解释他都咬死这句话，拒绝继续，气死我的同时还是感到欣慰。我们抛开设计稿，结构中在body和div之间最少都应该有个标题h1来指明这是“大便蛔虫的表单主标题”。“新增联系人”只是模块标题，还需要一个归属，这个模块到底是用在北京WC研究院还是上海WC研究院。这是一个成熟开发平台中发布了的通用组件，在我到来之前就已经存在很久了，作为通用组件，这个主标题应该具备并且动态生成，但是由于在我去之前，把Web标准带去之前，这个公司三十多个程序员都在用传统方式研发和开发，没人关心过结构，所以这个功能一直没有，而要添加的话，引一发动全身，最初我选择的是直接改动ascx，增加h1写死在页面，但是这样的话就降低了组件的重用性和灵活性，尤其是有很多这样的表单。所以我最后选择放弃h1。结构的不完整带来的就是CSS设计的困难，不能按正常思维去完成，我曾有那么几分钟很想把h1添加上去，但是最终还是从css上找到了办法。可以留意一下我是怎么分析页面的？Css设计唯一的难点是结合结构分析页面，而table不一样，按照设计稿切分表格就是了，当然table也有页面分析，分析的好嵌套少，想省事，那么就使劲嵌套吧，所以传统的table制作手段只有还原没有设计。而我在做Css设计的时候，10分钟会有8分钟用来对着电脑发呆，单个页面的分析，整个站点的分析，整体设计的分析。……打住，跑题了，说远了，回来回来。汗……

没有h1的难点在于主标题图片放在哪里？边框怎么解决？
1、主标题如果放在body中，那么为了避免冲突，必须给每个这样的页面的body增加class，麻烦。
2、如果主标题放在div中，左右边框怎么办？如果把边框做成图片定死，那么怎么适应分辨率？又或者用内部的div来拼凑边框，问题更大。
怎么办，走头无路的时候，反向思维！其实就是乱想。我们还有一个Tag可用，那就是h3。
1、把“大便蛔虫的表单主标题”这张图片定义到h3中去，看似违背常规设计思路，却解决了问题！
2、给div样式margin-top和body拉开距离，然后用相对于div的绝对定位使h3飘起来去填充拉开的距离以定位图片标题。
3、再给h3样式padding-top定位“新增联系人”字体的位置，而“新增联系人”下面的渐变背景则定义在div中repeat-x。
4、最后给div样式padding-top使表单内容在渐变下方。搞定！^_^
其实如果静心分析，可以一下就出来了。要实现自适应边框一定不能用图片实现，只能用div定义边框，因为表单内容会变，所以不能使用第三层的div拼凑边框。主标题在边框外，正常设计下，这就意味着div外需要tag，而目前div外只有不能使用的body，那么要解决这个问题唯一的办法就是从h3身上想，h3能否跑到div外面去？可以！绝对定位。看，分析完了也就做完了。这种手法有一点类似我在《Web标准下，OA系统常见左栏定宽，右栏自适应宽度的“爆（牙齿）力解决法”。》一文中的手法。活用绝对定位，跳出常规设计思维。所以我说我发错地方了，这里大部分人都是程序员，对Css的设计并不擅长也没必要，要解决这个问题不仅必须对Css很熟悉，还要思维灵活，敢于胡思八道。关键是要能对着设计稿使劲发呆，脑袋高速运转，从上到下，各角度去分析页面、站点、整体设计……，而不是急急忙忙的动手。你思想站的高度将决定手中活的容度。

好了，关键样式在下面，完整的我打了个包——Web Standards Form Example.rar

*
{
    top: 0;
    left: 0;
    margin: 0;
    padding: 0;
    font: normal 12px "宋体";
}
body{background: #AEB4C5;}
input{} /*全局输入框*/
.buttonarea input{} /*全局按钮*/

#PopPage /*相对定位*/
{
    position: relative;
    width: 98%;
    margin: auto;
    margin-top: 50px;
    padding-top: 45px;
    text-align: center;
    border: 1px solid #FFF;
    background: url(bg_02.png) repeat-x #F2F3F8;
}
#PopPage h3 /*绝对定位*/
{
    position: absolute;
    top: -50px;
    width: 100%;
    padding-top: 60px;
    background: url(bg_01.png) center 10px no-repeat;
}
#PopPage div /*定宽浮动*/
{
    float: left;
    width: 295px;
}
#PopPage div label,
#PopPage div input{float: left;}
#PopPage div label
{
    width: 75px;
    text-align: right;
}
#PopPage div.buttonarea
{
    clear: left;
    width: 100%;
    background: url(bg_04.png) repeat-x;
}
#PopPage div.buttonarea input{float: none;} /*弹出表单按钮浮动清除*/

自适应自己下载去试试，1024、1280都可以，我给出这个固定宽度的弹出窗口最终设计效果如下：

1024图
 1280图

The End？结束了吗？没有，小小的例子可以引出很多东西来，慢慢来说。

我想大家肯定是有很多疑问的，说不定看了设计效果会有不少人骂到：靠，晃点我，明显和设计稿不一样嘛！文字中间的间距呢？输入框长度也不对啊！等等等等……我笑笑，说：凭什么要和设计稿完全一样！

说了这句话，我也静了一下。程序和设计是两条截然不同的路，设计是感性思维，而程序是理性思维。两者全通的人很少很少。所以作为程序员一般而言是没有资格去否定设计的，作为设计师也没有资格去否定程序，问题就出来这里：那么制作谁来做？我从一开始进入互联网就不认为设计和制作是可以分开的，就算在 table布局时代，一个优秀的设计师完成设计稿后其实制作已经完成，因为设计时就已经充分考虑的制作（如何切图），精确到像素，脱离设计稿靠记忆都能迅速把表格准确切分出来（当然很多的所谓设计师只是随心所欲的在画画根本不考虑制作，所以被称为美工）。一个优秀设计师的设计稿绝对不仅仅就是一张图，它还涵盖了很多理念在里面（UI，UE，交互等等），到底有多少在于这个设计师对网页这个词的理解深度。你说平面设计师能不去考虑印刷吗？他在做设计的时候虽然不用考虑制作但必须考虑印刷的限制。对于平面设计师，他的设计水平不是设计稿，是印刷后的效果，同样对于网页设计师，设计水平体现在已经成形的网页上，网站设计师范围更大，网站的整体。设计稿算个屁啊！凸！你去问问室内设计的效果图算什么，有多少价值？一个室内设计师如果不知道材料和施工，只会玩3DS MARKS把效果图做得天花乱坠而又实现不了，狗屁。上面的例子，如果设计稿是我做的，我压根就不会把标题放在外面，或者不会选择这种表现形式来进行设计，我会充分考虑如何通过设计来降低制作的难度从而优化制作。还有，文字的间距，此类表单，如果文字无规律可寻，我也不会这么去设计，间距是表现是排版的一种手法（说到这里，既然间距是表现也应当写进Css，所以提醒大家，Web标准下，不要随便使用空格。空格不是办法，有本事用空格把4个字和5个字对齐，^O^！只有Css才能做到）。文案如果不能做到有规律可寻，那么就不该设计间距，否则给予Css设计很大难度，要在xhtml中增加很多无谓的 class，还要一个一个定义，不是做不到而是很不值得。请搞清楚一件事，要做的不是Css还原，而是Css设计！哎呀，不说了，严重跑题，以后再详细阐述Web标准下的分工与协同。对了，大家别看了这段话就去和自己的设计师们叫板哈，那我就成罪人了，除非你自信自己对设计的理解比他们深，否则还是请尊重设计稿。

还是回到这篇文章的目的：复杂表单可以标准化吗？应该标准化吗？第一个问题有答案了，可以。那么应该吗？这个分歧点很大，有几个人赞成的请举手……好吧，呵呵，拿我的名字分两方面来论证一下。

求证：理论上来说，复杂表单应该使用table进行设计吗？

郑旻：（^_^）: 如果用table来处理上面的例子，表单部分很明显是4列多行数据。但是它是吗？table是表格是吧，什么是表格？数据库应该是最好的表格了吧，像上面的例子，怎么在数据库中定义字段？当只有一条记录的时候，我们把数据库的行当列，列当行，字段作为值，它是一个2列多行的表，而不是4 列。为什么会产生4 列？那是因为表现的需要，或许我还会设计成三列的显示，再或许我希望它随分辨率的变动自适应。你的数据库中会设计多个重复的字段吗？所以，复杂表单虽然带个“表”字，但是大部分都是伪表格数据，为什么不是全部，还是有部分表单是真表格表单，类似DataGrid在线编辑模式下的那种。好了，论证完毕。

求证：实践中，效率上，复杂表单应该使用table进行设计吗？

郑旻：（哈哈，我又来了）: 这个我想是大家最关心的事情。怎么说呢？这个是Web标准的特性：对于个人，尤其对于单个页面，用标准设计的速度永远比不上table的可视化设计速度。页面设计如此，表单设计同样如此。我记忆犹新，两年前，我在《重构之美－迎接Web标准化设计的来临[总结一：网页设计回归？]》中对标准的速度做过如下总结：

3、关于速度和效率的问题。
　　很多人都在想这个问题，被这个问题所困扰。cloudchen曾经回复过我这么一句话：网页就象快餐，在这种东西上面浪费时间不值。我深以为是，速度是非常重要的。但是我要说的是，如果使用标准，对于网站来说，开发速度会比使用表格快N倍。从单个页面来开，使用标准再熟练再快我承认都快不过表格，说不定差距还会很大。但是对于网站来说就不一样了，随着网站规模的扩大，差距会缩小，到某个临界点时，两者会持平，而后使用WEB标准的网站在开发速度和效率上会将表格远远抛在后面。所以对于小网站，小应用来说，使用标准在速度上是完全没有优势甚至会有明显劣势，但是对于一个大网站，尤其是非一次性开发而是持续性不断开发的网站来说，呵呵，不用我说了吧。我使用表格5年，我的表格设计速度可以说已经练到极为准确和快速了，几乎无法再大幅度提升了，而我使用标准才 2、3个月，我有这样的体会，你做何选择？
今天我把它从坟墓里抓出来同样说到表单设计上，是的，对于团队，对于大量的表单，标准化后的优势不是一丁一点的，是淋漓尽致的凸现。我不止一次的说过和认为： Web标准从一个方面上讲是一项为团队而生的技术和标准！回到上例吧，先给一张图片，这个是我让程序员整理的该项目需要设计的弹出表单列表，先看看，数数，再看看旁边的下拉……。

感受如何？我有两个感受：第一站在传统的角度，我也是从传统过来的，我感到可怕。第二很庆幸标准的出现和我两年来的应用积累成精了，100个表单页面，就算斩一半也有近50，我们所有的程序员都解脱了，所有表现全部压在我头上，我一点都不怕，虽然依旧麻烦，但是相比之下，对于团队已是数量级的效率提升了。而且Web标准的高灵活性、高重用性和对未来的高度适用性等所有优势将驻留在标准化下的表单中，为未来带来极大的便利。

最后，当你的系统、网站页面全部标准化了，但是每个表单之处仍然table化，那么它将成为水桶的最短的那块板，不断的卡住你。还有什么疑问吗？那么我下结论罗，^_^。

结论一：理论上来说，复杂表单应该使用table进行设计吗？回答是：NO!

结论二：实践中，效率上，复杂表单应该使用table进行设计吗？回答仍是：NO!

不要说这个表单简单了，复杂了一样的，想想最初的标准只是在很简单的页面上实验，最简单的页面－博客－个人网站－门户网站，一路走来，发现其实复杂页面也没什么大不了（当然现在很多标准化过的网站实际上很烂），我的意思是表单同样如此，不在于它简单还是复杂，关键的关键还是在于结构化和语义化，表单是不是该用table来做？那么table到底该怎么用？

首先，大家儿童节快乐，我要去买份儿童套餐来温习温习。^_^

问题：XHTML中的列表Tag（ul/ol）和表格Tag（table）区别何在？对于单列多行下的数据表，如何判断和选择？

这是我在培训中提的第二个问题。如果说上一个问题“理解h系列的不合理”能够把人带入对结构，代码结构的思考中，那么这第二个问题我认为则是把人带进对语义，语义结构的思考中。

说到标题“深入语义”，其实并不是从现在才开始的，大家应该发现在之前的文章中，我总是会回到语义这个点上去展开思路，论述结构。关于语义这个概念非常重要，什么是语义？这个我想一展开又是一长篇大论，我现在也很难说得清，所以，我还是回到这篇文章的主题，泛泛而言吧。

我想大家肯定变狡猾了，先去W3查过对ul/ol和table的定义，嘿嘿，我也是。但是很遗憾的是该死的W3给的答案是Define a List, Define a Table. 这不是废话嘛？NND！说了等于没说，完全就好比等于是一团大便。什么是List嘛？什么是Table嘛？还有办法，金山糍粑！

List: 英文【A series of names, words, or other items written, printed, or imagined one after the other】
中文【目录, 名单, 列表, 序列, 数据清单, 明细表, 条纹, [总称]各种上市证券】
Table: 英文【An orderly arrangement of data, especially one in which the data are arranged in columns and rows in an essentially rectangular form.】
中文【表：数据中的一种有序排列，尤指其中的数据按基本上构成一个矩形的竖行和横行进行排列的一张表格】

好像也得不出什么所以然的结果，虽然好像已经有所提示了，怎么个提示法？问题的最关键在于单列多行的时候如何抉择？好，待我磨拳擦掌搓脚磨牙，试试看。

首先严正申明：由于没有准确的List和Table定义，所以和之前有法可依，有矩可循不一样，这次真正纯粹是个人的理解了，您完全可以视为胡说八道。我想还是和上次一样分两方面来分析，理论和实践。

理论先行，我先闭嘴，咱们看图说话，分别用List和Table列一段单行数据如下：(unorder和order并不是关键，随便了）

List

数据一
数据二
数据三
数据四
数据五

Table

数据一

数据二

数据三

数据四

数据五

看出来什么没有？好像什么也看不出来，ul和ol的圆点数字说明不了什么问题，ul/ol的代码量比table少很多，也不能说明什么问题，table的边框？我故意加的。好，我们接着继续看，让我们把数据扩展一次再看。

List Expand

数据一
1. AAA
数据二
1. BBB
数据三
1. CCC
数据四
1. DDD
数据五
1. EEE

Table Expand

数据一	AAA
数据二	BBB
数据三	CCC
数据四	DDD
数据五	EEE

现在看出来了吗？仔细看看？还没有吗？还需要我继续扩展吗？

我直接说我的认知了：
table和ul/ol都能产生数据行，但是table的重心应该是在产生数据列，而ul/ol的重心应该是在产生数据级。
所以对于单列多行的数据，扩展的趋势是产生级的时候，使用ul/ol。扩展的趋势是产生列的时候，使用table。。

是的，我是这么区分的，趋势、级、列。我认为是隐藏的语义。

我想，你可能不会认可，觉得牵强，其实我也不是非常确定。

那么好，现在我再回到实践中来分析我的观点。

最常见的是网站中的新闻列表，特别是首页上的各栏目新闻列表，绝大部分都在使用ul/ol。我认为是种滥用，应该用table。这里要到后台程序开发中走走，新闻列表从数据库里产生出来，在数据库里，一条新闻由许多字段组成，首页上的简短新闻表和内页中的完整新闻表在一些情况下有可能是调用同一个存储过程或者SQL语句。不同的仅仅是数据的绑定，首页上的我可能只是绑定标题和时间，内页中或许会更完整一点，比如加上点击数、作者之类。如果一个新闻表有三列以上，你肯定不会使用ul/ol了。那么两列的和三列的有本质区别吗？我知道两列可以很容易用ul/ol实现，增加span嘛，那么三列呢？你说可以，给span加class。好吧，四列了，你还说可以吗？是的，我承认仍然可以做到，你烦不烦啊！

再说了，本来一个样式就可以内外定义完同样的新闻表，分开后你又要定义ul/ol，又要定义table，不是多此一举吗？最重要的还是在扩展的趋势上，如果数据一旦向列扩展，ul/ol将非常困难。你说是吗？

ul/ol不是用来取代或者模拟table的，table用于表状数据，什么数据是表状数据，扩展趋势是列的数据，哪怕它只有一列也应该视为表状数据而使用table。那么什么时候使用ul/ol？级。具体点菜单上，树上。

当然有些时候数据又有列又有级，这时就会出现混用的情况，相对复杂点了，但我觉得判断还是在级和列上，谁为重？

列表和表格的区别我想了想还是发出来了，毕竟这篇文章老早就标上了，不发有点对不起大家，再说这个我觉得或许真的能够对大家有很实际的帮助。列表和表格是太常用的数据表现形式了。所以发了。

不过发完后我将不再在博客上继续了，尽管现在我还有很多很多想说。两年前的“迎接”，现在的“在路上”，悄悄的说我还想“跨越”，呵呵呵，但是回头看看，很沮丧，连xhtml部分都没写完，CSS方面基本没谈到，还有JS，还有……

以目前这样的慢速度，随意而为，实在不知道何年何月才能写完。Web标准牵扯面太广了，我经常觉得自己驾驭不住，唉，能力还不够啊。我被W3骗了，原以为简单，结果太烫了，让我越陷越深，爬不出来了，感觉自己到处都是漏洞，补不过来。

不过陷得越深，Web标准带给我的震撼也就越大，让我心甘情愿的被埋进去，再埋深点，再深点让我看清楚你的狗屎人模鬼样！本来想的是今年悠哉悠哉的把‘在路上’写完然后沉潜2年再写‘跨越’。其实‘跨越’现在就在我眼前，只不过模糊的地方还多，所以不敢写。

但是从另外一个方面来说，两年后是什么样，谁知道？两年后说不定我都老掉牙了，再没有精力和心力来写了，所以我打算趁着自己现在牙还没有掉，赶快转进另外一种状态：写作状态。用一年的时间专专心心的整理，认认真真的思考，把所有模糊的地方搞清楚和搞透彻，然后一鼓作气带给大家像现在一样毫无保留的，我的全部经验心得，完完整整的《重构之美》，我想应该比目前零零散散的记录好很多。我非常感谢这段时间来大家的关注，给了我很大的支持和信心，希望能够得到大家的谅解和继续支持和鼓励和帮助和加油和乱七八糟的一大堆。

I Promise, I'll be back! 一年后见。

Posted on 2007-03-02 11:10 李通通阅读(302) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

.NET 博客