Web標准的web UI——來源、謬誤與個人理解
序
我從2004年末開始接觸web標准，2005年5月正式采取完全的web標准方式的網頁制作，2005年8月，第一個符合web標准的網站UI開發工作完成。直至今日，經歷了無數的艱辛，也有過許多的困惑。所幸，我的瑞典籍的Project Leader是一個很有經驗的人，他告訴了我很多關於web標准國內並不了解的東西，我這幾年技術方面的成長離不開他的支持和引導，感謝Andreas Liljefilt！在這裡，我把它們告訴大家，也希望能有更多的人來討論。
Chaper 1 什麼是web標准？Div+CSS的謬誤。
提到web標准，就不得不先說一說國內業界非常流行的一個詞——Div+css。這個詞在國內簡直是一個潮流，不僅互聯網上一直在提，大量的教程中使用這個詞，就連一些出版的書籍也是用了這個概念。然而，甚少人知道的是，這個概念本身是錯誤的。有好事的朋友不妨去google搜索一下（先調整到英文界面，這樣可以強制讓它搜索google.com而不是google.cn），"div+css"這樣一個關鍵字是根本找不到任何一個英文網頁，全部都是中文的。沒錯，其實所謂的div+CSS就是一個中國特有的理解和概念。我甚至不知道這個詞是誰先提出來的，然而，它對web標准中xHtml/CSS的網頁構建方法的理解幾乎是完全錯誤的。
回歸正題，web標准究竟是什麼？Web標准是w3c組織規定的各種web上所使用的語言的標准和規范的集合。
我們目前究竟接觸到了web標准的多少？打開 w3c的官方網站，我們在左側可以看到如下列表：
引用:
# 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標准目前的全部技術規范。web標准包含了這麼多的內容，而我們目前所說的div+CSS只是其中xHtml/CSS實現方式的不完整的一部分而已。
* 為什麼是xHtml/CSS？
其他的部分，我不想說的太多，第一是因為我也沒辦法全都弄懂，第二是其中有一大半浏覽器支持不完全甚至根本就不支持。XML是web標准中對網頁實現的最終目標。也就是web頁面數據化和語義化，然而由於浏覽器的支持不完善和兼容問題，目前優秀、兼容性強的純XML網站只是停留在幻想裡而已。因此，現在主流的網頁實現方式就是xhtml/CSS。首先，xhtml與Html大部分兼容，並且可以讓目前大多數的浏覽器直接閱讀。CSS主流的幾大浏覽器也支持的非常完善。再加上ECMAScript(不說Javascript的原因是Javascript的概念中包含了很多與標准不同的浏覽器私有定義)，已經足夠實現web UI布局的大部分需要了。
Chapter 2 web標准真的是要完全不用表格？
好像是在2005年的時候，一篇叫做《把表格從你的網頁中扔出去》（找不到文章的鏈接了，但確實有這篇文章）的在線文章，似乎給了人們一個錯覺，要符合標准，那麼表格在網頁中就完全不能使用了。必須用div來代替。也許div+css這個概念就是這樣被想當然的創造出來的（源自表格布局）。但事實上，web標准並不是完全不允許使用表格。而是要求摒棄使用表格來布局的做法。同時，也不再使用布局這個概念。而是提倡結構與表現分離。這時，就有一些人會產生一個疑惑，如果說xhtml代表結構，CSS用來控制表現，那麼，布局該如何解決？相信現在接觸web標准的朋友不會再有這個疑惑了吧？結構和表現結合起來就形成了布局。既然不能用表格來做布局了，那麼表格還有什麼用呢？似乎很多人忘了表格在Html中的原始定義——展現結構化數據表格。舉個例子，某學校班級的期中考試成績表，這種數據，就是一個非常明顯的表格。web標准中絕對沒有要求你用div來模擬表格，那是非常蠢的做法。這幾天在經典論壇上還看到有人產生這樣的疑惑，表格形式的格式化數據，用表格比用div要方便的多，他們搞不懂為什麼一定要用div來表現表格，現在我告訴你答案了，該用表格展現數據的時候就要用表格。
Chapter 3 為什麼要用web標准？怎麼樣才算是符合web標准？
很多人會說例如兼容性好、代碼易懂、代碼量小、結構合理、甚至有人說使用標准可以實現比表格更豐富的樣式等各種理由來支持web標准，而web標准也的確具有這些優點，然而，這些卻並非web標准真正要做的。
並非把表格換成div就是符合web標准了。也並非使用xHtml和CSS就是符合web標准。甚至就算你的代碼能夠通過w3c的驗證，也很難說它就完全符合web標准。事實上，web標准的最終目標不是為了讓人容易看懂網頁如果僅僅是為了讓人容易看懂，那麼表格布局已經足夠了。它的最終目標是為了讓計算機能夠讀懂網頁。看下面幾個例子：
表格布局的一段代碼：
<table width="50%">
<tr>
<td width="30%"></td>
<td width="30%"><font size="3">web</font>標准的概念</td>
<td width="40%">如何實現<b>標准化制作</b></td>
</tr>
<tr>
<td colspan="3"><font color="red"><font size="3">web</font>標准在網頁中的使用</font></td>
</table>
web標准（XHtml/CSS）實現的一段代碼：
<h3><span>web</span>標准的概念</h3>
<h3>如何實現<em>標准化制作</em></h3>
<h3 class="important"><span>web</span>標准在網頁中的使用</td>
web標准(XML)實現的另一段代碼：
<articles>
<articletitle>web標准的概念</articletitle>
<articletitle em="4" emlegth="3">如何實現標准化制作</articletitle>
<articletitle level="important">web標准在網頁中的使用</articletitle>
<articles>
看過以上幾段代碼後，我們先來分析一下。第一段是表格布局的代碼，它把整塊分成了兩行，第一行用了三列，第一列是空的用於縮進，後面兩列分別放了兩篇文章的標題。其中的英文文字采用了不同於中文的字號。第二篇文章的標題上還有一部分是加粗強調的。第二行則是一篇文章的標題占用了整行，並且以紅色顯示文章標題。在頁面展現出來之後，我們能夠明白下面的信息：第一篇文章是普通文章，第二篇文章中有一個概念是很重要的。而第三篇文章則非常重要。然而，在代碼中我們卻很難看出這一點。因為沒有人說過加粗就一定是強調。也沒有人告訴我們紅色就一定表示重要（如果是在暗紅色背景下，它甚至表示不重要，光看代碼是不知道頁面展現出來是什麼樣子的，是否重要自然無從判斷），在這段代碼中甚至沒有告訴我們，這幾段文字是文章標題。
第二段代碼就要清楚的多了，首先，h3標簽告訴我們，它是一個標題。span標簽完全沒有含義，會被分析器忽略掉。而em標簽則表示強調。程序很容易明白它究竟是什麼。最後一行指定的的類important則可以告訴分析器，這篇文章十分重要。
最後，我們再看第三段中的XML代碼，首先，articletitle已經明明白白的告訴我們，它是文章標題，多余的信息沒有了。事實上多數情況下是否強調一段文字中某一個部分對於分析器來說並不重要。因此，加粗強調被放到了屬性裡面。最後一條，level屬性非常明白告訴分析器，這個屬性定義的是文章的級別。而它的屬性important則告訴分析器，它的級別是重要。將來采用這種結構，我們的網絡將會更加智能，而搜索引擎的搜索結果也將會更加准確。當然，好處遠遠不只是這些。
直到現在為止，第三段代碼要想真正完美實現並且兼容，仍然只能停留在我們的夢想裡。
Chapter 4 web標准的局限
web標准並沒有有些人說的那麼天花亂墜無所不能。正如很多在學習web標准開發的朋友所體會到的那樣，如果想要開發的產品完全符合web標准，它的局限性其實很大。舉例來說，如果按照web標准的建議不使用空結構塊(如空div)、不使用無意義塊（如僅作為裝飾邊角的圖片）、不做無意義的DOM結構嵌套，那麼想實現一個可拉伸大小的園角塊都是非常困難的。目前網上流行的幾種做法都不符合這個要求。這就是為什麼歐美的許多網站往往結構以方塊為主並且非常干淨簡練，一個原因是他們習慣這樣的風格，但更重要的原因是為了UI的可用性和符合標准而在犧牲了美觀，因為網站的DOM結構越復雜，互動表現越復雜，觸發BUG的可能性就越大，兼容性也越難調整，此外，這些效果往往還不能完善。有興趣的朋友不妨仔細看看一直被設計人員稱道的大多數韓國網站，這種類型的網站和歐美的主流風格正好完全相背，走了另一個極端，以界面華麗花哨著稱，因此特別能獲得美術出身的朋友的青睐，在使用過程中總會出現各種各樣的小問題。在 FF下也沒有幾個可以完美表現的。此外，這類網站在中國也是行不通的。大家不妨想想，究竟有哪個模仿韓國的網站能夠獲得比較高的知名度的？原因嘛，第一是它們經常造成浏覽器速度過慢，第二是在網絡條件不好的情況下下載經常很慢，第三，對服務器的負載壓力非常大，很容易提高服務器的投入成本，最後，帶來高帶寬成本。
Chapter 5 web標准的背後，企業該如何適應web標准？
web標准有諸多好處，也帶來了美好的前景，應當普及和推廣。然而，盲目地追隨標准，卻可能造成整個項目的失敗。要知道，web標准並非孤立的產生，而是於整個軟件工程和web項目管理的發展有關。下面，我們來看一下，在適應web標准的過程中，究竟有哪些問題會造成項目失敗。
1. 對標准的理解錯誤
前面說了，國內其實大多數企業和開發人員並不了解web標准。甚至有很多連web標准這個概念都不知道。反而對div+CSS這個被人錯誤解釋出來的怪胎耳熟能詳。設計師在進行設計的時候，往往天馬行空的去做設計，完全沒有任何章法可言，同樣的內容，甚至在首頁是三個字的標題，到了二級欄目頁就會變成五個字，從根本上破壞了結構的可重用性。而UI程序員（請原諒我使用這個詞語，因為發展到現在的web標准網頁開發已經不是美術出身的設計師能夠完全掌握的了）為了適應設計師的設計，只好拼命疊加各種奇怪的DOM結構，結果使本來用十行Html代碼就能寫出來的頁面最後用了三十行甚至更多，結構也一片混亂。CSS就更不用說了，不僅亂，而且亂的毫無章法。這種開發的方式經常造成最後只要設計上修改一點，就要對代碼作非常大的改動，甚至整個開發流程從頭做一遍，根本沒有做到web標准中宣傳的改版成本小，正好相反，改版成本有時會被無限提高。而混亂的結構和樣式也會引發浏覽器更多的BUG，讓UI程序員不得不花更多的精力去寫hack。從而進一步提高開發成本。
2. 沒有任何規劃，上手就做
在早期，由於表格布局的完全可視化編輯，使網頁開發是可以完全不需要規劃，一邊做一邊修改的。而我們大多數企業目前的開發流程也是如此。往往網站開發接近完成，策劃人員還沒有完全確定網站要展示的內容和提供的功能。但歐美許多公司的做法卻是先做一份十分完善的策劃和需求描述，然後建立用例模型、分析網站需求、建立邏輯模型，規劃UI模塊、規劃功能模塊、定義UI和功能模塊的接口（大多數情況下這個接口就是我們現在經常使用的各種模板標簽，事實上在歐洲比較完善的團隊，這些標簽在開始設計前就已經規定好了）、定義 Flash應用程序的數據接口（一般情況下是XML文檔）、定義內容框架（以便設計師在設計網站時了解網站的每個頁面上究竟應該放些什麼），這一大堆的各種文檔幾乎可以讓任何兩個不同的團隊做出功能一模一樣的兩個網站來，除了美術設計不同。我就見過一份不過二十多個模板的策劃案，僅僅是涉及UI設計和開發的策劃和分析文檔打印出來有300多頁，密密麻麻的幾十萬字！為什麼要說中國和歐美企業的開發過程的不同呢？原因很簡單。中國的流程隨意性更大，而歐美的流程則更加系統。然而web標准在設計的時候卻是以歐美的設計流程為主。這就是我上面說的，沒有任何規劃，上手就做經常會造成項目失敗的原因。一個邊策劃邊構建的開發流程，采用了一份為完善的系統工程要求訂制的標准，不失敗才是奇跡！
3. 主導人員角色錯誤，外行管理內行
這幾乎是中國百分之八十項目失敗的主要原因！對比東西方的管理，會發現一個奇怪的現象，在西方一個項目是由專業的項目經理主導，而東方則是誰職位最高就由誰主導。總經理、部門行政經理甚至市場人員干預網站開發進程在中國屢見不鮮，甚至有向非web專業市場人員主導項目管理的傾向。在一個web開發團隊中，有時起主導作用的項目經理或者策劃人員並非專業的項目經理或者web策劃人員，最誇張的，我目前在做的項目竟然是以設計師的設計稿為主導，設計成什麼樣子，就必須作成什麼樣子，並且整個網站的設計稿完全沒有任何關於互動方面的說明（其實是繪圖師，他們對web的結構和技術限制是完全懂的）。而我認識的很多朋友也都因為上級在開發進程中的胡亂干預（注意，是開發進程中，而不是策劃過程）叫苦連天，甚至有時會造成整個項目必須徹底推翻重來的尴尬境地。不斷延期或者推翻重來的項目開發過程，無限翻倍的項目成本，造成項目失敗也就不怎麼新鮮了。似乎這一點與web標准並沒有關系，然而，在web標准化開發要求的團隊和流程裡，第一點要求就是項目經理和策劃人員必須專業並且其技能范圍符合項目規模！事實上這也是任何項目管理的必要條件。
那麼，企業和開發人員究竟該如何適應web標准？以下幾點注意事項僅供參考：
這篇文章到這裡已經結束了，我不知道這篇文章究竟會不會讓那些一意孤行的BOSS們看到，更不指望能給他們帶來多少影響。如果哪個BOSS看到了，希望你考慮一下你的投資和鈔票。我所說的這一切，不僅僅是為了減輕開發人員的負擔，更是為了讓開發人員能夠實現一個賺錢的項目，從而在這個賺錢的項目中獲得更多的金錢和良好的心情。而能夠決定這一切的，並非開發和設計人員。