按照惯例，年底的 淘宝 的确是到了「需要改版的时候」。这次新版的淘宝首页上线，乍看并没有多少夺人眼球的地方，但仔细揣摩其中的细节，还是发现了不少的改变。

其中有一点就是感觉页面留白过多，仔细看了下发现是页宽从 原来的 960px 拉伸至 1000px。

不要小看这个增加了的 40px 页宽，这对于设计师们而言可能是做了个「异常艰难的决定」。

混沌时期

还记得用 Win98 拨号上网的时代吗？那时候分辨率也小得可怜，800x600 的标配分辨率甚至都不及当前的某个高端智能手机。

不知道什么时候开始，网页的页宽有了个经典宽度 600px -- 当然，那时候谁都不会在意它。

960 时代

后来，这个故事变得简单而且老套：随着硬件的发展，分辨率也不断的提升。从 1024x768 到 1280x800 再到 1440x900 甚至更高（ 这里有个统计 ）。

网页的页宽数字也在不断的增加，比较经典的几个数字为从 600px、740px 直到 960px 。然而这时候标准线出现了，那就是 960 页宽。

以淘宝为例，我印象中 960px 页宽从 2006 年沿用至今（2011）已经整整五年。这相比二十一世纪的前五年的页宽改变趋势而言，这实在是让人感到有些变化不大过于拘泥。

当然，设计师们采用 960 这个数字当作页宽的布局方案也有其道理：

1. 其能兼容大部分的屏幕分辨率。800x600 已死，剩下分辨率最小的也有 1024x768。那么，为了更可能多的展现内容，页面的宽度自然会在 800-1024 像素之间，960 设置数值差不多是个中间值，不多不少刚刚好。
2. 960px 方便栅格化布局 -- 其实从数学的角度上说，这个观点有点站不住脚。不过 960 页宽的栅格是最早出现的， 同时也是最广泛使用的 （附， 淘宝的栅格系统 ）。

打破僵局

既然 960 页宽已经足够好，沿用传统的页宽也并不会犯错，那么回过头来我们再看这次淘宝首页为何要改变成规。

根据我的个人观点，可以总结部分：

1. 960 页宽已经显得「过时」，1024x768 像素会像当年的 800x600 一样，迟早会被更大数字的分辨率所淹没。
2. 需求的驱动，需要在页面中加入更多的内容。想想页宽增加 40px 乘以页长，整个页面将会多出多少设计和内容填充空间。
3. 1000px 这个整数更容易计算和安排栅格 -- 不过从数学上这个说法也很难站住脚。不过整数 1000 的整除数比 960 多多了，也更容易安排。

单单 40 像素的改变，对于「粗心大意」的用户而言似乎无关痛痒（当然，也可以理解为淘宝其实不想让用户过多得在意他们的改变）。

个人觉得 1140 页宽 也是可以考虑的数字。那么，还有会不会有更大的页宽数字出现？我想应该会控制在 1200px 以内， 否则将会给用户阅读带来困扰 。

未来

我们来预测下未来的经典页宽将会是什么数字？说实话我也不知道，这一答案完全在设计师脑子里。有点可以预料到的是，移动上网设备的兴起会有促进两个大的趋势：

1. 向下兼容针对小屏幕的弹性页宽（ 详见 ）。
2. 页面布局将会针对不同的设备而定制，因此 800px 以下的页宽将会「复活」。

-- Split --

这次广泛采用 HTML5 标签、加大页宽等等的改变，看得出淘宝一直在做着细节方面的尝试和调整。然而从不谐调的留白、布局的不协调看得出来，淘宝对于新的页宽经验稍显不足。

但愿 1000px 这个页宽将又会是个经典的数字。毕竟，不客气的说，「山寨」淘宝首页的站点实在是太多太多了。

PS，淘宝还给我们留了个小彩蛋，新版在首页搜索框中输入「about:staff」会有惊喜（相应代码在 1970 行开始） :^D

-- EOF --

请原谅我取了个如此有争议的标题，原文的标题是《浏览器不是什么》。我个人觉得作者有点脱离题目，但这并不影响其想要陈述的观点。

可用性 一直是我们前端争论的焦点之一。但仔细想想，我们是否值得为那些连见都没见到过的盲人阅读器或者那些自行禁用 JavaScript 的用户投入额外的、大量的开发成本去「满足」他们？

-- Split --

原文地址： http://blog.istvan-antal.ro/2010/10/what-is-not-a-browser/ 发声 。而后过了段时期，出现了能够同时使用扬声器和声卡的应用程序。

话说回来，现在是否还有人关心自己的机子上有无声卡吗？我想恐怕已经没有。甚至我觉得人们已经遗忘了机箱中的扬声器了。

例如，我从来没有见过某款游戏因为机子上没有声卡而自动关闭其声音－－当然，如果我耳朵听不到那是另外回事情（老外的这个说法比较冷）。

说了那么多，上述故事和浏览器以及 JavaScript 的故事非常的相似。不同的是现在的开发人员，在开发应用的时候，仍然在考虑如果没有脚本支持的这一情况。

其实和当年的声卡普及情况差不多，JavaScript 发明于 1995 年（已经是 15 年前了）。当时其在浏览器中的份额不到 1%，而且当时的用户（甚至开发者）都认为这玩意是可有可无的。

