查看任何一个2003年的站点的页面源代码,从Amazon到Microsoft.com,从Sony到ZDNet,检查他们复杂的非标准的标记,他们私有的ActiveX和JavaScript(常常包含断链检查),以及他们拙劣使用的CSS(当他们完全使用CSS后)。这样的站点能工作在任何浏览器上简直就是一个奇迹!
因为早先的Netscape Navigator和Microsoft Internet Explorer的第4代、第5代浏览器产品支持非标准的标记和特定浏览器代码,这些站点能工作在昨天主流的浏览器中。为了自己浏览器的市场份额,他们居然在拙劣的战争中鼓励私有的标记和脚本。
通常,非标准站点能工作在以前的浏览器上,是因为它们的所有者已经投资购买了昂贵的能够适应多种浏览器的发布工具,可以建立多样的、非标准的版本适应特定浏览器和平台的特殊要求,就像上一节“‘版本’问题”中所述。实际上,他们为了不同版本代码分支,大量嵌套的表格,空像素和其他图片处理,过时的或者不完善的标记,以及属性浪费带宽,使拨号用户负担加重。
什么是代码分支
代码是程序员写的用于在我们的数字世界里建立软件产品、操作系统或者其他大量事物的语句。当多组程序员工作在一个项目上时,每个开发组为了解决不同的问题或者遵循不同的进程,代码就可能被“分支”到多个不相容的版本中。
本书提及的代码分支是指创建不兼容的多版本,以应付不支持ECMAScript和DOM标准的浏览器的需求。
在同一时间,这些多版本浪费了网站的带宽,越大的站点浪费越严重,越多的金钱被浪费在服务器调用、冗余、图片处理和不必要的复杂的代码和标记上。
一般来说,如果一个站点精简35%的代码,它也同样可以减少相同百分比的带宽成本,一个组织一年花费2 500美元的话就可以节省875美元,如果花费160 000美元就可以节约56 000美元。
Yahoo的首页(如图1.3所示)每天服务数百万次,每在过时的HTML标记上浪费一个字节,都将成倍增加天文数字的页面负载,导致10亿字节通信浪费,Yahoo服务器的负担将成倍增加。如果Yahoo简化它的代码,用节约带宽的CSS代替耗费带宽的<font>标签,如图1.4所示,每页的服务成本会减少,公司收益得到增加,那么Yahoo为什么不做这样的改变呢?
我们只能推断Yahoo公司希望他们的站点在现代浏览器中看起来和1995年的不支持CSS的浏览器中一样。具有讽刺意味的是,没有一个Yahoo管理者关心Yahoo页面看起来像什么。站点巨大的成功是因为他们提供的服务,而不是漂亮的视觉设计(就像不存在的一样)。
还有那些网站外表华丽的公司,浪费不计其数的带宽只是为了一个看上去好看却没有人会赞扬的页面。究其原因只是开发者们根深蒂固的“向前兼容”思想,并把这看得比网站可访问性、合理性或者公司利益更重要。

图1.3
Yahoo站点(www.yahoo.com)看起来就像一个朴素的白板

