ppk曾经说IE的传统盒子模型比W3C的定义好理解，但为什么IE的盒子还是比W3C的糟糕呢？因为IE盒子的定义连IE盒子的支持者自己都搞不清楚。与文中所述相反，IE盒子并不包括margin，而只是纯粹的计算padding与border的占位。为什么IE传统盒子这么烦？因为需要反向推导一个盒子的内容宽度，而浏览器渲染时期望尽快知道内容的宽度。再有，IE传统盒子硬是把微软自己的开发团队都搞晕了，有些bug还穿越出现在标准模式下，哦，你不知道IE6的标准模式使用W3C的盒子定义？

支持IE传统盒子的同学，没有为IE5.x开发过的同学，请你考虑这个问题：如今CSS3支持图片border了，使用IE盒子模式，浏览器应该怎么计算内容宽度？CSS3是为设计者方便提供帮助，请不要以box-sizing为借口，为IE5.x的顽固不化辩护。

延伸阅读：

• Internet Explorer and the CSS box model

• The Box Model Problem

• Box model tweaking

• Internet Explorer box model bug

return “SOCKS 127.0.0.1:8001; DIRECT”;

这个设定看起来很美，SOCKS挂了的话选择DIRECT模式继续。然而实际情况是怎样？若存在多个选项（例子是SOCKS和DIRECT），对SOCKS是否响应的测试，WinINET库只会做一次（若有Load Balancing功能，对代理的选择应是RR）。也就是说，一旦前面的SOCKS端口关闭，所有请求均使用DIRECT模式。即便再启动端口，请求也不会走SOCKS（直到程序重启）。除非你能保证SOCKS 100%响应，否则别加入DIRECT为后备选项（单独return可以）。

另外，Google Chrome对File://协议的支持依旧是浮云，如果你使用本地PAC文件（Chrome使用IE的设置），会出现在IE中没问题，Chrome却不读取PAC的状况。Opera 10读取本地PAC文件亦有问题，至少我没成功过。

最后，WinINET不支持SOCKSv5，这代表着它不支持UDP层查询DNS的功能，修改HOSTS表或把Lookup请求用软件Forward到SOCKS端口上才可实现远程DNS查询。更诡异的是，Chromium的人知道WinINET的弱点之后，自己开发了一个独立的HTTP stack，支持SOCKSv5，却没有实现UDP层，于是也不支持DNS查询。前后不是人。

如果你真的很在意SOCKS，延展性极强的Firefox依旧是你最好的选择。以上。

更新：Chrome需要用Flag来设置，Lookup如前文所述，依旧提交至本地设置的DNS（IE默认），而非远程。h/t to est.

我祝你永远别被我的统计学导师遇上，否则你一定会被他往死里批斗。你连续两次发布所谓的Failure Curve图表，不仅缺乏实质统计意义（”The data is based on snapshots taken 50 days after each IE8 pre-release”，你们把每个发布版本的错误报告重叠起来干什么），更是利用条状图迷惑读者（事实上，”To date, we have fixed 80% of all the reported crashes and hangs in IE8″，还有20%的错误报告没能解决），让笔者怀疑你是怎么当上微软产品经理的。没有价值的文章请你找PR的人去写，读起来至少动听些。

IEBlog的作者们，请不要再写这种伪技术文了！

不是看条目，是看Google Reader有多少条目未读。我现在读日本宅文的感想是完全无所谓，哦，新番发布，哦，宅人跳舞。so what。

经济不好自然影响到动画界了；事实上Gonzo的文章我都写好了，就差重读和插入图片。

IEblog又开始抽了，一边教读者使用CSS Filter的最大问题是什么，一边展示W7下的IE8程序错误不完全由IE8造成。一篇用于辩解IE8赶不及支持已存在数年的W3C标准opacity，后一篇图片的横轴不标记程序错误的分类，看完也不知道IE8错和不错在哪。两篇文都是扯淡。

写插件当天的浏览器访问，真希望天天这样。

24ways看到这里，有三篇文章比较适合客栈的潜水设计者，一是加速多页面开发的Polypage简介；二是华丽的网络文字排版术；三是实用性较高的绝对纵列。如果你在海外做收费设计，一定要看IE6换算公式；在国内就免了，只有等微软推IE8和新OS，或者等IE6的技术支持过期，制作终极IE6病毒（哈哈，哈哈哈，哈哈哈哈哈哈哈哈哈哈哈哈哈——Joker模式）。

