Web标准的web UI-来源、谬误与个人理解

Web标准的web UI-来源、谬误与个人理解时间: 2007-12-25 16:54:19　浏览：2741　序

我从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的官方网站，我们在左侧可以看到如下列表：

QUOTE:

# 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标准的最终目标不是为了让人容易看懂网页如果仅仅是为了让人容易看懂，那么表格布局已经足够了。它的最终目标是为了让计算机能够读懂网页。看下面几个例子：

表格布局的一段代码

 

CODE:

<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）实现的一段代码

 

CODE:

<h3><span>web</span>标准的概念</h3>
<h3>如何实现<em>标准化制作</em></h3>
<h3 class="important"><span>web</span>标准在网页中的使用</td>

web标准(XML)实现的另一段代码

 

CODE:

<articles>
    <articletitle>web标准的概念</articletitle>
    <articletitle em="4" emlegth="3">如何实现标准化制作</articletitle>
    <articletitle level="important">web标准在网页中的使用</articletitle>
<articles>

转载请保留作者和原文地址： 作者 icebird，http://blog.icebirds.net/site/comments/a20071224001/

看过以上几段代码后，我们先来分析一下。第一段是表格布局的代码，它把整块分成了两行，第一行用了三列，第一列是空的用于缩进，后面两列分别放了两篇文章的标题。其中的英文文字采用了不同于中文的字号。第二篇文章的标题上还有一部分是加粗强调的。第二行则是一篇文章的标题占用了整行，并且以红色显示文章标题。在页面展现出来之后，我们能够明白下面的信息：第一篇文章是普通文章，第二篇文章中有一个概念是很重要的。而第三篇文章则非常重要。然而，在代码中我们却很难看出这一点。因为没有人说过加粗就一定是强调。也没有人告诉我们红色就一定表示重要（如果是在暗红色背景下，它甚至表示不重要，光看代码是不知道页面展现出来是什么样子的，是否重要自然无从判断），在这段代码中甚至没有告诉我们，这几段文字是文章标题。

第二段代码就要清楚的多了，首先，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标准？以下几点注意事项仅供参考：

• 完善的前期策划和分析
• 完善的前期逻辑模型以及项目规范性文档的制定
• 尽可能将行政性干预移到策划阶段（按照国内的情况，做到这一点可能很困难）
• 尽可能向后兼容，在项目规范性文档制定阶段对网站进行完善的模块化规范（主要是为了提高网站模块代码的可重用性以及最大程度上降低改版成本）。
• 尽可能简化UI代码的DOM结构，以降低维护成本
• 在设计和开发过程中首先保证UI的可用性，在此基础上保证其美观（好用第一，好看第二）。
• 项目阶段明确，要让单位的高层明白，在项目的alpha期之前是不可能有能让他们看的懂用的通的完善网站出现的。
• 项目团队主要成员必须要用专业人员，并且要让这些人员有足够的决定权（如果项目负责人无法主导项目走向，项目就必然产生缺陷甚至失败）。

这篇文章到这里已经结束了，我不知道这篇文章究竟会不会让那些一意孤行的BOSS们看到，更不指望能给他们带来多少影响。如果哪个BOSS看到了，希望你考虑一下你的投资和钞票。我所说的这一切，不仅仅是为了减轻开发人员的负担，更是为了让开发人员能够实现一个赚钱的项目，从而在这个赚钱的项目中获得更多的金钱和良好的心情。而能够决定这一切的，并非开发和设计人员。