Web標準的web UI——來源、謬誤與個人理解
序
我從2004年末開始接觸web標準，2005年5月正式采取完全的web標準方式的網(wǎng)頁制作，2005年8月，第一個符合web標準的網(wǎng)站UI開發(fā)工作完成。直至今日，經(jīng)歷了無數(shù)的艱辛，也有過許多的困惑。所幸，我的瑞典籍的Project Leader是一個很有經(jīng)驗的人，他告訴了我很多關(guān)于web標準國內(nèi)并不了解的東西，我這幾年技術(shù)方面的成長離不開他的支持和引導，感謝Andreas Liljefilt！在這里，我把它們告訴大家，也希望能有更多的人來討論。
Chaper 1 什么是web標準？Div css的謬誤。
提到web標準，就不得不先說一說國內(nèi)業(yè)界非常流行的一個詞——Div css。這個詞在國內(nèi)簡直是一個潮流，不僅互聯(lián)網(wǎng)上一直在提，大量的教程中使用這個詞，就連一些出版的書籍也是用了這個概念。然而，甚少人知道的是，這個概念本身是錯誤的。有好事的朋友不妨去google搜索一下（先調(diào)整到英文界面，這樣可以強制讓它搜索google.com而不是google.cn），"div css"這樣一個關(guān)鍵字是根本找不到任何一個英文網(wǎng)頁，全部都是中文的。沒錯，其實所謂的div css就是一個中國特有的理解和概念。我甚至不知道這個詞是誰先提出來的，然而，它對web標準中xhtml/css的網(wǎng)頁構(gòu)建方法的理解幾乎是完全錯誤的。
回歸正題，web標準究竟是什么？Web標準是w3c組織規(guī)定的各種web上所使用的語言的標準和規(guī)范的集合。
我們目前究竟接觸到了web標準的多少？打開 w3c的官方網(wǎng)站，我們在左側(cè)可以看到如下列表：
引用:
# Accessibility
# Amaya
# CC/PP
# Compound Document Formats
(CDF)
# CSS
# CSS
Validator
# Databinding
# DOM
# Efficient XML
Interchange
# eGovernment
# GRDDL
# Health Care and Life
Sciences
# HTML
# HTML Tidy
# HTML Validator
# HTTP
# Incubator
# InkML
# Internationalization
# Jigsaw
# Libwww
# MathML
# Mobile Web Initiative
(W3C-MWI)
# Multimodal
Interaction
# OWL
# Patent Policy
# PICS
# PNG
# POWDER
# Privacy and P3P
# RDF
# Rich Web Clients
# Rules
# Security
# Semantic Web
# Service Modeling Language
(SML)
# SMIL
# SOAP/XMLP
# SPARQL
# Style
# SVG
# Timed Text
# URI/URL
# Validators
# Voice
# Ubiquitous Web
Applications
# WAI
# Web API
# Web Application
Formats
# Web Architecture
(TAG)
# WebCGM
# Web Services
# WS-Addressing
# WS-CDL
# WSDL
# WS-Policy
# XForms
# XHTML
# XHTML2
# XLink
# XML
# XML Base
# XML Encryption
# XML Key Management
# XML Processing
# XML Query
# XML Schema
# XML Signature
# XPath
# XPointer
# XSL and XSLT
全看下來后是不是覺得很暈？沒錯，這個就是web標準目前的全部技術(shù)規(guī)范。web標準包含了這么多的內(nèi)容，而我們目前所說的div css只是其中xhtml/css實現(xiàn)方式的不完整的一部分而已。
* 為什么是xhtml/css？
其他的部分，我不想說的太多，第一是因為我也沒辦法全都弄懂，第二是其中有一大半瀏覽器支持不完全甚至根本就不支持。XML是web標準中對網(wǎng)頁實現(xiàn)的最終目標。也就是web頁面數(shù)據(jù)化和語義化，然而由于瀏覽器的支持不完善和兼容問題，目前優(yōu)秀、兼容性強的純xml網(wǎng)站只是停留在幻想里而已。因此，現(xiàn)在主流的網(wǎng)頁實現(xiàn)方式就是xhtml/css。首先，xhtml與html大部分兼容，并且可以讓目前大多數(shù)的瀏覽器直接閱讀。css主流的幾大瀏覽器也支持的非常完善。再加上ECMAScript(不說Javascript的原因是Javascript的概念中包含了很多與標準不同的瀏覽器私有定義)，已經(jīng)足夠?qū)崿F(xiàn)web UI布局的大部分需要了。
#p#
Chapter 2 web標準真的是要完全不用表格？
好像是在2005年的時候，一篇叫做《把表格從你的網(wǎng)頁中扔出去》（找不到文章的鏈接了，但確實有這篇文章）的在線文章，似乎給了人們一個錯覺，要符合標準，那么表格在網(wǎng)頁中就完全不能使用了。必須用div來代替。也許div css這個概念就是這樣被想當然的創(chuàng)造出來的（源自表格布局）。但事實上，web標準并不是完全不允許使用表格。而是要求摒棄使用表格來布局的做法。同時，也不再使用布局這個概念。而是提倡結(jié)構(gòu)與表現(xiàn)分離。這時，就有一些人會產(chǎn)生一個疑惑，如果說xhtml代表結(jié)構(gòu)，css用來控制表現(xiàn)，那么，布局該如何解決？相信現(xiàn)在接觸web標準的朋友不會再有這個疑惑了吧？結(jié)構(gòu)和表現(xiàn)結(jié)合起來就形成了布局。既然不能用表格來做布局了，那么表格還有什么用呢？似乎很多人忘了表格在html中的原始定義——展現(xiàn)結(jié)構(gòu)化數(shù)據(jù)表格。舉個例子，某學校班級的期中考試成績表，這種數(shù)據(jù)，就是一個非常明顯的表格。web標準中絕對沒有要求你用div來模擬表格，那是非常蠢的做法。這幾天在經(jīng)典論壇上還看到有人產(chǎn)生這樣的疑惑，表格形式的格式化數(shù)據(jù)，用表格比用div要方便的多，他們搞不懂為什么一定要用div來表現(xiàn)表格，現(xiàn)在我告訴你答案了，該用表格展現(xiàn)數(shù)據(jù)的時候就要用表格。
Chapter 3 為什么要用web標準？怎么樣才算是符合web標準？
很多人會說例如兼容性好、代碼易懂、代碼量小、結(jié)構(gòu)合理、甚至有人說使用標準可以實現(xiàn)比表格更豐富的樣式等各種理由來支持web標準，而web標準也的確具有這些優(yōu)點，然而，這些卻并非web標準真正要做的。
并非把表格換成div就是符合web標準了。也并非使用xhtml和css就是符合web標準。甚至就算你的代碼能夠通過w3c的驗證，也很難說它就完全符合web標準。事實上，web標準的最終目標不是為了讓人容易看懂網(wǎng)頁如果僅僅是為了讓人容易看懂，那么表格布局已經(jīng)足夠了。它的最終目標是為了讓計算機能夠讀懂網(wǎng)頁?？聪旅鎺讉€例子：
表格布局的一段代碼：
<table width="50%">
<tr>
<td width="30%"></td>
<td width="30%"><font size="3">web</font>標準的概念</td>
<td width="40%">如何實現(xiàn)<b>標準化制作</b></td>
</tr>
<tr>
<td colspan="3"><font color="red"><font size="3">web</font>標準在網(wǎng)頁中的使用</font></td>
</table>
web標準（XHTML/CSS）實現(xiàn)的一段代碼：
<h3><span>web</span>標準的概念</h3>
<h3>如何實現(xiàn)<em>標準化制作</em></h3>
<h3 class="important"><span>web</span>標準在網(wǎng)頁中的使用</td>
web標準(XML)實現(xiàn)的另一段代碼：
<articles>
<articletitle>web標準的概念</articletitle>
<articletitle em="4" emlegth="3">如何實現(xiàn)標準化制作</articletitle>
<articletitle level="important">web標準在網(wǎng)頁中的使用</articletitle>
<articles>
看過以上幾段代碼后，我們先來分析一下。第一段是表格布局的代碼，它把整塊分成了兩行，第一行用了三列，第一列是空的用于縮進，后面兩列分別放了兩篇文章的標題。其中的英文文字采用了不同于中文的字號。第二篇文章的標題上還有一部分是加粗強調(diào)的。第二行則是一篇文章的標題占用了整行，并且以紅色顯示文章標題。在頁面展現(xiàn)出來之后，我們能夠明白下面的信息：第一篇文章是普通文章，第二篇文章中有一個概念是很重要的。而第三篇文章則非常重要。然而，在代碼中我們卻很難看出這一點。因為沒有人說過加粗就一定是強調(diào)。也沒有人告訴我們紅色就一定表示重要（如果是在暗紅色背景下，它甚至表示不重要，光看代碼是不知道頁面展現(xiàn)出來是什么樣子的，是否重要自然無從判斷），在這段代碼中甚至沒有告訴我們，這幾段文字是文章標題。
第二段代碼就要清楚的多了，首先，h3標簽告訴我們，它是一個標題。span標簽完全沒有含義，會被分析器忽略掉。而em標簽則表示強調(diào)。程序很容易明白它究竟是什么。最后一行指定的的類important則可以告訴分析器，這篇文章十分重要。
最后，我們再看第三段中的XML代碼，首先，articletitle已經(jīng)明明白白的告訴我們，它是文章標題，多余的信息沒有了。事實上多數(shù)情況下是否強調(diào)一段文字中某一個部分對于分析器來說并不重要。因此，加粗強調(diào)被放到了屬性里面。最后一條，level屬性非常明白告訴分析器，這個屬性定義的是文章的級別。而它的屬性important則告訴分析器，它的級別是重要。將來采用這種結(jié)構(gòu)，我們的網(wǎng)絡(luò)將會更加智能，而搜索引擎的搜索結(jié)果也將會更加準確。當然，好處遠遠不只是這些。
直到現(xiàn)在為止，第三段代碼要想真正完美實現(xiàn)并且兼容，仍然只能停留在我們的夢想里。
#p#
Chapter 4 web標準的局限
web標準并沒有有些人說的那么天花亂墜無所不能。正如很多在學習web標準開發(fā)的朋友所體會到的那樣，如果想要開發(fā)的產(chǎn)品完全符合web標準，它的局限性其實很大。舉例來說，如果按照web標準的建議不使用空結(jié)構(gòu)塊(如空div)、不使用無意義塊（如僅作為裝飾邊角的圖片）、不做無意義的DOM結(jié)構(gòu)嵌套，那么想實現(xiàn)一個可拉伸大小的園角塊都是非常困難的。目前網(wǎng)上流行的幾種做法都不符合這個要求。這就是為什么歐美的許多網(wǎng)站往往結(jié)構(gòu)以方塊為主并且非常干凈簡練，一個原因是他們習慣這樣的風格，但更重要的原因是為了UI的可用性和符合標準而在犧牲了美觀，因為網(wǎng)站的DOM結(jié)構(gòu)越復雜，互動表現(xiàn)越復雜，觸發(fā)BUG的可能性就越大，兼容性也越難調(diào)整，此外，這些效果往往還不能完善。有興趣的朋友不妨仔細看看一直被設(shè)計人員稱道的大多數(shù)韓國網(wǎng)站，這種類型的網(wǎng)站和歐美的主流風格正好完全相背，走了另一個極端，以界面華麗花哨著稱，因此特別能獲得美術(shù)出身的朋友的青睞，在使用過程中總會出現(xiàn)各種各樣的小問題。在 FF下也沒有幾個可以完美表現(xiàn)的。此外，這類網(wǎng)站在中國也是行不通的。大家不妨想想，究竟有哪個模仿韓國的網(wǎng)站能夠獲得比較高的知名度的？原因嘛，第一是它們經(jīng)常造成瀏覽器速度過慢，第二是在網(wǎng)絡(luò)條件不好的情況下下載經(jīng)常很慢，第三，對服務器的負載壓力非常大，很容易提高服務器的投入成本，最后，帶來高帶寬成本。
Chapter 5 web標準的背后，企業(yè)該如何適應web標準？
web標準有諸多好處，也帶來了美好的前景，應當普及和推廣。然而，盲目地追隨標準，卻可能造成整個項目的失敗。要知道，web標準并非孤立的產(chǎn)生，而是于整個軟件工程和web項目管理的發(fā)展有關(guān)。下面，我們來看一下，在適應web標準的過程中，究竟有哪些問題會造成項目失敗。
1. 對標準的理解錯誤
前面說了，國內(nèi)其實大多數(shù)企業(yè)和開發(fā)人員并不了解web標準。甚至有很多連web標準這個概念都不知道。反而對div css這個被人錯誤解釋出來的怪胎耳熟能詳。設(shè)計師在進行設(shè)計的時候，往往天馬行空的去做設(shè)計，完全沒有任何章法可言，同樣的內(nèi)容，甚至在首頁是三個字的標題，到了二級欄目頁就會變成五個字，從根本上破壞了結(jié)構(gòu)的可重用性。而UI程序員（請原諒我使用這個詞語，因為發(fā)展到現(xiàn)在的web標準網(wǎng)頁開發(fā)已經(jīng)不是美術(shù)出身的設(shè)計師能夠完全掌握的了）為了適應設(shè)計師的設(shè)計，只好拼命疊加各種奇怪的DOM結(jié)構(gòu)，結(jié)果使本來用十行html代碼就能寫出來的頁面最后用了三十行甚至更多，結(jié)構(gòu)也一片混亂。css就更不用說了，不僅亂，而且亂的毫無章法。這種開發(fā)的方式經(jīng)常造成最后只要設(shè)計上修改一點，就要對代碼作非常大的改動，甚至整個開發(fā)流程從頭做一遍，根本沒有做到web標準中宣傳的改版成本小，正好相反，改版成本有時會被無限提高。而混亂的結(jié)構(gòu)和樣式也會引發(fā)瀏覽器更多的BUG，讓UI程序員不得不花更多的精力去寫hack。從而進一步提高開發(fā)成本。
2. 沒有任何規(guī)劃，上手就做
在早期，由于表格布局的完全可視化編輯，使網(wǎng)頁開發(fā)是可以完全不需要規(guī)劃，一邊做一邊修改的。而我們大多數(shù)企業(yè)目前的開發(fā)流程也是如此。往往網(wǎng)站開發(fā)接近完成，策劃人員還沒有完全確定網(wǎng)站要展示的內(nèi)容和提供的功能。但歐美許多公司的做法卻是先做一份十分完善的策劃和需求描述，然后建立用例模型、分析網(wǎng)站需求、建立邏輯模型，規(guī)劃UI模塊、規(guī)劃功能模塊、定義UI和功能模塊的接口（大多數(shù)情況下這個接口就是我們現(xiàn)在經(jīng)常使用的各種模板標簽，事實上在歐洲比較完善的團隊，這些標簽在開始設(shè)計前就已經(jīng)規(guī)定好了）、定義 flash應用程序的數(shù)據(jù)接口（一般情況下是XML文檔）、定義內(nèi)容框架（以便設(shè)計師在設(shè)計網(wǎng)站時了解網(wǎng)站的每個頁面上究竟應該放些什么），這一大堆的各種文檔幾乎可以讓任何兩個不同的團隊做出功能一模一樣的兩個網(wǎng)站來，除了美術(shù)設(shè)計不同。我就見過一份不過二十多個模板的策劃案，僅僅是涉及UI設(shè)計和開發(fā)的策劃和分析文檔打印出來有300多頁，密密麻麻的幾十萬字！為什么要說中國和歐美企業(yè)的開發(fā)過程的不同呢？原因很簡單。中國的流程隨意性更大，而歐美的流程則更加系統(tǒng)。然而web標準在設(shè)計的時候卻是以歐美的設(shè)計流程為主。這就是我上面說的，沒有任何規(guī)劃，上手就做經(jīng)常會造成項目失敗的原因。一個邊策劃邊構(gòu)建的開發(fā)流程，采用了一份為完善的系統(tǒng)工程要求訂制的標準，不失敗才是奇跡！
3. 主導人員角色錯誤，外行管理內(nèi)行
這幾乎是中國百分之八十項目失敗的主要原因！對比東西方的管理，會發(fā)現(xiàn)一個奇怪的現(xiàn)象，在西方一個項目是由專業(yè)的項目經(jīng)理主導，而東方則是誰職位最高就由誰主導?？偨?jīng)理、部門行政經(jīng)理甚至市場人員干預網(wǎng)站開發(fā)進程在中國屢見不鮮，甚至有向非web專業(yè)市場人員主導項目管理的傾向。在一個web開發(fā)團隊中，有時起主導作用的項目經(jīng)理或者策劃人員并非專業(yè)的項目經(jīng)理或者web策劃人員，最夸張的，我目前在做的項目竟然是以設(shè)計師的設(shè)計稿為主導，設(shè)計成什么樣子，就必須作成什么樣子，并且整個網(wǎng)站的設(shè)計稿完全沒有任何關(guān)于互動方面的說明（其實是繪圖師，他們對web的結(jié)構(gòu)和技術(shù)限制是完全懂的）。而我認識的很多朋友也都因為上級在開發(fā)進程中的胡亂干預（注意，是開發(fā)進程中，而不是策劃過程）叫苦連天，甚至有時會造成整個項目必須徹底推翻重來的尷尬境地。不斷延期或者推翻重來的項目開發(fā)過程，無限翻倍的項目成本，造成項目失敗也就不怎么新鮮了。似乎這一點與web標準并沒有關(guān)系，然而，在web標準化開發(fā)要求的團隊和流程里，第一點要求就是項目經(jīng)理和策劃人員必須專業(yè)并且其技能范圍符合項目規(guī)模！事實上這也是任何項目管理的必要條件。
那么，企業(yè)和開發(fā)人員究竟該如何適應web標準？以下幾點注意事項僅供參考：

