用 Feed 实现 Blogger 分页 8 条评论

使用 Blogger 建博客，一个很不爽的问题是在首页下方没有分页功能，这会直接导致有兴趣的读者没有办法方便的翻阅以前的旧帖子；而 Blogger 提供的模板，无论是老的 Template，还是新的 Layout，都没有相关的标签来实现这个功能，因此要加上这个功能，就只能继续 hack 了。

这两天利用 Blogger 的完整帖子的 Feed，配合 PHP 实现了这个功能。思路为：

• 读取原始的 index.html，把帖子的部分去掉，也就是 <Blogger>...</Blogger> 这段内容
• 读取以下 Feed 地址，解析出文章的日期、时间、标题、正文、标签等，按照原来模板的格式，用 PHP 输出到原来 index.html 放文章的地方

  http://www.blogger.com/feeds/[blogId]/posts/full?max-results=[step]&start-index=[startIndex]&orderby=published

• 根据当前页码以及总帖数计算分页，在页面底部添加分页链接
• 如果有条件，可以利用 .htaccess 文件，将分页的 URL 由原来的

  xxx.php?page=x

  形式替换成对搜索引擎更友好的

  /index/x

  形式

如此一来，就可以在自己不存储任何文章数据的情况下，实现分页功能。当然，直到目前，以上的 Feed 地址仍然是被墙的，需要翻墙或者使用 HTTP 代理才能成功地获取内容。

phpMyAdmin 使用时 Apache 崩溃问题 1 条评论

最近笔记本的硬盘时常怪响，因此换了一块硬盘以防万一，系统重装了，因此开发环境 PHP + MySQL + Apache 也需要重搭。因为已经做过很多次，做起来轻车熟路，然而装好 phpMyAdmin 以后，在登入界面输入用户名密码点登入，居然弹出一个 Windows 应用程序进程崩溃的 report 对话框：Apache 崩溃了……

重新试了几次，仍然如此，换以前硬盘上的 PHP 目录（保证 PHP 的配置和以前一致），无效；换 Apache 版本，无效；换 phpMyAdmin 较早的可以正常使用的版本，无效；用 MySQL 官方的 GUI 客户端登录，可以读写数据，因此不是 MySQL 的问题，于是我就没辙了……

上 Google，发现很多人都有类似的问题，最早的帖子甚至可以追溯到 2003 年，然而没有看到一个有用的解释或者回答，但终究找到一个网页提到架设 PHP + MySQL + Apache 的时候，要保持 MySQL 的客户端连接库 libmysql.dll 版本一致，最好使用 PHP 自带的 dll。

想到这次设置 PHP 时，没有像以前把所有的 dll 都拷贝到 %windows_root%\system32 下，而只是直接的把 D:\PHP 加入到了 PATH 环境变量中。于是马上照以前的办法，把 PHP 包中的相关 dll 都拷贝到了 system32 下，再启动 Apache，进 phpMyAdmin，问题解决了。

用了一会儿，问题有时候仍然存在，于是又把 %Apache%\bin\libmysql.dll 删除（或改名），则问题解决了。但是在 phpMyAdmin 登入后，首页下方会提示说当前使用的 MySQL 客户端版本和服务器版本不相符，可能导致不可预料的结果。

如果各位对此问题有没有更透彻的解释以及彻底的解决办法，望不吝赐教。

Update 2010-02-10:

这个问题似乎和 MySQL 的版本有关。之前出现此问题的 MySQL 版本是 5.4 beta。最近在新机器上同样的架构和设置，只是 MySQL 版本为 5.1，没有出现该问题。

Gmail 结束 Beta 0 条评论

Google 官方博客及 Twitter 上的 @google 昨晚都发布消息，称 Gmail、Google Docs、Google Calendar 以及 Google Talk 结束 Beta。“Beta” 标记将从这些产品的 LOGO 中去除，但无论是否 “Beta”，Google 都将继续对这些 WEB 应用程序进行创新和改进。

记得自己在 Gmail 刚推出的时候，就收到邀请注册了，并一度做为自己的主要私人邮箱使用，已经有很多年了。（据 Solidot 文章，Gmail 于 2004 年 3 月 31 日推出，所以到现在已经有 5 年多了。）

一项以及多项相关产品有如此长的 BETA 期，这是很少见的。加上我所在公司的其它部门曾经做过 Android 平台 API 的单元测试工作，据说该平台自推出后的很长一段时间，该 API 中 bug 非常多且 API 文档混乱。另外据我多年使用 Blogger 作为博客平台的经验，其 bug 之多也是在公众运营的产品中遥遥领先的。

尽管 Google 的创新能力和“不作恶”是另世人和广大互联网用户称道的，但以上事实也让我非常怀疑 Google 内部的代码质量控制。现在此四项产品的最终结束 Beta，应该可以说对 Google 的形象起到了长远的积极作用，也希望 Google 能为我们提供更多更稳定更惊艳的互联网产品。

GFW 开始识别 WEB 代理 3 条评论

之前提到用 HTTP 中转的办法解决了评论的问题，今天发现 Blog 上所有的评论又失效了…… 开始以为是因为页面直接引用了 www.blogger.com 域名的某些内容而导致撞墙，但仔细分析后发现，我的 HTTP 中转直接不能访问了，而且之后我的 HTTP 中转程序所在的域名也会在一小段时间内无法访问…… 但同时，用该中转能够访问原本没有被封的内容，比如 Flickr……

考虑到传入的目标 URL 参数是用 Base64 和 URL Encode 方式处理的，不存在任何加密，而且这和大多数的　WEB 代理相同，所以推测是现在 GFW 能够识别用 Base64 编码的内容，如果该内容刚好是被屏蔽的网址，则阻拦该 HTTP 请求，并且屏蔽该请求所在的域…… 从而让公众无法通过 WEB 代理访问屏蔽内容。

当然，解决的办法也简单，如果不能简单通过 Base64 decode 得到一个 URL，那么它也就无从判断是不是被屏蔽的网址了……

我起先想直接把原网址按位取反再 Base64 就行了，结果同事说我作为一个 IT 人士这么干太低级了…… 他们说用 RSA 吧，但是也犯不着这么兴师动众吧……

还是 Liuming 小弟比较聪明，提供了一个比按位取反高级，又比 RSA 简单的办法，那就是……

两次 Base64…… >.<"e;

SAMSUNG 手机安装 MIDlet 出现“内容不匹配” 0 条评论