我的观点是，每个 Web 应用程序应该能够尽可能的运行在不同环境中，但它并不说明无条件的迁就于某一情况，在任何情况下都表现一致。

例如，在浏览器没有 JavaScript 支持的情况下，新闻类站点仍然可以显示其主要内容（新闻），同时不保证那些依赖 JavaScript 的相册脚本，仍然还能正常工作。

我们现在称之为「浏览器」的应用程序必须为：它能理解 HTML、能使用 CSS 渲染页面、同时能驱动 JavaScript 脚本。某个应用程序只能够完成上述一项或者其中两项功能，那么这压根就无法称之为「浏览器」。

例如，搜索引擎理解 HTML（以及部分 CSS 防止作弊），我们只需要提供内容让其收录 －－ 同时它不需要过多的了解 GUI 相关的设计。

从内容方面考虑，其实我只关心两件事物：搜索引擎和浏览器。首先，我第一步需要做的就是创建具有语义的 HTML（这对于 HTML 来说并不容易），然后再使用 CSS 排版并且使其支持现代浏览器，然后再使用 JavaScript 增加针对 IE 的 CSS 规则（很明显原作者非常讨厌 IE）。

我的上述工作流程有时候会收到指责，因为这样必须让老旧的浏览器具备 JavaScript 支持才能引入针对其自身的 CSS 规则。同时情况可能变得模棱两可，我真的不认为我们称之为「浏览器」的玩意竟然不支持 JavaScript，哪怕是那些可以称之为古董的玩意（暗指 IE 吗？）。

总而言之，我们的思路应该为未来而开发，而非迁就过去（We should develop for the future not for the past.）。

我们应该为大多数（用户）而非少数服务。如果我们的用户中有 0.1% 禁用了 JavaScript，那么在我看来，我们可能不值得去耗费大量的开发时间去争取那些 0.1% 的用户。

同时另一个事实是，如果我们让用户觉得在没有使用 JavaScript 的情况下也能使用我们的应用，那么他们会毫不犹豫的禁用它（类似 noscript 插件 ）。那么这样，我们推进 Web 的前进几乎是不可能的，我们和用户都会认为 JavaScript 是额外的附属品。

最后，其实我想说明的是：在着手实际开发之前，我们首先规划那些有限的资源（例如时间、人力等）－－ 它们的计划投入和实际产出是否能符合我们的预期。

-- EOF --

单纯从规模上讲，目前拥有至少 七家文学站点的盛大 ，推出 BamBook 阅读器 丝毫让人感觉不到意外。

这款目前称为 BamBook 的阅读器外形与我期前接触的内部版并无多大的改变。当时由于是内测版本没有印上 Logo，给人第一眼的印象就是国内 Kindle 的山寨板。

都知道 BamBooke 面对的对手不是 iPad，而是 Amazon 的 Kindle。在面对已经历经三代的 Kindle 面前，新生的 Bambook 就好比是孩子对比成年人一样，没有任何的对比性可言。

一开始将 BamBook 的目标定位为 Kindle 未免有些不太现实，其实我们能理解， BamBook 主要面对的是国内中低端阅读器市场 。

然而，国内的「特殊环境」可能是制约此类产品发展的因素之一。这就好比国外卖手机其实卖的是服务而非硬件，国内此 类产品永远大多都是在做「产品」而非「服务」。

盛大当然也考虑过这个道理，因此考虑这款产品如何生存下去的条件之一，就是如何降低成本降低售价。BamBook 那 1k 不到的卖价，自然也就在情理之内（同时 我有理由相信以后的价格只会更低 ）。

相对价格，时隔几个月不知此时发布的版本稳定性和速度对比那时体验的内测版是否有所提升。如果还是老样子，那么即便是如此低廉的价格，恐怕还是很难打动挑剔的消费者。

随着 iPad 等平板电脑的持续发力（虽然两类产品无法共同比较）、Kindle 的第三代版本目前最低售价也才一百多美元、同时国内现有的例如 汉王 等传统电子书厂商也有降价的趋势。

光控制成本和售价并不能说明 Bambook 有多少的竞争力。如果想在这堵墙中拉开道口子，BamBook 必须在其它的地方寻找突破口。

首先能想到的就是盛大目前掌握的资源 ，「搅局的人永远在后面出现」，不要忘记盛大的掌中已经有几家国内规模较大文学站点。如果盛大能将这些资源充分的利用 对接起来，那么原本风平浪静的国内阅读器市场将会变得复杂。

我们可以想象下此时盛大的心态，这个在大部分人眼中还是家依靠游戏外包发家的公司，对比腾讯没有其影响力和用户基础、对比百度其没有技术。如果其想要转型，那么除了大肆收购的手段之外，剩下事情就是组建自己的核心生态圈－－回头看其实这个局早在 2006 年就已经开始布置。

我们回看 BamBook 产品本身，那外形类似 Kindle、平台 UI （ 甚至产品页面 ）类似 Apple 的 Bambook，它首先需要做的就是摆脱那模仿的影子， 同时避免那些拙劣的推广手段 。

那么这样，才有它的未来。

-- EOF --