IE8 RC1 scores 12/100 (the same as IE8 beta 2), which clearly will disappoint web designers and developers that heavily use CSS… For sake of reference, IE 7 scores 12/100 just like IE 8. To be fair, that number increases to 21/100 in IE8, if the window is left open for an extended period of time (several minutes).

这不是新闻。我没有跟踪IE8的新闻有一段时间了，今天难得一看就是这样的消息。顺便一提，IE6也是这个分数。我想明年初又要将conditional comment换成if lte IE 8了。

via slashdot

BTW，要IE支持属性选择器，一般使用javascript框架来虚拟，或者用Dean Edwards的IE7与IE8库来修正。

既然客栈已给IE7，Firefox 2/3，Opera 9和Safari for Windows等等浏览器做过评测，支持平等机会的我们没理由放过Google Chrome，这款10岁网络霸主的新beta产品。为增加娱乐性，我们决定通过各浏览器亲卫队最喜欢也最鄙视的大乱斗解决：Google Chrome 0.2 vs Firefox 3.0.1 vs Internet Explorer 7 vs Opera 9.52 vs Safari 3.1.2 for Windows！高潮迭起，请勿错过！¹⁾

回归正题，相信浏览器爱好者们已经非常清楚几位老选手的底细了，这里只介绍新人“股沟鸽”的内涵配置。

Google Chrome （ver0.2.149.27）

• 页面渲染引擎：WebKit/525.13（Safari 3.1.2使用WebKit/525.21）

• 图像渲染引擎：Skia（Google自行开发，还缺乏部分功能，例如text-shadow和border-radius）²⁾

• Javascript引擎：V8（Google自行研发，适合运行结构性强的JS代码） ³⁾

FF，IE，Opera和Safari的支持者，看清楚对手的嘴脸了吗？让我们进入第一个环节。

技术测试

中文网络上的用户体验实在是多如牛毛，个人感想到底没什么说服力，还是先上测试大餐对得起观众。

Javascript 引擎测试

Google Chrome浏览器内最前卫的莫过于他们独立开发的Javascript引擎：V8。在他们自己制作的速度测试上Chrome以超过Firefox 3和Opera 9.52数倍的成绩完成任务，更不用提众矢之的的IE7了。

然而V8的benchmark是否有足够代表性？Google有没有刻意夸大V8的实力呢？让我们用客栈自食其力的实证主义精神来判断。我们选择了如下几个Javascript引擎测试——

• 来自mootools开发者的Slickspeed，测试浏览器运行主流JS库各种selector的速度。与DOM有关。

• 来自Celtic Kane的JS Benchmark，测试运行简单对象，内置函数与DOM的速度。

• 来自Google的V8 Benchmark，有大量的递归函数，纯粹JS引擎测试，无DOM。

• 来自WebKit的SunSpider，测试各类函数运行，纯粹JS引擎测试，无DOM。

• 来自PPK的DOM vs. innerHTML Benchmark，本用于研究不同元素生成方法的速度，这里用于测试浏览器的DOM渲染能力。

• 来自Mozilla和jQuery开发者的Dromaeo V2，测试从内置函数到主流函数库等等实际浏览时会遇到的运算问题，包括大量有关DOM操作的测试。

Slickspeed

对于轻量级网站的JS代码开发者来说，如今几个主流JS库的速度决定着网站的速度，因此在JS库DOM最基本的组成部分——selector上下点功夫测试绝非奇怪之事。

详细测试数据

在该测试中Google Chrome并没有什么优势（和Firefox3相近），反而让传统的强者JavaScriptCore（Safari）和Opera的新引擎 Futhark拿到头彩。各位自行做测试就会发现，每款浏览器都有自己特别不擅长的selector模式，这和对应JS库的具体实现方式有关（因此不同浏览器的返回值出现分歧的selector也不同）。

JS Benchmark

只包含少数几个对象/函数的loop检查，缺乏实际应用性；测试Javascript引擎运算能力和特定的DOM。

详细测试数据

Google Chrome再次败阵，原因在于V8引擎就算对简单的函数构造也会毫不含糊的重复新建/修正“隐藏类”，导致速度大大减慢。使用内存字典搜索的Safari，Opera乃至Firefox会更快。

V8 Benchmark

详细测试数据