昨天通过 OTA 方式从 Apache 服务器上在一部 SAMSUNG SGH-L760 上安装 MIDlet，下载完 JAD 确认安装，开始下载 JAR 之前，手机报错说“内容不匹配 (Content mismatch)”。同样的 JAD 和 JAR 在另外一个主机上就能成功下载安装，而且这一组 JAD 和 JAR 在同服务器上另外一个 HTTP 服务应用上也能成功安装，一时觉得纳闷。

开始怀疑是端口问题，因为出现安装错误的 Apache 服务器是运行在 82 端口上的。但是同样是从这个 Apache 服务，另外一部 SonyEricsson K610i 就能正常下载安装，而且如果是端口问题，没道理 JAD 能下载而 JAR 不能。

然后开始怀疑是 JAR 文件的 Content-Type 问题，因为在确认安装的界面上，有显示应用类型是 application/vnd.sun.j2me.java-archive。打开 Apache 的配置文件 /etc/httpd/conf/httpd.conf，发现没有定义 .jad 和 .jar 文件的语句，于是添加如下两行：

AddType text/vnd.sun.j2me.app-descriptor .jad
AddType application/vnd.sun.j2me.java-archive .jar

然后重启 Apache 服务，问题解决。MIDlet 成功在 SAMSUNG SGH-L760 上安装了。

你博客的 ping 列表真的全在工作吗？ 4 条评论

我们知道在博客发表文章时，可以利用 XML-RPC 技术将更新通知到各种 Blog 的服务商、搜索引擎等，好让它们主动来抓取，从而提高博客文章被收录的速度和范围。

Google 的 Blogger 不像 WordPress，后者提供了一个方便的 Update Service，只要将 Blog 服务商公布的 XML-RPC 接口地址填进去就可以方便的在发布的时候 ping 这些地址。Blogger 只是在 Settings » Basic 有一个“Add your blog to our listings?”的选项，解释说选择了“Yes”，Google Blog Search 以及 Weblogs.com 就会来收录，除此之外并没有一个可以设置 ping 接口地址列表的地方。

我强烈怀疑 Blogger 这个选项的作用，因为曾经有很长一段时间 Google Blog Search 都没有收录我的文章，后来为了确保收录效果，每次发布文章后我都手工 ping，于是通常 5 分钟内文章就会被收录，而 10 分钟左右，Google 的网页搜索也会收录这篇文章（观察到的最快纪录为 8 分钟）。但是每次都要手工去 ping 确实很麻烦，于是今天就琢磨着自己用 PHP 写一个简单的 XML-RPC 客户端来做这个工作，顺便还可以把其它主流的 ping 服务地址加进去，批量执行。

结果是不试不要紧，一试吓一跳。我参考 Weblogs.com 和 Google Blog Search 提供的标准 ping 操作 API 文档写了一个 XML-RPC 的客户端，测试了一下主流的 ping 服务地址列表，发现其中有很大一部分都不能正常工作。

http://blogsearch.google.com/ping/RPC2
http://rpc.pingomatic.com/
http://api.my.yahoo.com/RPC2
http://api.moreover.com/RPC2
http://rpc.newsgator.com/
http://rpc.weblogs.com/RPC2
http://www.feedsky.com/api/RPC2
http://ping.feedburner.com/
http://rpc.technorati.com/rpc/ping
http://ping.blog.qikoo.com/rpc2.php
http://blog.iask.com/RPC2
http://www.xianguo.com/xmlrpc/ping.php
http://www.zhuaxia.com/rpc/server.php

以下就来一一看一下 ping 这些地址得到的具体结果。

以上这些地址中，能够完全按照标准 API 正常工作的有：

http://blogsearch.google.com/ping/RPC2
http://api.my.yahoo.com/RPC2
http://api.moreover.com/RPC2
http://rpc.weblogs.com/RPC2
http://rpc.technorati.com/rpc/ping

以下是其它有问题的 ping 接口的具体情况。

http://rpc.pingomatic.com/

这是一个十分有名，被博客界所有人争相 ping 之的地址，但是，真的有人见过它返回正确的结果吗？我试了很多次，无论是请求 weblogUpdates.extendedPing 方法，还是weblogUpdates.ping 方法，无论是提供两个参数还是三个、四个参数，它返回的 HTTP 头永远只会是“501 Not Implemented”，正文部分没有任何内容。我另外还试了 http://rpc.pingomatic.com/RPC2 和 http://pingomatic.com/ 两个地址，得到的结果一样。

http://rpc.newsgator.com/

这个地址存在大家的列表中，我感到非常诧异，因为这个域名都已经不存在了，我换了很多个 DNS 服务器都不能解析出它的 IP 地址。后来发现了 NewsGator 的另一个 ping 接口：

http://services.newsgator.com/ngws/xmlrpcping.aspx

经过测试，这个是可以正常工作的。

http://ping.feedburner.com/

起先 FeedBurner 的接口很长时间都不返回，纳闷了很久；细查之下，发现 ping.feedburner.com 这个域名做成了 feeds.feedburner.com 的 CNAME 纪录，而众所周知后者已经被墙，所以实际上这个 ping 接口是没有办法直接通知到的，除非发起 ping 动作的客户端在国外运行。

http://www.feedsky.com/api/RPC2

Feedsky 趁着 FeedBurner 被封在国内很是火了一把，可是做事情的态度和质量还是和人家有差距。首先是没有实现 weblogUpdates.extendedPing 方法，而在请求 weblogUpdates.ping 方法时，返回的结果也很不稳定。有时是正常的结果，有时会以错误码 304 将整个 Feed 的内容放在 message 字段中返回，有时又干脆什么都不返回。

http://ping.blog.qikoo.com/rpc2.php

这个似乎是奇虎官方给出的地址，而几乎网上搜到的所有 ping 列表中都有它。奇怪的是，这个地址根本打不开，HTTP 状态码为 404。我曾经猜测是不是大家在传抄过程中不小心弄错了大小写，于是也试了 RPC2.php, RPC.php, rpc.php，结果都是 404。

http://blog.iask.com/RPC2

新浪这个表面看起来很不错，相应速度很快，返回的 XML 格式也很标准。可是无论怎么提交，返回结果都是 flerror: 1; message: sorry,failing。以至于让我怀疑，这个接口背后的后台程序真的有在运作吗？

http://www.xianguo.com/xmlrpc/ping.php

发出请求大约 5 秒钟后，返回如下内容：

Fatal error: Call to undefined function xmlrpc_server_create() in /opt/lamp/code/common/rssreader-common-2008-11-12-14-31-18/topgene/feed/xmlrpc/server.php on line 15

怎么？PHP 的扩展库都还没配置好就当公共运营的服务器了？而且还直接把错误信息输出到页面上，服务器路径信息一览无余。鲜果啊鲜果，让我说你什么好哇！