完善的前期策劃和分析 完善的前期邏輯模型以及項目規(guī)范性文檔的制定 盡可能將行政性干預移到策劃階段（按照國內(nèi)的情況，做到這一點可能很困難） 盡可能向后兼容，在項目規(guī)范性文檔制定階段對網(wǎng)站進行完善的模塊化規(guī)范（主要是為了提高網(wǎng)站模塊代碼的可重用性以及最大程度上降低改版成本）。 盡可能簡化UI代碼的DOM結(jié)構(gòu)，以降低維護成本 在設(shè)計和開發(fā)過程中首先保證UI的可用性，在此基礎(chǔ)上保證其美觀（好用第一，好看第二）。 項目階段明確，要讓單位的高層明白，在項目的alpha期之前是不可能有能讓他們看的懂用的通的完善網(wǎng)站出現(xiàn)的。 項目團隊主要成員必須要用專業(yè)人員，并且要讓這些人員有足夠的決定權(quán)（如果項目負責人無法主導項目走向，項目就必然產(chǎn)生缺陷甚至失?。?

這篇文章到這里已經(jīng)結(jié)束了，我不知道這篇文章究竟會不會讓那些一意孤行的BOSS們看到，更不指望能給他們帶來多少影響。如果哪個BOSS看到了，希望你考慮一下你的投資和鈔票。我所說的這一切，不僅僅是為了減輕開發(fā)人員的負擔，更是為了讓開發(fā)人員能夠?qū)崿F(xiàn)一個賺錢的項目，從而在這個賺錢的項目中獲得更多的金錢和良好的心情。而能夠決定這一切的，并非開發(fā)和設(shè)計人員。