回到Google自己制作的benchmark上，4个测试的统一特质：递归函数。只要指定类型的对象属性没有被更改过，V8就能再利用与之挂钩的隐藏类，直接生成machine code stack，免去耗时的搜索内存的步骤。V8 Benchmark就是在假设甚少对象属性变更的基础上设计的，因此对Google Chrome相当有利。

SunSpider

详细测试数据

SunSpider是一款相当出名的Javascript引擎性能测试，由于它囊括了各方面的纯引擎测试，是许多浏览器开发者的首选。Google Chrome二次夺冠，但这次它的领先幅度缩小很多，V8的杀手锏“隐藏类”为它在前四个部分（尤其是测试递归的controlflow）取得了决定性胜利，但在其他区域Chrome的优势明显较弱，甚至被其他浏览器反超。

DOM vs innerHTML

详细测试数据

这时我们猜测Google Chrome的弱点可能在于它DOM Manipulation的速度。遂选择了PPK制作的“内容生成”测试。简单的DOM测试证明Chrome的速度介乎Firefox 3与Opera 9.5之间，V8的优势在重复利用对象的JS运算上才能得到充分体现。

IE7的数据有点惨不忍睹。

Dromaeo V2

最后这个测试围绕着Web 2.0时代进行，不管是内置函数还是外挂函数库，都少不了为DOM服务的，而DOM也是大多数浏览器最慢的部分。因此除了纯粹的引擎测试，Dromaeo V2还有大量的DOM和渲染被加入（IE7实在太慢，没法完成测试）。

详细测试数据

Chrome没能获得第一，但表现得比Firefox和Opera要稳定（后两者都有特别慢部分，导致得分偏低）。

引擎测试小结

Google Chrome的V8是个相当独特而优秀的引擎，它考虑到了Javascript代码开发的趋势，为复杂的JS框架/Web2.0服务量身定做。它目前问题是DOM渲染并不突出，这就好比欠了东风，让Chrome还是火不起来。对于国内的用户来说，Gears插件节省的页面读取时间或许比V8的优势明显得多，不过这是题外话了。

Flash插件，启动速度，内存与CPU占用

在网速较慢的中国，对Javascript运行速度的要求或许不如国外高（JS上争取到的1-2秒相对网速的缓慢不过是小巫见大巫）；在国内，对Flash插件的兼容性，浏览器耗费内存与CPU的度或许才是用户最注重的项目。

Flash

Flash插件的好坏一直评判是浏览器流行程度的指标，IE的ActiveX插件始终比其他使用NPAPI插件的浏览器要快，这也是为什么IE还在嚣张的原因之一。

Google Chrome也和多数开源浏览器一样，使用npswf32.dll作为插件。有鉴于Safari for Windows是个电脑杀手，我们特别在意Flash插件与谷歌浏览器的资源消耗。

测试一号

Google Chrome vs 所有使用npswf32.dll的浏览器；我们使用禁用了ActiveX插件的IE7作为基准。

上图中的所有浏览器都打开了1个主窗口，5个标签页分别运行着纯文字页面、多图片页面、Javascript高需求页面、Flash影片页面和我们自己的标准站。结果是Chrome的多进程系统耗费最多内存，133MB；Safari以107MB紧随其后，Opera和Firefox只是使用了 80MB左右；没有Flash插件的IE7更是用了不到56MB。

接着我们关闭了使用Flash的页面，让浏览器自行释放内存。这时Safari for Windows的问题显露无遗：它无法释放Flash插件占用的内存，这也解释了用Safari上新浪网（Flash广告海）就假死的原因。所幸的是 Google Chrome并没有类似的问题，但它仍比其余两款浏览器使用更多的内存——Chrome为避免单一标签页崩溃就殃及整个浏览器的问题，将每个标签页的内存单独处理，间接导致内存占用增加。Firefox/Opera表现正常。

最后是将所有标签页关闭，清空缓存后的结果。Google Chrome的Sandbox表现相当出色，配合V8的垃圾回收，基本恢复热启动时的内存占用量；Firefox的内存管理不比Chrome逊色，也接近了冷启动时的初始值（30MB左右）。Opera 9.52的73MB可以接受，虽然远超过20MB的启动内存，但它在浏览页面的过程中一直只占用70~90MB内存的特性让我们猜测它有独特的内存管理。最后是Safari，呃，也就是如你所见了。值得一提的是IE7的内存也迅速降下来了，微软毕竟不是白吃饭的。