http://www.zhuaxia.com/rpc/server.php

抓虾比鲜果好点，至少还返回了，只不过不知道返回的是啥。返回结果如下：

<?xml version="1.0" encoding="utf-8"?>
<methodResponse>
<params>
 <param>
  <value>
   <boolean>0</boolean>
  </value>
 </param>
</params>
</methodResponse>

如果说你看不懂 Weblogs.com 的英文文档倒也情有可原，但是照着 Google 的中文文档依葫芦画瓢总会吧？自己想当然的随便弄一下就完事了？

由以上可以看出，大公司终究还是大公司。令人深思的是，这些不能正常工作的接口中，几乎全是国内的服务商，其中有些暴露出来的问题，更是令人汗颜。

向微软 Live Search 提交 Sitemap 0 条评论

作为 Webmaster，您一定知道 sitemap；您应该也知道使用 Google 的网站管理员工具来提交 sitemap 让 Google 收录您的网页；您或许还知道 Yahoo! 具有同样的站长工具（及其英文版）。

最近发现微软还在 beta 测试中的 Live Search 也推出了这样方便站长的工具 Webmaster Center。

微软 Live Search 的 Webmaster Center

和 Google 及 Yahoo! 的类似，以上 Webmaster Center 工具会让您提供网站的入口地址和 sitemap 地址，然后 Live Search 会提示您下载一个 LiveSearchSiteAuth.xml （文件名真是个微软特色十足啊）文件，其中含有和网站对应的校验码。上传至您网站的根目录，使其能够用

http://www.mysite.com/LiveSearchSiteAuth.xml

这样的形式访问到即可。过一段时间 Webmaster Center 就会自动处理您提交的 sitemap 了。

对于已经录入过的网站，可以在 Site List 页面上的站点列表中点击网站地址的链接进入每个网站查看具体信息，包括摘要、属性、抓取问题、反向链接、链出链接、关键字和网站地图等信息。当网站地图发生改变时，可以通过 Ping 地址

http://webmaster.live.com/webmaster/ping.aspx?siteMap=[your sitemap web address]

来主动通知 MSNBot。

相信有了这个工具后，我们的网站就更容易被 MSN 和 Live Search 收录了。如果您的网站有 sitemap 而还没有提交给 MSN，不妨试一下这个办法。

挑战 XHTML 的 Strict 标准 2 条评论

我的 Blog 网页在 Doctype 声明上一直使用的是 XHTML 的 Strict 标准，当初在模板制作完成时是校验过的，可是随着后来无数次的修改、内容添加，现在已经不能通过 W3C 的语法校验了，加上 Google Blogger 在发布页面的时候似乎也并没有考虑目标模板的 Doctype 标准，也部分导致校验的失败。

经过一个下午的努力，终于基本上解决了所有 XHTML 的语法问题，总结如下。

<a> 标签没有 target 属性

在 Strict DTD 里面，超链接 <a> 标签 没有 target 属性，因此不能利用 target="_blank" 这样的代码来达到新开页面打开链接的目的。为了实现同样的功能，通常的办法是用 rel="external" 来替代 target="_blank"，然后用如下 JavaScript 代码来处理链接：

function externalLinks() {
  var linkArray = document.getElementsByTagName('a');
  for (var i = 0; i < linkArray.length; i++) {
    var link = linkArray[i];
    if (link.getAttribute('rel') == 'external') {
      link.target = '_blank';
    }
  }
}

然后将该 externalLinks() 函数添加到页面的 onLoad 事件中。如：

<body onload="externalLinks();">

<img> 标签必须添加 alt 属性

对于 <img> 标签来讲，alt 属性是必须的。给图片添加 alt，一方面当图片因为各种原因无法显示的时候，能给访问者以提示；另一方面也便于搜索引擎判断图片的内容，以及更准确的建立索引。

<img> 标签没有 border 属性

<img> 标签是没有 border 这个属性的。我们通常会加上 border="0"，主要是因为把图片放在链接标签 <a> 里时，浏览器会加上一个链接默认颜色的边框，而这通常是多余的。在 Strict 标准中，不能用 border 属性来去掉边框，而只能使用 CSS 控制。同样 align 属性也是不存在的，要实现 absmiddle 这样的目的，也只能用 CSS 代替。

<blockquote> 标签内必须使用 block 级别的标签

<blockquote> 标签用来在页面上表示引用的内容，例如，最常见的，引用代码。我通常习惯将代码的内容放在 <code> 标签中，而这个标签是 inline 级的，不符合 Strict DTD 的要求。<strong>、<b> 等同样会导致问题。符合要求的 block 级标签包括：<address>, <blockquote>, <del>, <div>, <dl>, <fieldset>, <form>, <h>, <h2>, <h4>, <h5>, <h6>, <hr>, <ins>, <noscript>, <ol>, <p>, <pre>, <script>, <table>, <ul>。

不能使用 <embed> 标签

这个问题最容易出现在引用外部媒体文件时，例如 MP3 音乐、视频等。很多资料推荐同时使用 <object> 和 <embed> 来增强媒体引用元素的浏览器兼容性，但是很不幸的，Strict DTD 并未定义 <embed>。其实我们完全可以不使用 <embed> 一样能够兼容浏览器。例如 Youtube 给的代码一般是这样的：

<object width="425" height="344">
  <param name="movie" 
         value="http://www.youtube.com/v/uhsjNTEJD3c"></param>
  <param name="allowFullScreen" value="true"></param>
  <embed src="http://www.youtube.com/v/uhsjNTEJD3c" 
         type="application/x-shockwave-flash" 
         allowfullscreen="true" 
         width="425" height="344"></embed>
</object>

这样无法通过校验。我们可以改成：

<object type="application/x-shockwave-flash"
        width="425" height="344">
  <param name="movie" 
         value="http://www.youtube.com/v/uhsjNTEJD3c"/>
  <param name="allowFullScreen" value="true"/>
</object>

实体用法问题

在 XML 中，实体的写法是 &entity;，以一个 & 符号开头，一个分号结束。因此，Strict 标准的 XHTML 里面不允许出现任何单独的 & 符号，即使是在 URL 中用来分隔查询参数。需要用到这个符号的时候，要用 &amp; 来表示。通常一个实体用法的错误会同时导致 5 个校验时的错误，当解决以后，这 5 个错误会同时消失。由于 Blogger 在发布页面时 URL 直接使用了 & 符号，因此会直接导致 Strict 标准的 XHTML 校验失败。

重复的 id 值

对于 XHTML 标签来讲，id 属性的值必须唯一，如果一个文档中出项重复的 id 就会导致问题。出现这种问题，通常是把 id 属性放在了 Blogger 模板会循环输出的部分。

