We don't choose who we are, but we do choose who we become.
(image via shoze)
过去二十年间浏览器的技术大战已经发生了好几次，头把交椅从Netscape转到IE又转到了如今的WebKit，战火从桌面蔓延到移动平台……但万变不离其宗，似乎总有一个强大的派系脱颖而出，成为某时间内的网络主宰者。
WebKit一度是下个领导者的有力人选，当移动市场占有率相当高的Opera也迫于缺乏开发者支持与iOS限制而转投WebKit，不少人已默认WebKit为新的霸主。
当Google毅然决定从WebKit中脱离出来，成立自己的新分支Blink时，所有业内人都意识到，那渐渐褪去的硝烟将再次扬起。
Firefox在输入法(IME)下的行为曾经让不少开发者烦恼，它和IE与Chrome的主要区别是，后两者在IME输入时都会触发keyup事件，而Firefox在完成时才会触发keyup事件。后来Firefox与IE、Chrome都实现了DOM Level 3里的Composition Event，有了类似compositionupdate的更新事件，于是也就没了支持上的问题（Mozilla也拒绝了来自开发者对keyup事件触发行为更改的请求，转为推荐使用Composition Event）。
WebKit是个不错的排版引擎，它的风行主要与Safari，Google Chrome乃至无数移动设备浏览器有关。但WebKit有些很神奇的bug，那种所有人一看就知道它不对，但不知为何始终没有fix的bug。
WebKit在图片不存在时，是不显示img的alt文字的。这是对UA Accessibility Guideline的违背，学习过W3C标准的前端设计师与开发者应该知道这点。
我真的不愿意提这个老道理，但随着PC（以及那些自称“后PC时代”的电子产品）的傻瓜化，似乎越来越多人对基本的计算机概念（或者说是数学概念）搞不清楚——这个世界上没有免费的午餐。没有程序能解决另一个程序的内存泄漏，Firefox Plumber是个骗局，把内存转为页面文件的骗局；除非你真的用尽了物理内存，让程序运行在页面文件上增加CPU周期与硬盘I/O这才是最大的失误。此外Chrome也从来没自称占用内存低，事实上，为了保证多进程沙盒，它不得不容忍各种多余的overhead。
真正要加速，你只能选择抛弃一些负担（用相对小的代价换来较大的速度提升），而所谓的Firefox SSE2 Build与Palemoon就是类似的项目。
欢迎走上为智能手机和触屏开发Javascript的不归路。Mobile Graded Browser Support at jQueryMobile, 注意级别特指对DOM和Javascript的支持；此外B级有两种解读。
我们距离“该网页游戏所需的CPU最低配置”不远了。我预测IE9的GPU加速或许能让微软风光一把（其他浏览器不会落后太久）。这个JS游戏引擎的作者Paul Bakaus是jQuery UI的开发者，他称引擎会支持IE较早版本，并且可以在iPhone与网本上流畅运行。
youtube via hacker news
只能用神作来形容的Javascript游戏开发库，代号Akihabara（秋叶原），利用了HTML5的小部分特性，制作纯(X)HTML + Javascript的游戏。和以往常见的游戏库不同，这个库的运行速度相当快，它运行塞〇达传说的流畅度与精细度让我惊叹！
这个游戏库惹人喜爱的另一个地方是它的独立性，放弃jQuery这类常用的跨平台库意味着Akihabara可以用最高效的代码完成功能；事实上，Akihabara库的源代码十分易读，对网页游戏开发将来趋势有兴趣的旅客不妨看看。
via ajaxian
PS: 说起网页游戏，就不得不说最近宣布由韩国Mgame开发的《美少女梦工厂OL》。本来让一群“爸爸”在游戏大厅交流育女信息就够让人头大了，这次还准备把养女党（抱歉）带到手机与网页上。虽然觉得RIA更有可能成为网页版的构架基础，但要有HTML5的版本就拽死了！“爸爸开个Chrome再来好好教育你”之类的台词浮想联翩……