测试二号

将Flash ActiveX插件与npswf32.dll平行对比，Google Chrome vs IE7的战斗。参照浏览器为Firefox 3。

同样的环境中，IE7果然比Google Chrome少占用内存，算上IE与explorer.exe共用的内存，谷歌的浏览器还是超出10MB有余。

作为对比，以上分别是在浏览无Flash页面和热启动时的内存监视，Firefox和IE7的内存占用都与Chrome相近……可预见今后浏览器性能大战的获胜条件将少不了来自Flash插件的良好支持。

小结

我们认为Google Chrome对Flash插件的支持达到或超过了Firefox/Opera的水准，代价是运行时的内存耗费比较大；另一方面Flash的ActiveX插件版仍有绝对的性能优势，有鉴于Google扼杀AIR和Sliverlight的决心，我们不认为Adobe会特别关照Google Chrome。

启动速度

准确测试有难度，只凭我们的观察为准。

冷启动耗时：Opera 9.52 < Google Chrome 0.2 < Safari 3.1.2 « IE7 < Firefox 3.0.1

热启动耗时：Google Chrome 0.2 =< Opera 9.52 =< Safari 3.1.2 < Firefox 3.0.1 < IE7

内存和CPU

为排除Flash插件和Chrome多进程的干扰，我们选择之前使用过的Dromaeo V2测试，因为它很耗CPU和内存，而且无需Flash支持。结果如下——

首先是空闲时的内存占用，220MB。

Google Chrome一度使用接近400MB内存，因为Sandbox的关系单个进程（标签页）的CPU占用不会到50%以上。双核使用不平均的问题估计在实际浏览中不明显。

Firefox的CPU分配很平均，减低了单独CPU的压力，但在CPU吃紧时会影响到其他程序的运行。Firefox 3在Javascript上的内存管理已经有长足进步，最多时只使用200MB内存，没有发现leak（这些JS库也有避免内存溢出的预防措施）。

Opera是相当奇怪的浏览器，它在运行JS时基本只使用一个CPU（会完全占用，即50%），我相信这是它速度较慢的原因。它在运行繁重JS时的内存占用较高，一度上升到450MB。我们的Opera 9.52在渲染Dromaeo V2页面时有bug，所以无法判断这个测试的准确性。

Safari for Windows 3.1.2的内存管理很糟，全无下调的趋势，最后停滞在500MB；相反它运行JS时的CPU占用率很低，我们甚至可以开个Winamp听歌兼用 Thunderbird收发邮件。另外别忘了，JavaScriptCore在本测试轻松获胜。

小结

Google Chrome用内存换速度做法在beta阶段会很受欢迎，相信不少人会成为Chrome的用户；而它的快速启动和每个进程只占用5~15%的CPU的特性，也比其他浏览器更为讨好（在我们的系统上没发现稳定性问题）；但要作为用户每天使用的浏览器，Google Chrome还需要考虑得更多。

使用体验

Google Chrome的不少独特设计都是双刃剑，我们会从多方面考虑。

菜单

Chrome是5款浏览器中唯一一款完全没有顶部菜单的，这对于熟悉浏览器通用快捷键的用户来说是亮点（例如Ctrl+B的收藏夹/书签，Ctrl+H的浏览历史等等），对于没这么擅长浏览器操作，喜欢通过顶部菜单寻找功能的用户来说则是烦恼。我们估计早期换用Chrome的用户会相当喜欢这种设计（这种设计类似IE7隐藏菜单栏后的设计）。

另外由于没有顶部菜单，Chrome不得不将所有功能置入右侧仅有的两个菜单按钮里，目前的还不算拥挤，今后Chrome功能增多时该怎么办，还需开发者挖空心思去解决。

标签页

Google Chrome的标签页与地址栏的位置关系与大多数浏览器相反，处于最顶部。习惯了各种标签页设计的我们并不觉得陌生，加上Chrome的标签页操作和其他浏览器几乎一致，早期使用者不应感到特别不适。

此外，Chrome从Safari身上学会了经典的标签页/新窗口互换技能，两款浏览器都能将标签页拖成新窗口，也允许新窗口之前互换标签页；Google Chrome可以将新窗口逐个恢复成标签，Safari则有融合所有窗口为一个的功能。

导航/地址栏