另外，Blogger 提供的模板中，backlinks 那一部分会导致 4 个不同类别的问题。凭心而论，Blogger 模板在 backlinks 这一块的代码实在写的很烂，用了三个不同的 js 文件，用 JavaScript 输出 CSS，不但使得不同模板之间难以更改这一部分显示的样式，也导致了很多 XHTML 的语法校验问题。例如 Blogger 自己的 Buzz，打开任一个文章的独立页面的源代码，Doctype 声明赫然是 XHTML 1.0 Strict，然而 backlink 那一块的代码不用校验也能看出漏洞百出。

Blogger 目前版本的网站出自著名设计师 Douglas Bowman 之手，其本人对 XHTML 以及 CSS 有着非常深刻的研究。在设计之初，Blogger 还没有 Backlinks 的功能，显然这个蹩脚的 Backlinks 是后来由其他人加上去的。不知道 Bowman 先生在看到这一幕后会做何感想。

Google 黑板报用的是同样的 backlink 代码，不过比 Buzz 知趣的是它的模板干脆去掉了 Doctype 声明。只不过作为 Google 旗下的网站，页面连 Doctype 声明都没有，也是一件汗颜的事情。

言归正传，以下列出 backlink 这部分代码导致的问题以及解决方法。

<div> 和 <dl> 之间的嵌套问题

在 Blogger 给出的默认模板代码中，是用 <dl> 来实现反向链接列表的；可问题在于，他们将 <BlogItemBacklinks> 放在了 <dl> 之内，而在生成页面时，会将 <BlogItemBacklinks> 这一对模板标签替换成一对 <div> 标签，从而导致 <div> 被嵌套在 <dl> 内。在 Strict DTD 里，<dl> 标签内只允许出现 <dt> 和 <dd> 两个子标签。解决办法是把 <BlogItemBacklinks> 放到 <dl> 外面，当然这样虽然让 XHTML 语法通过校验，但实际的运行结果，会导致每个反向链接条目会占用一个 <dl> 块，而不是预期的放在循环的若干个 <dt> 和 <dd> 中。通过 CSS 可以解决条目之间间距的问题。如果要完美解决这个问题的话，就只有自己重写 Blogger 提供的 JavaScript 函数来改变这一行为了。

<script> 标签的 defer 属性

在 Blogger 用模板生成页面时，除了将 <BlogItemBacklinks> 替换成一对 <div> 以外，还会在开标签的 <div> 之前加上一个 <script;> 用来引入相关的 JavaScript，同时给出了一个 defer="true" 属性，然而，根据 Strict DTD，defer 属性只能有一个值，只能是 defer="defer"。

<noscript> 内只能用 block 级别标签

在生成以上 <script> 标签的同时，Blogger 给出了一个 <noscript>，用来当浏览器不支持脚本的时候显示一个 Blog Search 的链接。可是 <noscript> 标签内只能用 block 级别的标签，直接用 <a> 这样的 inline 标签是不行的。

模板占位符问题

在模板中这段关于 backlink 的代码中，Blogger 用了一些模板标签作为占位符。通常模板标签会在生成具体网页时替换掉，但这里的占位符不会，它们要在实际生成 backlink 条目时被 JavaScript 程序换掉。但是在做 XHTML 语法校验时，这些占位符以 HTML 标签的形式存在于代码中，而又显然不属于 XHTML 定义的范围，从而导致校验失败。解决办法是将它们的尖括号转移，写成诸如 &lt;$BlogBacklinkTitle$&gt; 的形式，这样既能够被 JavaScript 成功识别，保证功能正常，又能通过 Strict 语法校验。要特别注意，其中 <$BlogBacklinkDeleteIcon$> 不要转义，这个模板标签是在页面生成时被替换的，而不是 JavaScript 的数据占位符。

最后，Google 黑板报最近也发布了一篇关于互联网标准性的文章，这篇文章也提供了很多关于改进网站 HTML 代码的参考信息。

试用 Google Chrome 浏览器 0 条评论

Google 昨天发布了一款开源的浏览器，已经可以下载。目前还只有 Windows 的版本，据说以后还会推出 Linux 和 Mac 的版本。

和目前主流的 Internet Explorer 和 FireFox 比起来，Chrome 的特点就是简洁轻便，Installer 的大小约为 22.8M，和通常的 Windows 应用程序相比，Chrome 窗口没有标题栏和菜单栏，也没有状态栏，界面上除了标签栏、按钮/地址栏和书签栏三行以外，剩下的空间全部留给打开的网页。在地址栏后面有连个按钮，分别是针对当前页面的操作菜单和浏览器的设置菜单，因此操作起来也比较简单，这算是秉承了 Google 一贯的风格。值得一提的是，在地址栏中，URL 的域名以外的部分会显示成灰色，而域名是黑色，这样使得域名看起来更加突出。

虽然界面简洁，操作简单，但功能上该有的也一点都不含糊。支持多页面浏览、内置多款搜索引擎、支持字体缩放。可以从 Internet Explorer 或者 FireFox 导入书签、搜索引擎设置、已经保存的密码以及浏览历史记录。另外，还有下载管理、密码保存、界面默认字体和编码设置、代理服务器、内容和弹出窗口过滤、网络欺诈和恶意软件保护、SSL 证书管理等，可谓应有尽有。同时浏览器以及预置了包含简体中文和繁体中文在内的 42 种界面语言以及拼写检查。从安装目录的文件夹设置上看，应该也支持第三方插件和换肤功能，只是在浏览器界面上还没有体现出来。

对于网页开发人员来讲，Chrome 也体贴的预先内置了源代码查看器（带语法高亮）以及 DOM 查看器以及 JavaScript 调试功能。 IE 和 Firefox 则需要安装第三方插件实现这一功能。

经过测试发现 Chrome 在我机器上的 User Agent 值为：

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

用的可能是 Safari 内核。目前的版本为 0.2.149.27，还只是处在测试阶段，相信以后会更加完善。

Google 的新 Favicon 0 条评论

刚刚发现，Google 似乎更换了网站的 favicon：

和以前旧的纯色边框比起来，现在的浅色渐变和四周的圆角显得更时尚！如果你看到的还是旧的图标，可能是因为缓存的原因。打开 http://www.google.com/favicon.ico 应该可以看到新的图标。另外，Gmail 和 Blogger 的图标还暂时没有发现有变化。

微软将强制将浏览器升级到 IE7 0 条评论

在 Solidot 上看到，InfoWorld 的报道称，微软将在 2 月 12 日通 Windows Server Update Services 把所有 Windows 系统的浏览器强制升级到 IE7，不会像以前那样要经过用户的许可。微软给出的理由是“安全原因”。