图1.4
查看Yahoo首页的源代码,你会发现如此简单页面的代码竟会如此缠绕和复杂
1.3.1 过时的标记:网站所有者的成本
假设一个旧式的网页的代码和标记有60KB,那么,替换过时的<font>标签和清除其他私有的、表现层的垃圾代码,采用结构化标记和一些CSS规则,同样的页面可以只有30KB(在我的实践中,我们常常可以用22KB甚至更少来替换60KB。保守地说,至少可以节约50%),看下面两个典型的案例。
1.T1终结者
情节:一个经常有几百人在线的自有主机的小型业务或者公共网站服务组织,在通过清理表现层标记,用XHTML结构化页面,切掉一半页面垃圾代码后,节约了1500美元/月。
如何做到的:在代码精简前,为这些用户提供服务需要租用2条T1线,每条线月租是1500美元(一条1.544MB/s的T1线的正常成本),当裁剪文件尺寸50%后,该组织发现只要1条T1线就可以有效提供服务,因此从这一处理上节约了1500美元/月。带宽节约后,同样将节约一些硬件费用。简化你的代码标记,使页面显示更快;页面显示越快,对服务器的压力就越小,你就可以购买、维护、升级更少的服务器。这个做法对于现在应付动态的,基于数据库的内容网站是切实有效的。
2.节约每一兆字节的流量
情景:当商业主机托管变得流行,网站拥有者发现他们每月都支付了一种意想不到的文件流量罚款,从几百甚至到几千美元。裁剪文件一半尺寸后,每月的账单恢复正常,费用趋于合理。
如何做到的:许多商业主机服务提供商每月给他们的用户分配一定流量的免费带宽。比如不超过3GB。低于标准,你每月只要付一般费用,超过了,则必须付更多。
在一个声名狼藉的案例中,因为超出限定流量,主机提供商Global Internet Solutions要求独立设计师A1 Sacui为他的非营利性网站Nosepilot.com支付16 000美元额外费用。这是一个极端的例子,Sacui在核对后避免了支付,但经历了漫长的司法战争,因为那家主机提供商改变了服务条款而没有通知他(http://theWebfairy.com/gisol/)。谁愿意冒高额账单风险或者和主机提供商拖到司法程序中去呢?
当然,不是每一个主机提供商对待流量超额都采取高额收费的措施。例如,在Pair.com,超出1MB的费用一般是1.5美分。一个采用Pair主机的小通信量的站点通过裁剪代码尺寸可以每年节约200美元。更大更高通信量的站点可以节省更多。不论你的站点大还是小,是百万人访问还是只有少数团体会员访问,你的文件越小,占用带宽越小,和你的主机提供商因为流量超额而产生冲突的可能性就越小。顺便说一句,如果你拥有一个热门站点,最好选择那些流量不限制的主机提供商。
精简与压缩代码
在对Web标准发表了一次演讲时,一位听众中的开发者对作者宣称,由干净的和结构良好的代码标记所节约的带宽对于采用压缩HTML技术的公司来说微不足道。
除了通过精简代码压缩你的页面之外(或者仍旧采用过时的“HTML设计”方法),你还可以在一些服务器环境下压缩代码标记。例如:Apache服务器加载的mod_zip模块可以在服务器端压缩你的HTML,在用户浏览器重新把它解开。
那个开发者举了个例子:如果Amazon.com在过时的代码和垃圾代码上浪费40KB,但是用mod_zip压缩掉20KB,Amazon的肿胀的标记的费用将比演讲中建议的要少。
事实上,Amazon没有使用mod_zip,很少有商业网站使用这个工具,可能是因为发送页面前需要额外的加载原因。但是,从另一个角度说,越小的文件压缩后更小。如果你从80KB压缩到40KB节约了费用,那么你为什么不先从80KB精简代码到40KB,然后再压缩到20KB以节约更多费用?每一页节约的数量看起来很小,但这个值是累加的,长时间下来,可以大量地减少操作费用,也可以预防额外的费用。(就像前面的例子:你可以不必要再租借另外一条T1线来应付超额带宽。)
干净的、结构良好的标记的好处不仅是节约带宽,而且还会得到会计和客户的赞扬,这对于那些采用压缩HTML技术的网站也是有现实意义的。
1.3.2 向前兼容
对开发者来说,什么是“向前兼容”?如果你问他们,他们会说就是“支持我们所有的用户”。谁会对这样的观点有异议?
事实上,不管怎么说,“向前兼容”就意味着使用非标准的、私有的标记和代码来保证每一位访问者有相同的体验,不管他们喜欢IE2或者Netscape7。在专业开发领域中,“向前兼容”理论的声音洪亮,就像举着圣杯。但是这样做成本太高,实践也总是基于一个谎言。
没有真正的向前兼容,总是有一个切断点。例如,不论Mosaic(第一个可视化浏览器)还是Netscape1.0,都不支持基于表格设计的HTML。需要解释一下?好,那些用远古浏览器看网站的人们不可能和用稍新一点的浏览器浏览的用户获得同样的视觉体验,比如Netscape1.1或者MSIE2.0。
那些坚持“向前兼容”观点的开发者和客户不可避免地要设定一个“基线浏览器”。例如Netscape 3,网站将不支持更古老的浏览器(Netscape 2的用户就不幸运了)。为了履行他们支持基线浏览器的承诺,开发者针对不同版本的浏览器细节,用非标准的处理方式反复设计他们的标记,导致每一个页面都在加大加重。
在同一时间,开发者也需要写多个脚本来适应不同浏览器,检测用户的浏览器并运行不同代码以使页面看起来最好。正是因为这样做,页面尺寸不断加大,服务器压力不断增加,想挣脱“永久淘汰”的怪圈,直到他们财力枯竭或者被淘汰。
1.3.3 屏蔽用户对业务不利
一些公司愿意多花点钱试图保证在旧版浏览器上能和新浏览器一样正确看到他们的网站,另外一些公司则决定只支持一种浏览器。在减少开支的目标压力下,越来越多的网站只针对IE浏览器设计,甚至某些情况下只针对Windows平台,因此他们失去了15%~25%潜在的访问者和客户。参见图1.5、图1.6、图1.7、图1.8、图1.9。

图1.5
KPMG(www.kpmg.com)网站在Navigator中的页面效果,我们宁可不用Navigator看。这样的页面得感谢愚蠢的只针对IE的代码
因为这种目光短浅的做法而会失去大量的客户。如果有公司说不要1/4的潜在客户,那么谁都会理解这种商业模式。
根据NUA Internet调查统计报告(www.nua.ie/surveys/),截止2002年9月有超过650 600 000的因特网用户,你可以自己计算损失。

图1.6
KPMG网页在Netscape 7中同样无效,我们猜想公司根本不关心他们的客户

图1.7
好,如果这个站点只针对IE浏览器,那么让我们试一下Macintosh IE5版本。噢!它也不能工作。(这个站点在IE5/Macintosh下一半正常,一半失败,没有任何理由)
说你不介意你的站点损失25%的访问用户,而继续“IE-only”方法也是不理性的,因为你不能保证IE(或者桌面浏览器)在Web领域会持续保持主导优势。

图1.8
同样的站点在IE6/Windows下,这才是最初的界面设计

图1.9
当Opera 7/Windows定义自己是IE时,网页非常漂亮。(如果定义自己是Opera,站点无法打开)
在写这本书的前几年,Netscape的Navigator浏览器占领的市场份额远远大于Microsoft的Internet Explorer,在那时,惯例是只支持Netscape。在Microsoft投入数不清的金钱过后,市场改变了,那些只支持Netscape的站点变成了信息高速公路上的数字垃圾。
同样的命运会不会落到只支持IE的站点上?看上去难以想像,但是在Web上没有什么是不变的,惟有变化是永恒的。由于日益广泛使用的非标准网络设备和个性化设计的桌面浏览器等因素,排斥所有其他浏览器和设备的业务决定绝对是不明智的。
此外,正如本书所展示的一样,使用标准就可能设计出适用所有浏览器和设备的站点,简单而快捷。在花费大量成本建立一个向前兼容的网站和压缩成本建造只服务单一浏览器的网站两个极端之间,Web标准提供了惟一的出路。
不论浪费金钱的多版本方法,还是深思熟虑决定只支持一种浏览器或平台的方法,都不能帮助今天的网站继续工作在未来的浏览器上,或者是超越桌面的、日益繁荣的、每天都在变化的世界中。而如果继续这样做,成本和复杂性就会不断升高,直到大部分的公司都无法负担和升级网站的费用。
当我们努力在不同浏览环境下提供相同的体验时——使网站看起来像印刷物,操作起来像桌面软件——我们损失了它的真正的本意,即网站对所有人都应该是丰富的、多层次的、易接近的媒体。
在短暂的网络繁荣期,当设计师和开发者不规范地维护网站,无标准地学习,为某种浏览器细节而设计页面的时候,我们逐渐失去了它的本意,最终导致我们现在面临网站淘汰的关口。
许多网站已经发展到荒废期,只是还在垂死挣扎,当你读到这些文字,无数的网站都已经倒闭。如果你是网站拥有者、管理者或者创建者,警钟已经敲响!
1.3.4 愚蠢之路
早在1997年,有一个通用惯例:为Netscape浏览器写JavaScript,为Microsoft浏览器写JScript(一种类似JavaScript的语言)。使用JavaScript(只工作在Netscape)和ActiveX(只工作在IE/Windows)为不同的浏览器写代码也有类似的通用惯例,那就是我们为3.0浏览器做的。
这种方法对其他小的没有品牌的浏览器(比如Opera)没有一点好处,并且不能正确作用在Macintosh平台的IE上。但是它可以为大部分的Web用户工作,并很快成为当时的行业惯例,如果我们想建立比静态页面看起来更可爱的动态网站,我们除了使用这些程序别无选择。
1997年下半年,Netscape和Microsoft都推出了4.0浏览器,每个都吹嘘有强大的“动态HTML”(DHTML)能力。你可能已经猜到,它们完全互相不兼容,而且和它们自己早前的版本也互相不兼容(在Netscape 4中工作的不能在Netscape 3中工作),更不用说那些不知名的浏览器了。它们从顺从地支持HTML等基础规范,转变为创造它们自己的语言和属性。
规则可以自己随意制定吗?Netscape和Microsoft认为可以,许多设计师和开发者也同意。那些持反对意见的人除了咬咬牙用功做出需要的版本,发布一个可以接受的“专业”站点之外,别无选择,
我该如何编码呢?让我想想
既有针对Netscape 4的DHTML,又有不兼容的、更适合在Windows系统下工作的、针对Internet Explorer 4的DHTML。但是没有针对Netscape 3和IE 3的非DHTML的脚本语言,针对其他不知名的浏览器和更早期的浏览器或许有附加的代码,或许根本没有。简而言之,甚至最简单的网页也需要比意大利面更缠绕的代码。
一些开发者限制他们自己的网站只能适合两个浏览器版本(一个针对IE4,另一个针对Netscape 4),并要求访问者安装一个4.0浏览器,否则将无法访问。另外一些预算更少的,就将所有事情限制在一个浏览器上。
在4.0浏览器推出市场不久后成立的Web标准组织,评估当时Web开发方法,每个功能都需要写四个或者更多版本,因此设计和开发任何网站上将会至少增加25%的成本。
一些开发者对这一评估的反应是非常不屑的。因为网络越来越热,客户心甘情愿地付费,这样大网站运营商何必担心成倍代码和标记给网站带来的高成本?然而因特网泡沫的破灭,网站预算随之缩小或者冻结,运营商开始缩小规模或者转移到其他行业,一夜之间,几乎没有人能够负担得起多版本网站的费用。
当此行业从裁员和倒闭中蹒跚走出来时,新一代的支持公共DOM(W3C制订的)的浏览器出现了,这个发展意味着什么?它意味着版本问题找到出路,一个新的以标准为基础的设计和开发的时代的到来。我们低迷的行业经济如何对这渴望以久的消息做出反应?这个行业仍旧处于继续写分支代码、开发只针对IE/Windows的版本或者转到Macromedia Flash的状态中。因为过度的商业幻想,所以Web行业目光短浅。