这大概是任何浏览器最显眼的部分，Chrome的设计没啥特别，一键添加书签的功能也与Firefox3雷同。另外Chrome的地址栏为减少页面欺骗，会突出显示页面的所在域名；IE8也已加入这种显示。

莫名其妙的是右侧箭头——Google假设用户知道如何输入地址，却不知道地址栏可以回车确认？这明显是为IE6的最初级用户设计的。

边侧栏和状态栏

Google Chrome没有边侧栏，他们的书签只使用顶部空间，类似其他浏览器的书签栏；其他功能均使用整个标签页。它亦没有状态栏，链接会以渐入渐出的方式在右下角提示；可预见今后的插件控制是个问题。

此外Google Chrome是不会完整显示长页面标题的，这可能会造成一定困扰。

有趣的新功能

以下是我们没能在其他浏览器找到的新功能，他们不一定都有用，但至少给用户耳目一新的感觉。

内置任务管理器

不少浏览器都有自己的内存/CPU占用/带宽检测功能，但Google Chrome是第一个提供内置GUI任务管理器的浏览器。对于浏览器性能痴迷者来说是一大喜事。

搜索定位

一般的浏览器只会在页面上高亮（通常是黄色）搜索文字，Google Chrome更进一步，在右侧滚动条上显示搜索关键词出现的大概位置，这对于长页面和Ctrl+U的代码浏览器来说很有帮助。

隐身窗口的幽默感

隐身窗口并不是Google的创意，基本所有浏览器都有控制Cookie，密码和浏览历史加载的方法，Chrome只是将这个功能作为重要功能摆上台罢了（Google Chrome缺乏用户的管理和保护，对于公共浏览器来说提供隐身窗口功能是满足基本需要）。不过隐身窗口的对自己解释却给我们网络小公司的幽默感，让人暂时忘记了站在浏览器身后的渐渐满口官腔，越发渴求利益的Google。

明显弱项

1. 缺乏高级书签管理，就算能导入书签还是不好用。

2. 长页面的文字选取很慢，说起来，页面滚动也不怎么流畅。

3. 默认保护过强，当页面有链接指向或图片来自受感染的域名，该页面也会被禁止。

4. 无可切换全屏模式。

5. 任何杀广告的插件，用本地proxy过滤不算；谷歌在这方面一点都不急。

6. 通过GUI禁用特定插件，而不是要用快捷方式的启动参数。

7. 清除浏览数据时不会记忆上次的选项。

Google Chrome FAQ

Google Chrome虽然是开源，缺乏记录的部分却很多，这里我们把客栈整理到的信息归纳一下。

关于隐私

Chrome与Google服务器通信的方式很多——

• rlz.dll

• Metric_Service

• 搜索建议(Omnibox)

• 其他

由于Google拥有的用户信息已经多得吓人，随着他们逐渐变味的隐私保护⁴⁾，让人不禁怀疑Chrome是否成为Google的开源后门，为此我们也专门去看看了源码的解释。

rlz.dll

这个位于0.2.149.27(版本号)文件夹下的dll负责记录/发送Google合作产品的信息（通过访问特定的注册表位置），目前它只会每间隔 24小时发送Chrome自身的升级情况，首页和默认搜索是否为Google等信息到Google的服务器；至于今后rlz是否会发展到收集其他 Google软件的信息，只能拭目以待（代码设计预留了扩展空间）。

由于rlz会用这些注册表信息生成一条字符串，并在默认Google搜索时加入到查询语法中（rlz=），也让人怀疑Google是否在收集用户习惯，即便Google声称这些信息不能用于分辨用户身份。

rlz.dll并非浏览器进程必须的库，可以移除。

Metric_Service

这个服务并不是Google的原创，它一直是Firefox的官方扩展之一，只是不包括在下载包之中罢了。Google Chrome借用了Mozilla的Browser Metrics代码，打造了自己的Metric_Service，将收集到的信息发送到这个地址（直接访问会出现无效SSL证书的问题，强行接受证书就可以看到使用以下namespace的XML回应）

http://www.mozilla.org/metrics

这符合Mozilla官方的数据规格。按照Mozilla自己的说法，这个服务可以收集从浏览器设置，安装插件，特定URL到硬件设备等等基本信息，某种程度上是对用户隐私的侵犯。因此Chrome不用安装Google Toolbar也能达到统计用户使用数据的目的。

目前Metric Service可以通过禁止Chrome发送统计信息和崩溃报告来阻止（在高级选项中）。