Solidot 上还调侃说，对 WEB 开发者来说这是个好消息；对以前只支持 IE6 的网站来说，这是场灾难。

此话不假。以前做 WEB 界面，在所有为浏览器兼容性付出的工作中，50% 的时间花在让 IE 和 FireFox 兼容，另外 50% 的时间花在让 IE 的不同版本之间兼容。作为同一个公司推出的同一系列产品，对一种有标准的文档的理解会有如此大的差异，真的可以说是一件让人费解的事情。不过现在微软终于醒悟了，既然事实已经造成，那就让糟糕的过去都消失掉吧……

通过 GData API 提交评论 0 条评论

前两天有提到升级到 Blogger Beta 后发布评论的问题。今天从 Google Groups 上的 Google Data API 讨论组上看到一个新的发布评论的办法，就是用 GData API 通过单贴评论的 Feed 地址

http://beta.blogger.com/feeds/blogID/postID/comments/default

发布。

这个方法与向 http://beta.blogger.com/comment.do 直接 POST 数据的方法比起来，要科学得多。经过测试，这个方法确实可行，评论发布后，页面会被正常地重建。然而，仍然有问题：评论对应的发布者被设置成了 Blogger 的主人，也就是在向 feed POST 数据之前提供给 Google 的身份验证信息对应的用户。

据讨论组上 Blogger 的研发人员回复说，官方并不支持这种方法提交评论，尽管它确实是可行的。我想之所以会有上面的问题，大概是因为这个方法原本是用来发布帖子用的，在这种情况下，作者信息自然就应该从通过身份验证的 Blogger 账户中取得。

已经在这个有关 GData API 提交评论的讨论串中提出建议修正这个问题，不过不知道 Blogger 会不会理我。在这个问题被修正之前，这个方法实际仍然无法投入实用，毕竟不会有人会让所有评论的作者信息丢失掉。

升级后如何才能方便的发布评论？ 11 条评论

升级到 Blogger Beta后，由于大家无法访问 beta.blogger.com 域名，因此出现了无法发布评论的问题，在上次的帖子中有所讨论。

为了解决这个问题，我自己写了个简单的 Servlet，来接受来自页面上的评论发布，并将这个请求转到 Blogger Beta 上处理评论发布的地址 https://beta.blogger.com/comment.do，因为我可以修改服务器上的 host 文件使其可以访问 beta.blogger.com，这样可以起到一个类似代理的作用，代替需要发布评论的朋友们访问这个不能直接访问的域名。

理论上是没有问题的，实践上我也几乎取得了成功。出现的问题是：评论被正常发布后，和评论相关的帖子页面没有重建！

我们知道，用 FTP 的方式发布 Blogger，任何对帖子的更改，都会导致 Blogger 自动重建页面并自动发布到 FTP 相关的目录下，以使得 blog 网站上的页面能够反应出最近的信息，这些操作包括新增/修改/删除帖子，以及添加/删除评论。正常情况下，一旦有评论发布，这个重建的过程就会发生，这样评论能够在最多几分钟的时间内出现在页面上。

可是现在，评论的内容都出现在 Blogger Beta 自己的评论页面上了，但是却没有触发页面重建。不过，如果直接把页面上评论表单的内容提交到 https://beta.blogger.com/comment.do，则一切正确；但是当然这样做没有意义，因为这要求发布评论的朋友能够直接访问 beta.blogger.com 域名。

现在出现的现象会是，大家发布的评论不会立即显示在帖子页面上，但是实际上是已经被正确的保存了。我看到电子邮件的提示后，就会尽快重建页面使得这些评论能够被显示出来。相信这个问题只是暂时的，总归是应该得到解决的。

这个问题琢磨了一晚上也没有得到结果，Google 上也搜不出什么有用的东西来。已经把这个问题发布到了 Google 上的 Blogger Data API 讨论组求助，希望有人遇到过类似的问题从而给我一些提示。

Updated on 2006/11/17:
有一个更科学的方法来提交评论，那就是用 GData API 向单贴评论的 Feed 地址提交，不过仍然有些问题。详见“通过 GData API 提交评论”。

Updated on 2006/12/21:
Blogger 的某次更新似乎已经解决了评论提交后页面不会重建的问题。现在在页内的评论表单中提交评论，页面会被立即重建，只是由于需要重建的页面和以往的老 Blogger 比起来要多一些，因此会慢一点。一般 5 分钟之内评论就会出现在页面上了。

Firefox 的 JavaScript 问题两则 1 条评论

今天发现页面上新加上的左列 Tag 在 Firefox 上显示不正确，在细察之下，发现 Firefox 在 JavaScript / CSS 上和 IE 不同之处：

问题 1. 类似 obj.style.height = imgObj.height 的语句无效。

即将一个 image 对象的高度值赋给另一个对象，用来修改其样式高度，这样做无效。

分析

要理解这个问题，首先要纠正思想上的一个误区。以上这个操作，其实并非是通常编程概念上的将一个 int 值赋给另一个 int 变量。这个语句的操作，实际上是把 imageObj.height 当作一个字符串，作为 obj 这个对象 CSS 中 height 的属性。

而之前的一篇帖子说过，Firefox 对 CSS 的理解非常严格，任何表示大小的值，数字后面必须跟上单位，除非是 0。也就是说，height: 20 对于 Firefox 来讲不具有任何意义，必须写成 height: 20px 才会被接受。所以，在 JavaScript 中，为了让对 CSS 的 height 值的设置有效，所赋给的字符串也同样必须是数量加上单位。

解决

以上语句，应该写成：

obj.style.height = imgObj.height + 'px';

问题 2. Firefox 不支持 obj.innerText 属性。

如果把 obj.innerText alert() 出来，显示的值是 undefined。

分析

Firefox 支持 innerHTML 属性却不支持 innerText，这一点实在是蹊跷。很多人建议用 innerHTML 来代替需要用 innerText 的场合，但是这显然并不总是适用。我们有时候只是要取得一个 Tag 中的文字信息而不需要 HTML 的标记。

解决

良好的替代办法是用 obj.textContent，这个属性的作用和 innerText 是相同的，名称不同而已。不过为了兼容性，我们还是需要在程序中区分一下当前环境支持哪种。以下方法可以帮助我们区分：

if (document.all) {
    obj.innerText = "myText";
}
else {
    obj.textContent = "myText";
}

以前我们讲过，Firefox 不支持 document.all 这个 Collection，我们需要用 getElementById() 方法来替代，所以通过判断是否有 document.all，就能区分当前环境。

