JavaScript 的核心目的：从可用性到无障碍的演进

引言与 ppk 的贡献

自今日起，我将陆续发布关于 ppk on JavaScript 的读书笔记。ppk 是我非常敬重的一位 Web 开发者，原因在于他关注的领域涵盖了 Web 标准、可用性以及无障碍访问等许多开发者忽视或故意忽略的重要方面。他通过大量案例测试不同浏览器，总结了 JavaScript 接口的兼容性，成为开发者的重要参考资料。多年来，他这种钻研精神是许多人所缺乏的。

ppk 于今年 9 月出版了这本书，我从去年就开始期待。今天拿到书后，我迫不及待地读完了第一章，果然令人惊喜，他的功底非同一般。虽然我只是个初学者，但我认为自己正走在正确的学习道路上。我希望通过分享学习笔记，让正在学习的人看到，一起交流进步。尽管不敢保证你能从中获得多少启发，但我确信这些笔记比单纯拷贝粘贴代码的学习方式更为正确。

本书共十章，章节名称简洁明了，分别为：目的、背景、浏览器、准备、核心、BOM、事件、DOM、CSS 更改和数据获取。从未有一本书能如此简洁地明确 JavaScript 的方方面面，因此学习负担不会太大。前言不宜过多，下面开始我的第一章学习笔记。

JavaScript 的核心目的：可用性

开篇明义：JavaScript 的目的是为网页增加一层特殊的可用性。这听起来很简单，但这条黄金定律常被误解。即使编写了有用的 JavaScript，开发者也可能未能结合适当的情景：在 Web 标准运动发展下，与当代无障碍 HTML 页面的配合。更糟糕的是，有些开发者不是增加一层可用性，而是用 JavaScript 完全取代 HTML，后果是如果浏览器不支持 JavaScript，网站将无法运行。

概念概述：富与瘦的权衡

概念概述

JavaScript 是一门由浏览器解释的脚本语言。它通过在客户端而非服务器端处理某些交互（如表单验证、创建新菜单）来为网站增添可用性。传统的网页交互中，客户端的每一个动作都必须经过服务器端处理才能反馈，漫长的等待会让用户崩溃。而 JavaScript 可以在客户端代替服务器端执行某些任务（最明显的是表单验证），从而提高用户体验。

随着时代发展，JavaScript 能够处理越来越多的交互。问题随之出现：JavaScript 能做这么多事情，究竟应该多用还是少用？这就引发了富与瘦的对决：是整个页面都用 JavaScript 控制交互，还是只增加少量 JavaScript 来增强可用性？也就是说，是尽可能多地使用 JavaScript，还是有所节制，甚至不使用？

瘦客户端很大程度上依赖于客户端与服务器之间的通讯，而富客户端则尽可能限制额外的数据通讯。

哪种方式更好？尽管富客户端带来了一些可用性益处，但瘦客户端可能是更“标准”的 JavaScript 用法。Web 被认为是文档的集合，而非界面的集合。最明显的证据是，浏览器具有后退和前进功能，让你能在文档中跳转，而界面通常没有这些功能？浏览器可以收藏（书签）文档，而界面可以么？从无障碍的角度来看，瘦客户端也更少出错。

这种非平衡性很难解决。富客户端当然也可以在更高级的界面实现前进后退、收藏，甚至做到完美的无障碍。但这需要大量的额外工作，而并非每个项目都有超出预算的时间或金钱。此外，过于专注于可用性而忽略无障碍也是一个问题。

那么 JavaScript 的目的是为富客户端还是瘦客户端服务？答案是：视情况而定。这取决于你的网站、受众以及你的 JavaScript 水平。

技术概述与标准现状

技术概述

JavaScript 分为六个方面，分别是：核心（Core）、浏览器对象模型（BOM）、事件（Events）、文档对象模型（DOM）、CSS 变更和数据获取（XMLHttpRequest）。

在上古时代，NetScape 领头之时，NetScape 3 是事实标准。

当代的情况却不再简单。ECMA 标准化了 JavaScript Core，W3C 标准化了 DOM，而 BOM 尚在 WHAT-WG 的标准化过程中，W3C 也刚刚有了 XMLHttpRequest 的第一份草稿。目前，BOM 依然遵循 NetScape 3 的事实标准，而 XMLHttpRequest 则遵照 Microsoft 的原始规范。

JavaScript 的目的在于为网站增加可用性，而不是破坏用户的隐私和安全。因此，JavaScript 不允许读写用户的文件（cookies 除外），采取同源策略，只允许来自相同域的交互。不允许读取历史记录，不能为上传文件的表单设置值，由 JavaScript 控制的窗口关闭需经用户确认，由 JavaScript 打开的窗口不能小于 100×100 像素，也不能移出屏幕之外。

JavaScript 的历史演变

JavaScript 的历史

探寻历史才能让我们理解 JavaScript 为何会被误解得如此深。JavaScript 的创造者是 Brendan Eich，首次在 NetScape 2 中实现。它的目的是创建一门足够简单的语言，让开发者能够容易地为网页增加交互，只要把代码拷贝过来调整一下即可。这确实令人赞叹，许多 JavaScript 开发者都是从拷贝粘贴开始的。

不幸的是，JavaScript 生错了名字，也生错了语法。最初它叫 LiveScript，但 1996 年时 Java 炙手可热，NetScape 想搭顺风车，于是某产品经理（我想知道她/他是谁，呵呵）命令更名，并命令 Brendan Eich 让“JavaScript 像 Java”。这让很多人误认为 JavaScript 是 Java 的低级版，无法引起严肃程序员的关注。

1996 年时，NetScape 3 是王者，Microsoft 只能照抄。这是一个难得的和谐期，当然，那时候浏览器比起现在来“瘦”了，仅限于表单验证和鼠标轮换的一些小花招而已。

接下来就是影响深远的浏览器大战了。为了争夺市场，两家浏览器纷纷实现不同的东西，谁都想成为事实标准。最有名的就是 NetScape 4 的 document.layer 和 IE 4 的 document.all（忘记它们吧！）。它们让 DHTML 流行起来。

1999 年，Microsoft 以推出良好支持 CSS 和 DOM 的 IE5 胜出，NetScape 的让位终于有足够的时间让一场革命发生，那就是 CSS。WaSP 首先从 CSS 入手，而很多专家也发现/发明了许多浏览器的补救办法，让这场革命成为可能。

2003 年，一些先锋们在 CSS 革命的影响下开始探索新的 JavaScript 风格，更多地关注无障碍，改观人们对它的坏名声，那就是 unobtrusive（非侵入式）——把 JavaScript 从 HTML 结构层分离出来。遗憾的是，那些在浏览器大战中存活下来的程序员可能还没有发现这条新道路。

2005 年，Ajax 热潮为 JavaScript 社区注入了新的血液。但某些方面，Ajax 太像 DHTML 了，无障碍成为许多 Ajax 应用的难言之隐。这个热潮趋向于关注技术（如何 Ajax），而可用性和交互（为何 Ajax）却被低估。最后，各种肿胀的库（现在称为框架）迅速发展起来。

Ajax 依然全速前进，但这会像 DHTML 一样结果，人们渐渐失去兴趣，它们会土崩瓦解。

JavaScript 的兴衰史好像有一定的“定律”支配，我们能打破这个怪圈吗？不管如何，JavaScript 开发者在寻找各种酷代码和华而不实的框架之外，更应该调整自己的行动，让 JavaScript 运行在：标准兼容的、无障碍的网页中。