搜索建议(Omnibox)

只要不关闭搜索建议，并使用Google为默认搜索引擎，Chrome就会尝试建议关键词，这是通过向Google服务器提交信息得到的结果，自然也会让Google得到你输入的关键词（即便没有回车输入）。

搜索建议可到“选项”的“基本信息”的默认搜索中关闭。

其他

Google Chrome会定时更新不安全网站列表，下载拼写检查字典等等……

另外，跟随Google Chrome一起安装的Google Update会长期进驻系统（作为Win32服务），定时检查软件更新和提供一键安装的功能；没有正常的反安装功能，移除该程序比较困难。

使用免安装版Chrome可以省去移除GoogleUpdate的麻烦。

关于移动版

制作绿色/免安装版Google Chrome非常简单，只需要复制位于以下文件夹的所有内容即可。

Documents and Settings\username\Local Settings\Application Data\Google\Chrome\

制作Portable（可携带版）的Google Chrome比较麻烦，由于Google Chrome缺乏用户管理，目前它的默认用户被锁定在

Documents and Settings\username\Local Settings\Application Data\Google\Chrome\User Data\

必须新建快捷方式，加入–user-data-dir参数来设置用户账户的位置。 ⁵⁾

或者等待专业人员编译使用相对路径的Chrome。

关于谷歌的计谋

普遍认为Google Chrome的目的首先是打击IE的市场份额，让Google在提升基于Javascript的服务的复杂性时少些阻碍。^{6) 7)}

让Google花这么多人力去开发新浏览器的理由有不少。

减缓AIR和Sliverlight的崛起

javascript毫无疑问当今Web 2.0时代的网络服务的重要组成部分，以提供网络服务吸纳用户的Google绝对希望这种趋势维持下去。无论JS作为客户端语言的路还有多长，V8引擎的出现必定会掀起又一次浏览器JS引擎提速战，这对javascript的延年益寿很有帮助。

相同道理，javascript的持续流行将打击其他商业化产品，例如Adobe的AIR和微软的Sliverlight。网络服务还要依赖装机量为生有很大的风险，当大多数网站都选择了javascript，对AIR和Sliverlight的普及自然造成影响。

至于今后javascript是否能成为主方向，就得看标准的发展和Google Gears的应用范围了。

对微软的将军抽车

微软讨厌今天的javascript，这是毫无疑问的，它灭了vbscript占领网络的美梦，还老是给IE带来负面新闻。但Google Chrome将成为微软的下一个心病——如果微软选择维持IE8的JS引擎速度，则Chrome的傻瓜设计有可能对IE今后的市场占有率造成严重打击；即便他们将JS引擎速度提升到Chrome的水准，和Google打浏览器大战，也会间接帮助了Google的网络服务（尤其是和MS Office与Live服务争锋相对的服务，Google Docs，GMail等等）。

和Google Chrome对战这并非微软的意愿，他们最大的市场——企业局域网，并不需要这么平凡的浏览器升级。

为保IE和Office这些老将不死，微软的车——“漫长的开发期”和“践踏网络标准”两张王牌必须倒下，微软也将不得不在网络上与Google决胜。

真正的“云”，是用户群

我们曾经说过，任何用户信息对于Google来说都是宝贵的。随着互联网发展，要从用户得到涉及隐私的信息越来越难，随着各大开源浏览器的崛起，Google工具栏的吸引力日渐降低，Analytics则是以“站”为中心的服务，Google排名需要新的用户数据来填补这片空白。Google 的答案是发布开源浏览器，再次打开用户上缴个人信息的渠道，事实上，没什么比获得用户的第一手数据对排名和创新更价值了。

Google花费了不少心血，从开源的Firefox与Safari上习得了经典的技能，配合自己的名气，刚出炉就迅速抢占浏览器市场，也算是他们支持Mozilla多年得到的回报之一；今后Firefox的增长是否也会因为Chrome的出现而减缓，我们只能等待结果到来。

杂项

一些与谷歌浏览器有关的小知识⁸⁾

关于标签页

同网站打开的标签通常共享内存，这是为了让javascript能跨页面响应。同时Google Chrome并不能关闭标签页功能。

关于Google Update

安装Google Chrome时一并装入的Google Update还会在Firefox内加插一键更新的插件，如果你不喜欢Google这种走后门的做法，可到注册表的以下地方删除它。