Blogger 网页显示空白的问题 0 条评论

之前一直有朋友声称我的 Blog 访问不了，打开来是空白。这个问题我自己也经常遇到，原因是网页编码被误判成 GB2312，而不是正确的 UTF-8，于是 IE 无法识别，所以显示成空白。这个问题据说在 Firefox 上并不存在，但是为什么会被误判我也一直不清楚。

现在原因应该清楚了，因为在文件头中，声明网页内容编码的那一行标记

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />


被放到了 <title> ... </title> 之后，而刚好 title 中有中文，所以 IE 在没有获得指定的编码类型时，用了默认的 GB2312。

解决这个问题还是比较容易：编辑 Blogger 的模版，把“<$BlogMetaData$>”放到“<title><$BlogPageTitle$></title>”的前面，然后重建一下，就不会出现这个问题了。

Tomcat 5.5 无法编译 Java 1.5 语法 JSP 3 条评论

Apache Jakarta Tomcat 5.5.x (笔者在 5.5.9 和 5.5.12 下遇到同样问题) 在安装过后，用默认配置，无法自动编译带有 Java 1.5 语法的 JSP，经过多方求证，问题是由其自带的 eclipse 编译器造成的。文档 http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html 中说：

The Java compiler from Eclipse JDT in included as the default compiler. It is an advanced Java compiler which will load all dependencies from the Tomcat class loader, which will help tremendously when compiling on large installations with tens of JARs. On fast servers, this will allow sub-second recompilation cycles for even large JSP pages. This new compiler will be updated to support the Java 5 syntax as soon as possible.

Apache Ant, which was used in previous Tomcat releases, can be used instead instead of the new compiler by simply removing the common/lib/jasper-compiler-jdt.jar file, and placing the ant.jar file from the latest Ant distribution in the common/lib folder. If you do this, you also need to use the "javac" argument to catalina.sh.

由此可见，这个编译器 common/lib/jasper-compiler-jdt.jar 是不支持 Java 5 语法的，而 Apache Ant 工程中的编译器可以替代它解决这个问题，具体方法如下：

• 将/common/lib/common/lib/jasper-compiler-jdt.jar 删除
• 将 ant-1.6.x 发布的 ant.jar 拷贝到 /common/lib/
• 修改 /conf/web.xml 文件，找到并修改如下内容，增加 compilerSourceVM 和 compilerTargetVM 两个设置：

<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>

<init-param>
<param-name>compilerSourceVM</param-name>
<param-value>1.5</param-value>
</init-param>
<init-param>
<param-name>compilerTargetVM</param-name>
<param-value>1.5</param-value>
</init-param>

<init-param>
<param-name>fork</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>xpoweredBy</param-name>
<param-value>false</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>


SSI 和 document.write() 3 条评论

这两天一直在考虑怎么给 Blogger 加上 Calendar 和分类的功能。原来是这么打算的：

首先，要让生成的 HTML 代码尽量符合 XHTML 规范，以便可以写程序用 XML 解析器来分析并从中提取数据。只要是合法的 XML，应该问题就不大，不一定要完全遵循 XHTML 的 DTD，反正 Dom4J 没有 DTD 照样能分析 XML，不过，这个还有待试验证实。

Blogger 的帖子数据里面，link 这个字段似乎没有什么用，可以利用它来存储分类。通过程序分析提取以后，套用 Blogger 的模板生成 HTML，并把出现过的分类列表写到一个单独的 HTML 中，由需要的页面通过 SSI include 进来。

同样利用分析出来的数据，生成日历的 HTML，每个月一个文件，供需要的页面调用。

不过，要让 Resin 支持 SSI 功能，可能性不太大，必须另外想办法。

昨天给 BlogBus 做模板，发现这个 Blog 的默认模板里头，所有侧边栏（日历，最近贴，存档，Tags 等）全部都是由 JavaScript 来 document.write() 的，而 JavaScript 代码本身，也貌似是发布的时候根据数据动态产生的，估计这个是为了达到这些数据块可以在需要的地方重复调用的目的。

于是，我想，是不是我也可以将 Blogger 里头需要的 Calendar 和分类数据也在发布时用 Servlet 写成 JavaScript，然后再在需要的地方用这些 JavaScript 来 document.write()。

嗯，有空试验一下就知道了…… 理论上应该是可行的……

Updated on 11/13/2005:

经过试验，用 document.write() 方式输出是可行的，现在此 blog sidebar 上的日历就是用 document.write() 打印出来的，而数据是由 Servlet 分析生成的 HTML 文件后自动写的 JavaScript 代码。问题有两个，一是用 Dom4j 解析的时候，对实体 (entities) 的解析有点问题，要把除 &amp; 以外的所有实体全部清楚掉才能解析正确，应该有正确的识别方法，尚在研究中。另一个问题是，documents.write() 写出来的内容，无法被搜索引擎识别，但对网站本身功能影响不大。

IE, Opera 和 Mozilla Firefox 2 条评论

为了验证 tableless layout 版面的浏览器兼容性，特地找来了时下流行的 Opera 8.5 和 Mozilla Firefox 1.0.7 与 微软的 Internet Explorer 6.0 一起测试，结果是倍受打击……

原来以为基本上不用改就能兼容，因为完全没有用 table 排版，结果在这两个非 IE 的浏览器上，页面虽然没有面目全非，但是也不如在 IE 上显示的完整，而且有些地方莫名奇妙的怎么都设置不正确。花了 4 个小时，经过反复的和 stopdesign 网站样式表的比对，最后发现原因有两点：

• 没有用标准的 XHTML 头来声明页面的 DocType，经过测试，发现用传统的 HTML 4.0 声明，和 XHTML 声明，三种浏览器渲染出来的结果都不同；
• Mozilla Firefox 浏览器对样式表的要求非常严格，所有的数字属性，除了 0 以外，都必须带上单位，否则一律忽略不计！为了这个我纳闷了很久——前两个浏览器都能正确的显示各种样式的 border，而 Firefox 上所有的 border 全部都被忽略了，汗哪…… 给 border-width 参数加上单位 px 后，就正确了。padding、margin 具有同样的问题。

以上提到的 XHTML 需要如下声明：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head profile="http://gmpg.org/xfn/1">


对于线条的样式，dotted 和 dashed，在 IE 上 width 为 1 时，都显示为 dashed；但这两个样式在 Opera 和 Firefox 上能够明显的区分出来。另外，原来几乎所有的 JavaScript 在 Mozilla Firefox 上都不能运行，它对 JavaScript 的语法要求也非常严格，必须完全符合 W3C 标准：