HKEY_CURRENT_USER\Software\MozillaPlugins

或

HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins

删除@google的那个插件即可。

尾声

Google Chrome的确是浏览器市场的一股新风，性能和操作简易性上已让不少人折服，再加上可总结为Hey, it’s from Google!的用户信任度，这热潮恐怕得再刮一阵。

至于客栈，我们已经习惯了Firefox的强大延展性，加上Chrome缺乏书签管理的这个弱势⁹⁾，谷歌还不能成为我们首选。另一方面，别忘了Firefox 3.1和Safari 4都将各自有新的JS引擎，想超越V8并不困难¹⁰⁾，而Opera 10和IE8的出炉又会给这场战斗带来更多不可预计的因素^{11) 12) 13)}……Google还不能笑得太早。

暂时只有这么多，如果有什么新信息会继续加入。

¹⁾ 不使用IE8 beta2的主要原因是它的内存占用太夸张了。 – IE8 Beta 2 Fatter Than Firefox and XP

²⁾ Flickr – Google Chrome vs Safari 3.1

³⁾ V8 – Design Elements

⁴⁾ Google and Privacy: A History

⁵⁾ 谷歌浏览器 Google Chrome 免安装绿色版！

⁶⁾ Mozilla’s Thoughts On Google’s Chrome

⁷⁾ Inside Chrome: The Secret Project to Crush IE and Remake the Web

⁸⁾ Google Chrome Tips and Pointers

⁹⁾ 谷歌有“将功能留给网络服务，浏览器不应太复杂的解释” – A fresh take on the browser

¹⁰⁾ JavaScript Performance Rundown

¹¹⁾ Beta Browser Speed Tests: Which Is Fastest?

¹²⁾ Chrome Vs. IE 8

¹³⁾ Google Chrome, Day 2

原Wiki版地址（需要登录）：Google Chrome « 捏它营 / NetaInn

难得写一篇与本人正业有关系的文章——你有权说“用某某浏览器的飘”，但你说的话将成为Akismet的Spam证供。

假设你的系统是Windows，假设你用IE，假设你允许Javascript，假设你安装了Flash……如果你以前不理解为什么店长在看到类似Pixiv的网站时泪流满面，你现在该体会到了。这是拥有再多带宽，再多电子产品都无法“获得”的知识，只有当网页开发者真正开始考虑用户体验时，他们制作的网页才不会像某些烂动画一样，只能被少数人所欣赏。

说起来，3月比特客栈的IE用户下降至65%，IE6（包括那些用IE Shell的人）只占30%左右了。很好，店长希望能在两年内将IE6的访问比率降到5%左右，当前IE6用户看到的那些升级劝告是第一步。

更新：本文的争论告一段落，3月初在IEblog上的做出回应，宣布默认使用IE8的标准渲染模式，撤回了之前默认为IE7渲染模式的决定。（真讽刺）

试问各位旅客最近听说了IE的哪条新闻？是Opera对微软藐视W3C标准的控告，还是IE8内测版突破ACID2渲染测试的公告？或者更进一步，你甚至留意到IE8与它那最新功能：神奇的Version Targeting？无论如何，IE7带来的各种用户怒吼是微软所不希望承受的，而Version Targeting是他们的妥协方案。

停，请停下，Version Targeting是啥？为什么我要在意它？

事实是微软提出的Version Targeting（店长暂译“指定版本”，简称VT）就是为了让你意识不到它的存在。IE开发组的Chris Wilson在上面链接的文章中解释了IE8中的VT工作方式：

1. Quirks mode（当html文档缺乏标准doctype时的渲染模式）的工作方式不变；

2. Standard mode，IE8将默认沿用IE7对标准页面的渲染模式；

3. 网络上暂称Current ("Edge") mode，懂得标准的网页开发者将可以通过meta标签/http请求的header信息定义IE8使用最新的渲染模式。

简单点说，假设IE8正式版的渲染引擎真的通过了ACID2测试，也需要开发者额外添加一条meta信息它才会启用这个新版本引擎，否则浏览器将自动沿用IE7当前的引擎。撇开Opera的指控不谈，这是微软的又一个阴谋吗？