• document.all['id-name'] 不合法，用 document.getElementById('id-name') 替代；
• object.all.tags("DIV") 不合法，用 object.getElementsByTagName("DIV") 替代；
• collObjs(i) 不合法，用 collObjs[i] 替代。

做完以上工作后，终于页面能够在三种浏览器上得到几乎相同的结果了。突然觉得自己做了 5 年的 WEB，完全被微软毒害了，已经养成了太多不好的习惯；看来以后要严格执行 W3C 的 XHTML、CSS 和 JavaScript 标准才是。

So We've Got A New Face Here! 0 条评论

上次翻译了那篇倡导 tableless layout 的文章后，心里头就一直想着尝试一下。所以今天响应这个号召，在坚决不用 table 的原则下，把面孔改成了这个样子。实际没有什么设计的成分，主要是尝试对 CSS 的利用。结果是完全实现了原来必须要用 table 才能完成的版面，还是有点成就感。另外，今天还大概看了一下 CSS 2.0 的参考，突然发现了 CSS 很多以前不知道的却很实用的功能，尤其是，居然可以让溢出容器的文字串自动省略并以“...”结尾；以前这个功能需要用服务端程序来实现，而且还挺麻烦的……

Throwing Tables Out the Window 0 条评论

这是一篇翻译自 blogger.com 的新版网站界面设计者 stop design 网站的文章，如果对原文感兴趣，可以访问 Douglas Bowman 的英文原著。

如果您对本译文有任何疑问或者意见，请直接对本 blog 文章发表评论，或者给我发送电子邮件。

文章摘要

很多网站已经对 CSS 这片海洋进行了深入充分的测试，现在我们从水底开始欢呼的时候到了，让我们奉劝并鼓励那些还没有跳下水来的人，赶紧加入我们的行列。现在已经没有任何理由继续用表格来排版，也没有理由为不同的浏览器维护同一个网站的多个版本。赶快把表格扔掉吧，相信我们，你不再需要它们了！（译文：巴西葡萄牙语，丹麦语，法语，德语，意大利语，日语，西班牙语和土耳其语）

Throwing Tables Out the Window

妈妈快看，没有表格哟！

那些参加了今年在西雅图的 Digital Design World 的朋友们可能看到我主持了一场题为“No More Tables, CSS Layout Techniques”的讨论。在讨论中，我们回顾了一下表格的正确用法，以及一些用 CSS 来达到同样目的的方法。然后我们转向无表格排版，列举了一些范例并概括出两种基本的途径：控制位置和悬浮（positioning and floats）。

讨论进行到一半的时候，我改换了风格，宣布我们将就现实中的实例，实现从表格和占位 GIF 图片的排版方式向纯 CSS 排版的转换。我原本可以设置一个虚拟的例子用在讨论中，但是这个看起来会显得非常做作。如果我设置了我自己的例子，它看起来可能会显得漂亮整洁，所有的一切都会被按照我想象的那样被渲染，会避开所有我已知的问题点。
虚拟的还不够好，我要向真实的案例挑战。所以我选择了一个为大部分听众所熟悉的西雅图本地的小公司：

OK，大概并不只有一部分听众熟悉这个并不那么小的公司。很多用户每天都要登录微软网站的官方网站，不管它是不是像搜索巨头 Google 以及 Yahoo! 那样出名或者被经常用到，勿庸置疑的是，每天有数以百万计的用户访问 microsoft.com ，它为我们的互联网带来了极大的流量。

遗憾的是微软并没有竭尽全力优化她的网站。用户下载着不必要的大型页面，服务器为了支持他们浪费着额外的带宽。对于 40KB 来讲，微软首页的 HTML 还算不上是洪水猛兽，但是它负担着无法访问的、七拼八凑的、基于表格并充斥着各种属性的标记，以及一些笨拙的 JavaScript。注意我并没有提到这些是不是有效的标记。尽管它采用了 XHTML 风格，但是微软在其页面上漏掉了 doctype 声明。

为什么是微软？

这是不是仅仅另外一次对微软的挑剔？

直率地，诚恳地说，不是！

我选择微软并不是为了跳上时尚的抨击讲坛，或者向业内人们喜欢讨厌的公司多扔些鸡蛋。（我从未放弃任何机会来置疑微软做出的某些决定，但是我总是避免指责。）

我承认我有意地选择并锁定了一个备受瞩目的公司，我天生喜欢追逐领头羊。不过，作为范例，大部分人都熟悉她。microsoft.com 曾经是（现在仍然是）完美的 CSS 标准改造候选者。

以下是原因……

原因 #1

因为它低效率地用大量的表格和占位 GIF 来排版。当内容用表格进行排版后，页面的兼容性会更差，甚至无法访问。并不只有微软有这个问题。目前网络上绝大多数的网站仍然使用大量的表格用于页面排版，或者其它纯粹的视觉目的。我选择微软的网站，是因为它和很多其它网站有着同样的问题，而且它可以作为一个著名的范例（甚至最后成为模范）。

原因 #2

因为微软网站首页当前设计的基本结构和成千上万的网站的设计有着共同的模式：页眉 + 3 栏 + 页脚。进一步讲，页眉横跨整个页面上部，左栏主要包含导航系统，主栏放内容，右栏提供额外的资料，然后页脚在三栏下面同样横跨整个页宽。即使不是三栏式排版，很多网站也可能使用和这个结构类似的二栏式排版：一个边栏放在主栏的左边或者右边：

原因 #3

因为微软的网站对 CSS 的利用，仅限 FAC （字体和颜色）。我更希望看到这个曾经在应用环境下发明了样式表基础理论的公司，更偏重于 CSS，而非旧的方法。

原因 #4

因为目前微软根据浏览其网站的浏览器的不同，提供网站的不同版本。一个提供给 Windows 的 Internet Explorer (v5.5 及以上)，另一个什么 dumbed-down 的版本提供给所有其它的浏览器（包括 IE 和 Mac），它省略了一些图片，以及所有的产品徽记。这个非 IE/Win 的版本去掉了一些功能（如弹出式菜单），并用不同的技术来渲染页面元素。如果您有 IE 5.5 或以上版本，以及另外一个浏览器，您可以自己查看。如果没有，以下是两种不同版本的屏幕截图，并用红色的圈标出了不同的地方：

非 IE/Win 的版本和为 IE/Win 提供服务的版本相比，明显简陋得多。我们都知道它其实并不需要这样。这并不只是在某些浏览器上能够工作而在其它的浏览器上却不行的草率代码。微软故意做了一个 JavaScript 浏览器探测，当浏览器是 IE 5.5 或更高版本时，它会将浏览器重定向到另一个页面上。其实，微软可以只维护一个能够运行在所有浏览器上的版本。