微软启用VT的对外理由非常简单：兼容性。他们的论点是在IE6向IE7的过渡中用户反映了大量网站不兼容的问题，这是由于（引用Chris的原文）“网站开发者期望IE7的工作方式与IE6相同，即便是在标准渲染模式下。”换句话说，由于大多数开发者无意识的使用了标准doctype，使得经典的渲染模式开关不再有效，为了不影响这些网站的使用，IE8必须继续沿用IE7的渲染引擎为默认引擎，以避免进一步造成混乱。

信不信由你，“新瓶装旧酒”，居然在“为了兼容性”的言辞下变成了用户友好的新功能。现在你该明白为什么有许多新闻说IE8有“三个渲染引擎”了，多出来的一个应该是IE7正在使用的Trident V（如果微软不是在忽悠WaSP）。

对于微软启用的“新标准”，网络上自然又是各家自有各家的说法。对网页标准感兴趣的旅客一定听说过PPK，Eric Meyer和Jeffrey Zeldman的大名，有趣的是，长期与微软争锋相对的他们这次非常和谐的站在IE的一方。WaSP内部的意见也有很大分歧，很多成员是在ALA的两篇文章发布之后才知道是WaSP的领头们构思了这个Version Targeting的建议。

支持方的观点（目前占少数）——

• 没有VT的支持，IE开发团队根本没机会考虑标准化和持续更新的事情，因为新版本总在破坏网页渲染的模式（换句话说，不要说IE6，连IE7都距离W3C标准太远，持续更新引擎会让开发者/用户陷入困境。提供更新反而导致IE市场占有率下降，那领导们当然宁愿不更新引擎）；- Eric Meyer

• Version Targeting保护不懂网页标准的开发者与用户，这相比要求他们在一夜之间学会网页标准更加实际（如果IE团队选择不支持W3C标准，那标准也就失去了意义）； – Jeff Zeldman

• VT既然是微软开发团队自己接受的标准鉴别模式，那它应该100%工作，并且不影响其他浏览器，我们也无需再劳烦使用不稳定的浏览器嗅探。 – PPK

反对方的观点（目前占多数）——

• Version Targeting将阻碍Progressive Enhancement的发展，放弃默认支持更标准的设计，反而选择继续蒙骗不知情的开发者，暗示旧渲染引擎的行为是“正常”的； – Jeremy Keith

• 对开发者的“伤害”被夸大了，IE8的新引擎不会在IE7之上造成更大破坏，不使用doctype的产品也不受到新引擎的影响； – ALA上的留言

• 微软应该将金钱与时间用在宣传标准与教育用户上，而不是号称“亡羊补牢”的将标准与兼容性联系起来……这是IE五年无引擎更新带来的后果，应该由微软自己承担； – Chris Heilmann

• Quirk mode本来就是个向标准化过渡的产物，如果IE8还在引入“异名同义”的新Quirk mode，这只会给网页标准化带来负面影响； – Anne van Kesteren

• VT将给IE团队带来太多困难，在一款浏览器内加入多个渲染引擎本身增加了IE的体积，维护浏览器安全时又需要同时照顾到每个引擎，即便成功推出，用户是否会接受新产品也是个大问题。 – Robert O’Callahan

还有一部分开发者对此保持审慎态度……不过他们似乎都对微软的闭门NDA（不泄密协议）讨论表示不信任。

考虑到IE7/Vista的装机量依旧很低，导致微软不得不考虑将其列为“重要更新”以提高安装率，IE8的将来不甚光明。如何维持市场占有率是微软的首要问题，Version Targeting放在IE7也许有效，留待IE8则是为时已晚。站在局域网开发者的角度来说，假若IE8不支持IE6的渲染模式，那它对兼容也没什么好处。因此我非常怀疑VT的可行性，如果它不幸带来更多混乱，或是干脆被延迟到IE9，我都不会惊讶。

新的标准化战争在IE8还没有展露头角时就开始了。不同于以往的是，唇枪舌战将不局限在微软身上。WaSP领导与成员间急需的交流以及其他浏览器开发团队希望在IE8时代来临前打破垄断的野望，都给标准化带来不安的因素。

完。

如果你使用IE6，或者是任何对应的IE shell，例如世界之窗，Maxthon，Greenbrowser等等，请逛一逛新设计，有什么影响阅读的问题请报告。

来客栈的Safari用户比较少（当然我们也不是苹果的fans），如果有看到本文的也请帮忙检查下各类功能。

主题以大致完成，现在进入排除bug的时光

主题更新告一段落，更多功能今后有时间再加入，至于IE6，它再不死我们只能专门为它制订全套CSS了。