微软还只是为非 IE/Win 的浏览器用户提供了其网站的另一个版本，有些开发者所做的可能远不止这些。一些网站放弃对其它浏览器提供支持，我们听到的最多的原因是 MSIE/Win 被绝大多数用户使用，同时为任何其它的浏览器提供正确的页面会花费太多时间。有些则抱怨说为 IE/Win 之外的浏览器开发太昂贵。其实，“太多时间”和“太昂贵”的说法并不成立。

很多开发者相信这些说法，因为他们是从为 IE 开发——并在 IE 中检查——开始的。当他们用另一种浏览器来查看的时候就会感到沮丧——他们看到各种各样他们认为必须去修正的 bug。

IE 和其它在近两年不断升级版本的浏览器（Mozilla、Firefox、Safari、Opera……）相比，对 CSS 的理解更加松散。从 IE 开始开发，意味着在开发早期发现的问题会更少一些。先在 IE 上开发，然后尝试更新支持其它浏览器，从长期来看这将增加时间和金钱的消耗。但是，我们有一个更好的办法能够更快更省钱的解决这个问题。

从更严格的浏览器开始开发，这些浏览器通常按照它们应该渲染页面的方式去渲染。先让页面在这些浏览器上运行正常，然后再回来为 IE 做一些“修补”。用这种方式，开发将快得多。虽然初期这样会让页面在您流量分析中出现得绝大多数浏览器上不太直观，但是如果您并不打算习惯——或者依赖——IE 松散的渲染行为的话，这个开发过程要流畅和有效率得多。从 IE 开始开发，您可能会花费更长的时间来修改开始的代码，以便适应更严格的浏览器。

走这条路，我们仍然有 IE 方面的问题需要关注。但是，当我们有了更多关于 IE 错误的 CSS 渲染行为的经验后，IE 方面的问题从一开始就降到最少，这是肯定的。

请说事实

在讨论的后半段，我们从头到尾地经历了将微软基于表格和占位 GIF 排版的页面，转换为更容易访问的、纯 CSS 驱动的版本，使其能在任何浏览器上运行。这并不新潮，以前已经有人对 microsoft.com 进行过重新编码。本站一些常来的读者从事无表格的设计到现在已经一年多了。尽管 CSS 海洋的水已经被公平的全面测试过，但是我们仍然没有看到更多的人跳下水。因此有了 Digital Design World 上的讨论，有了这片文章。

在接下来的讨论中，我们将每个环节分成容易操作的若干个小块。我指出了过程中的主要步骤，包括去掉表格，将它们转换成更容易理解的标记，以及用来忠实重现微软首页设计每一个环节的 CSS 技术。

在整个讨论过程中，我们每个环节都演示了很多形象的东西（图示、截屏、统计图表等）来帮助理解这些渲染技术。我也预先准备了在每个环节需要的文件代码。

撰写此篇文章的其中一个目的，是为了发布对 microsoft.com 进行改造的最终结果，看起来有点让人难忘：

	当前设计 (IE/Win)	当前设计 (其它)	改造后
使用表格	40	36	0
占位 GIF	35	76	0
总 <img> 标签	43	122	6
CSS 背景图片	1	1	11
浏览器支持	2	Most modern	Most modern
HTML 文件大小	40 KB	39 KB	15 KB
文件大小减少	-	3%	62%

更多

当我们开始进行 Meyer/Davidson ESPN-style 评价和设计时，这些数字变得更加有趣了。在微软一篇公开的题为“Inside Microsoft”的网页上，微软公布了其流量统计：mocrosoft.com 在 2004 年 5 月获得了 12 亿次的 page view。在以上的讨论中，我显示了如何减少一个页面 62% 的标记，或者说 25 KB。我也同样预言了如果微软能够在整个网站上更加积极的应用 CSS，每页面 25KB 是一个公平的估计。如果乘以平均每天 3870 万次的 page view，每页面 25 KB 的减少每天可以为我们节省约 924 GB 的带宽，也就是每年 329 terabytes。

光凭这些数据，就应该足以让一些人回头。

现在，回到现实中，我们改造的仅仅只是一个版本，但这种改造仍然支持微软更多“高级”的设计（就像现在在 IE/Win 中看到的那样），在很多其它流行的浏览器中仍然如此。

不管像微软这样的公司是不是需要只维护其主页的一个版本来支持所有的浏览器，来提高页面加载速促，来使其更容易被所有的用户和设备所访问，我觉得值得指出的是，现在非常容易的展示他们——或者任何公司—— 能够创建一个高级的版本，使用更干净的标记，能支持更多的浏览器，能更容易地被访问。所有的展示花费不过一两小时。

更多要点和警示

• 如果您感到好奇，并且想更仔细一些，CSS 在改造过程中对原版本仅仅增加了 3KB / 5KB（分别对应 IE/Win 和非 IE/Win 版本）到 8KB。
• IE/Win 版本左侧导航中两个选项所带有的弹出式菜单一样可以被重现。所有这些都由纯 CSS，简单、易懂且更容易访问的标记实现。当鼠标悬垂到列表父列表条目上时，改造版本用 :hover 伪类（pseudo-class）来开关一个内嵌的无序列表（子菜单）。考虑到 IE 在列表条目上不支持 :hover，所以为了在此浏览器上支持弹出式菜单，微软正在使用的 JavaScript 仍然是必要的。或者类似于 Suckerfish Dropdowns 的东西能够用来保持和改造版本所使用的同样易懂的内嵌列表标记。
• 微软当前的非 IE/Win 版本上如此大的图片标签缩减主要是来源于占位 GIF 的滥用。另外，非 IE/Win 版本单独调用所有列表强调符图片，而不像其 IE/Win 版本以及改造版本那样，通过一条单独的 CSS 声明来调用。
• 微软网站上能够找到的所有 JavaScript 标记都被移除了。链接元素上成百上千的属性标记显然是出于点击追踪目的。Microsoft would likely want to add some of this layer back in - though hopefully through a valid means of doing so.
• 正如前面提到的，此文的目的是为了公布使用 CSS 和更简单的、易懂的标记来构建页面所带来的潜在结果和益处。我们仅仅用微软作为一个注明的范例。此文有意没有给出改造后的代码。我明白很多人能够从本次演讲讨论的成果中学到东西。即使没有参加演讲，也能够从对 HTML 和 CSS 代码的修改上获益。但是，我无意通过公开发表对源代码的修改来贬低任何人在微软的角色。我更倾向于有机会能够直接将它们展示给微软，与合适的团队成员讨论这些改变以及相关技术，如果他们愿意这么做的话。