导读：
未显示需要 JavaScript 的文档选项
级别： 初级
2006 年 8 月 03 日
为了诱使开发人员创建在他们自己的浏览器中得到最佳呈现效果的网站，浏览器厂商选择脚本语言作为武器发起了兼容性之战，用户则陷入了页面加载慢和可能存在安全漏洞的泥潭之中。市场推动了这种（不健康的）竞争，显然到了进一步标准化的时候了。看看在那一天到来之前如何保持中立的立场。
ECMAscript（即多数人更熟悉的 JavaScript）有一段有趣的历史，它最初是为了反抗标准出现的。就是说，ECMAScript 基本上和 JavaScript 以及 JScript 是相同的语言，这两种互相竞争的语言分别得到 Netscape 和 Microsoft 的支持。
这项技术最初被称为 Mocha，后来改为 LiveScript，1996 年第一次正式提出 JavaScript 的名称。但是，它和 Java? 语言没有任何技术上的联系，名称的重要性纯粹是出于市场的考虑。的确，新闻稿中暗示服务器端 Java 和客户端 JavaScript 之间有某种联系（参见 参考资料），事实上，两者毫不相干。
Netscape 的市场主导地位迫使 Internet Explorer 支持一种兼容语言，或者说基本兼容。Internet Explorer 提出了 JScript，它和 JavaScript 基本兼容。
标准之战
什么是 Open Ajax Alliance？
2006 年 5 月 JavaOne 预备会议中，来自 29 家公司的代表在 Adobe Systems 的会议室碰头了，尝试从总体上决定 Ajax 的未来方向，他们这个小组就被专门称作 OpenAjax。
这个小团体做了几项决策，包括最明显的一件事，就是给自己取了一个名字：Open Ajax Alliance。它还决定不把自己搞成正式的标准体，或者像 Eclipse Foundation 那样的开放源代码一线组织，其组织暂时也是非正式的。小组同意大约每周召开一次电话会议。
Open Ajax Alliance 主要关注三个领域：通过提供互操作性降低采用 Ajax 的风险、保证 Ajax 解决方案坚持走开放标准之路、保持 Web 的开放性。
小组的第一项任务就是寻找在 Ajax 工具间建立并保持互操作性的办法。
OpenAjax Alliance 由 31 家技术厂商组成，包括 IBM、Adobe、Eclipse Foundation、Google、Laszlo Systems、Oracle、Red Hat 和 Zend。
接下来的事情就简单了：Netscape 和 Internet Explorer 的每个新版本都增加了激动人心的、与对方浏览器不兼容的新特性。通过在私有语言中提供华而不实的新特性，显然其目标就是让 Web 设计人员提供只能在一个浏览器上查看的网页。在 Java 和 J++ 的冲突中也可以看到类似的情况，那场纷争发生在大约同一个时候。JavaScript 和 JScript 之间的冲突源于 Netscape 和 Microsoft 察觉到的经济利益，但对其他任何人都没有好处。事实上，这两家公司也为控制不兼容的代码来保持兼容性而付出了高昂的代价。
正式标准化工作开始于 1996 年，当时 Netscape 向 ECMA International 提交了 JavaScript 规范，1997 年 7 月第一个标准开始采用。当前的标准（ECMAScript Edition 3，1999 年）是 ECMA-262，对应 ISO/IEC 16262。
但是，这场战争并没有就此停止。JavaScript 和 JScript 都与 ECMAScript 兼容，但是仍然存在实质性的区别和扩展。各自的公司都利用这些差异诱惑开发人员，想让他们说某个页面只能用于某个浏览器，或者宣布某个浏览器可以提供 “最佳” 显示效果。
有些开发人员干脆忽略哪些浏览器可能用于处理其网页的问题，另一些则在任何尝试之前都小心翼翼地检查兼容性问题。他们检查用户代理字符串（浏览器提供给服务器的字符串）中的版本信息。不幸的是，很多 Web 浏览器都在用户代理字符串中固定使用 “Mozilla/X” 作为检测 Netscape 版本的标准。如果用户代理不是 Mozilla，有一些功能被忽略或禁用，结果这些页面可能根本不能在其他任何浏览器中正确呈现。于是，Internet Explorer 也开始用用户代理字符串宣称自己是一个 Mozilla 版本！
其他竞争者
在这种已经乱成一团的情形下，又出现了新的浏览器开发者，如 Opera、iCab 和 Konqueror，它们的基本目标是尽可能地呈现所有网页。因为很多 Web 页面把重要功能依赖于以 “Mozilla” 开始的用户代理字符串，越来越多的厂商开始沿袭 Internet Explorer 的技术。很多现代浏览器都支持发送误导的用户代理字符串，甚至能够选择伪装哪种浏览器。这就是市场驱动的特点，如果提供这样的用户代理字符串，并且惟有如此，新的浏览器才有可能呈现成千上万的网页。很多站点尝试检查或者禁止在呈现其网页时可能会也可能不会存在问题的某些浏览器。
虽然浏览器是最有可能引用 ECMAScript 标准或者标明特定版本的平台，但并不是支持标准的惟一技术。一些版本的 Macromedia Flash 使用称为 ActionScript的变体。Adobe Photoshop 也使用 JavaScript。特别有意思的是 Konfabulator，用于 Windows 和 Mac OS X 的一种 JavaScript 运行时，它支持编写一些小程序，比如股票行市自动收发器、小型视频游戏，等等。
标准冲突的影响
标准之争带来的最明显的影响就是延迟，因为网页在执行任务之前必须使用又长又复杂的代码检测浏览器的版本。一些程序用一页又一页的脚本识别浏览器，不同的版本使用不同的页面。
这些脚本不单纯是标准之争的结果，毕竟，网页需要其中一部分脚本可能仅仅是为了确定给定平台遵循什么标准版本。但是，JavaScript/JScript 的早期实现在这方面仍然相差甚远，经常不提供版本信息，或者以完全不兼容的方式提供。仅仅询问版本还不够，Netscape 和 Internet Explorer 可能以不同的方式返回版本！当然，更多的复杂脚本可能是由于开发人员的混乱造成的，而不是因为缺乏对版本检查的支持。比如，一个在线存储软件实现程序使用庞大的脚本判别您使用的是 Mac 还是 Windows 机器（仅支持这两种平台），然后确定提供 zip 还是 StuffIt 文件，尽管下载的软件是针对特定平台的。全部脚本都是垃圾，因为浏览器不支持该脚本，我还浪费了半个小时编写一个包含正确下载链接的静态网页。
数目惊人的代码都假定使用某个扩展会对给定实现带来好处。比如，一些开发人员可能检查 if (document.layers)然后认定，如果检查成功，宿主浏览器一定是 Netscape 4，于是使用各种 Netscape 扩展，或者那些在该 Netsacpe 版本之外没有广泛实现的标准特性。不要这样做！如果浏览器实现了这个特性而没有实现另一个，您就是自找麻烦。一定要坚持标准。（Mozilla 的开发人员提供了一个很好的 “嗅探器” 来确定 JavaScript 实现，参见 参考资料）。
虽然这种迂回方法造成流量仅占整个 Web 流量的很小一部分，但是值得估计一下为了模仿原生脚本而作为用户代理字符串的一部分发送 “Mozilla” 花费了多少时间。如果 JavaScript 从一开始就用简单的方式检查版本或执行特性测试，并且开发人员更好地利用现有支持，那么这些都可以避免。
其他的变种
近年来的变化之一是专门的、针对特定用途的浏览器的开发，其 JavaScript 实现通常缺乏良好的文档。当然，我指的是涌现出来的雏形。原来的 JavaScript 标准允许脚本执行几种有可能带来干扰的动作。干扰实际上不够准确，一些脚本甚至允许更像是病毒而不是网页的动作（比如，在关闭时使用 onUnload方法打开新窗口的窗口！）
虽然这些不良的程序部分仅仅带来不便或者烦恼（有些播放很响的声音文件希望把周围的人引到倒霉的受害人的桌子旁），另一些可能非常危险。安全恶梦包括创建 URL 隐藏窗口的选项，就是说，供给者可以在用户不知道的情况下加载任何其他页面的窗口。各种浏览器已经开发了针对不希望的脚本行为的防范机制。
随着网站开发出用 JavaScript 代码显示消息的新方法，浏览器厂商寻求压制不希望的消息的新方式，这种冲突继续增多。一些站点使重要的网站功能依赖于用于显示广告的基本相同的脚本技术，如果不接受不需要的广告，用户就不能使用网站的重要功能。
未来的方向
ECMAScript 的进一步标准化仍在进行之中。人们认为，未来的 JavaScript 2.0 语言标准和 ECMAScript Edition 4 标准基本上是同一种语言，虽然 JavaScript 有一些扩展。JavaScript 2.0 主页上解释说，“JavaScript 2.0 仍将包括少数在标准化之前需要更多反馈和试验的特性。”
如果用户幸运的话，开发人员将试验和研究这些特性，但不会作为网页的核心功能使用。过去我曾经坚持合理采用未完成的标准，但是采用新的规范必须要记住不是每个人都有支持它的工具。在决定之前所有人公开、坦诚地展开讨论是一件好事。
关于未来值得专门讨论的是 Ajax，它是 “Asynchronous JavaScript + XML” 的缩写。其思想是页面上的脚本可以作一些动态工作，获取新数据和修改显示结果，而不需要重新加载整个页面。理论上，这可能大大降低某些网站的带宽需求，因为脚本一次装载了页面的大部分内容，然后刷新和上传较小的部分。它本身实际上并不是一种新标准，而是 ECMAScript 语言的一种应用，它促使浏览器更好地标准化和某种程度上的功能扩充。脚本越复杂，它依赖的特性越多，对开发人员来说稳定而灵活的底层平台就越重要。希望将来标准的修订能够解决目前版本的安全问题，虽然不可避免地要损失现有的一些功能。
高效安全地使用脚本
这对于开发人员意味着什么呢？首先，必须尽量减少不必要的依赖性。一些页面使用 onclick脚本加载新页面，用 “#” 代替了网页上所有的 URL。这不过是令人讨厌的小伎俩。不要这么做。
编写脚本时，一定要理解如果禁用脚本会发生什么。一家大厂商的网站，几年以来一直在禁用脚本时显示空白页 —— 虽然使用脚本的惟一原因不过是确定浏览器是否支持 Flash 动画。（最新的版本显示一条消息说各种功能如站点导航需要 JavaScript。这也好不了多少。）如果必须使用脚本，应保持在控制之下，毕竟很多供残疾人使用的浏览器已经限制了脚本功能。
编写脚本时应考虑需要哪些浏览器来运行。如果可以排除较老的版本（或者为其提供不需要脚本的功能），可以大大简化编码。一些比较简单的脚本是可移植的，其他的可能需要多种特性或者同一代码的不同实现，分别针对那些互相竞争的所谓的标准。可以用具有很好可移植性的代码确定常见的 JavaScript 版本（更多信息请参见 参考资料）。将针对特定平台的代码隔离出来。不要简单地假定为 Internet Explorer，很多人使用不寻常的浏览器（移动电话或 PDA）或者更喜欢 Firefox。
要注意流行的设置已经在那儿，用户不愿意改变设置，事实上很多用户不能修改设置，或者是因为用户技术水平，或者是因为系统管理员控制。应该要求脚本即使在至少部分功能被锁定的浏览器上也能显示。
站的越靠近标准中心，离扩展的边缘越远，保持兼容性需要做的工作就越少，新的浏览器版本带来的影响就越小。基本无论何种情况，您都注定会在至少一次重要的浏览器升级中需要维护您的网页。作好准备吧。
参考资料
学习
您可以参阅本文在 developerWorks 全球站点上的 英文原文。
作者在 “My not-so-invisible enemy”（developerWorks，2005 年 7 月）一文中讨论了网页肿胀的问题。（The cranky user专栏中给出了另一个例子。）
阅读 “Retrofit Your Web Pages for Wireless Compatibility”（Brett McLaughlin，developerWorks，2005 年 11 月），建立更加灵活的网页。
浏览 developerWorks 无线专区，提升您的移动开发技能。
阅读 JavaScript versioning。
看看发明了 Ajax一词的这篇短文。
访问 developerWorks Web 架构专区，可以找到关于各种 Web 解决方案的文章和教程。
随时关注 developerWorks 技术事件和网络广播。
获得产品和技术
重温 JavaScript的最初宣言。
讨论
参与 developerWorks blogs加入 developerWorks 社区。
参与 developerWorks 讨论论坛。
关于作者
Peter Seebach 多年使用计算机，已逐渐适应。虽然还不知道为何需要经常清洗鼠标。
本文转自
http://www.ibm.com/developerworks/cn/web/wa-ecma.html
未显示需要 JavaScript 的文档选项
级别： 初级
2006 年 8 月 03 日
为了诱使开发人员创建在他们自己的浏览器中得到最佳呈现效果的网站，浏览器厂商选择脚本语言作为武器发起了兼容性之战，用户则陷入了页面加载慢和可能存在安全漏洞的泥潭之中。市场推动了这种（不健康的）竞争，显然到了进一步标准化的时候了。看看在那一天到来之前如何保持中立的立场。
ECMAscript（即多数人更熟悉的 JavaScript）有一段有趣的历史，它最初是为了反抗标准出现的。就是说，ECMAScript 基本上和 JavaScript 以及 JScript 是相同的语言，这两种互相竞争的语言分别得到 Netscape 和 Microsoft 的支持。
这项技术最初被称为 Mocha，后来改为 LiveScript，1996 年第一次正式提出 JavaScript 的名称。但是，它和 Java? 语言没有任何技术上的联系，名称的重要性纯粹是出于市场的考虑。的确，新闻稿中暗示服务器端 Java 和客户端 JavaScript 之间有某种联系（参见 参考资料），事实上，两者毫不相干。
Netscape 的市场主导地位迫使 Internet Explorer 支持一种兼容语言，或者说基本兼容。Internet Explorer 提出了 JScript，它和 JavaScript 基本兼容。
标准之战
什么是 Open Ajax Alliance？
2006 年 5 月 JavaOne 预备会议中，来自 29 家公司的代表在 Adobe Systems 的会议室碰头了，尝试从总体上决定 Ajax 的未来方向，他们这个小组就被专门称作 OpenAjax。
这个小团体做了几项决策，包括最明显的一件事，就是给自己取了一个名字：Open Ajax Alliance。它还决定不把自己搞成正式的标准体，或者像 Eclipse Foundation 那样的开放源代码一线组织，其组织暂时也是非正式的。小组同意大约每周召开一次电话会议。
Open Ajax Alliance 主要关注三个领域：通过提供互操作性降低采用 Ajax 的风险、保证 Ajax 解决方案坚持走开放标准之路、保持 Web 的开放性。
小组的第一项任务就是寻找在 Ajax 工具间建立并保持互操作性的办法。
OpenAjax Alliance 由 31 家技术厂商组成，包括 IBM、Adobe、Eclipse Foundation、Google、Laszlo Systems、Oracle、Red Hat 和 Zend。
接下来的事情就简单了：Netscape 和 Internet Explorer 的每个新版本都增加了激动人心的、与对方浏览器不兼容的新特性。通过在私有语言中提供华而不实的新特性，显然其目标就是让 Web 设计人员提供只能在一个浏览器上查看的网页。在 Java 和 J++ 的冲突中也可以看到类似的情况，那场纷争发生在大约同一个时候。JavaScript 和 JScript 之间的冲突源于 Netscape 和 Microsoft 察觉到的经济利益，但对其他任何人都没有好处。事实上，这两家公司也为控制不兼容的代码来保持兼容性而付出了高昂的代价。
正式标准化工作开始于 1996 年，当时 Netscape 向 ECMA International 提交了 JavaScript 规范，1997 年 7 月第一个标准开始采用。当前的标准（ECMAScript Edition 3，1999 年）是 ECMA-262，对应 ISO/IEC 16262。
但是，这场战争并没有就此停止。JavaScript 和 JScript 都与 ECMAScript 兼容，但是仍然存在实质性的区别和扩展。各自的公司都利用这些差异诱惑开发人员，想让他们说某个页面只能用于某个浏览器，或者宣布某个浏览器可以提供 “最佳” 显示效果。
有些开发人员干脆忽略哪些浏览器可能用于处理其网页的问题，另一些则在任何尝试之前都小心翼翼地检查兼容性问题。他们检查用户代理字符串（浏览器提供给服务器的字符串）中的版本信息。不幸的是，很多 Web 浏览器都在用户代理字符串中固定使用 “Mozilla/X” 作为检测 Netscape 版本的标准。如果用户代理不是 Mozilla，有一些功能被忽略或禁用，结果这些页面可能根本不能在其他任何浏览器中正确呈现。于是，Internet Explorer 也开始用用户代理字符串宣称自己是一个 Mozilla 版本！
其他竞争者
在这种已经乱成一团的情形下，又出现了新的浏览器开发者，如 Opera、iCab 和 Konqueror，它们的基本目标是尽可能地呈现所有网页。因为很多 Web 页面把重要功能依赖于以 “Mozilla” 开始的用户代理字符串，越来越多的厂商开始沿袭 Internet Explorer 的技术。很多现代浏览器都支持发送误导的用户代理字符串，甚至能够选择伪装哪种浏览器。这就是市场驱动的特点，如果提供这样的用户代理字符串，并且惟有如此，新的浏览器才有可能呈现成千上万的网页。很多站点尝试检查或者禁止在呈现其网页时可能会也可能不会存在问题的某些浏览器。
虽然浏览器是最有可能引用 ECMAScript 标准或者标明特定版本的平台，但并不是支持标准的惟一技术。一些版本的 Macromedia Flash 使用称为 ActionScript的变体。Adobe Photoshop 也使用 JavaScript。特别有意思的是 Konfabulator，用于 Windows 和 Mac OS X 的一种 JavaScript 运行时，它支持编写一些小程序，比如股票行市自动收发器、小型视频游戏，等等。
标准冲突的影响
标准之争带来的最明显的影响就是延迟，因为网页在执行任务之前必须使用又长又复杂的代码检测浏览器的版本。一些程序用一页又一页的脚本识别浏览器，不同的版本使用不同的页面。
这些脚本不单纯是标准之争的结果，毕竟，网页需要其中一部分脚本可能仅仅是为了确定给定平台遵循什么标准版本。但是，JavaScript/JScript 的早期实现在这方面仍然相差甚远，经常不提供版本信息，或者以完全不兼容的方式提供。仅仅询问版本还不够，Netscape 和 Internet Explorer 可能以不同的方式返回版本！当然，更多的复杂脚本可能是由于开发人员的混乱造成的，而不是因为缺乏对版本检查的支持。比如，一个在线存储软件实现程序使用庞大的脚本判别您使用的是 Mac 还是 Windows 机器（仅支持这两种平台），然后确定提供 zip 还是 StuffIt 文件，尽管下载的软件是针对特定平台的。全部脚本都是垃圾，因为浏览器不支持该脚本，我还浪费了半个小时编写一个包含正确下载链接的静态网页。
数目惊人的代码都假定使用某个扩展会对给定实现带来好处。比如，一些开发人员可能检查 if (document.layers)然后认定，如果检查成功，宿主浏览器一定是 Netscape 4，于是使用各种 Netscape 扩展，或者那些在该 Netsacpe 版本之外没有广泛实现的标准特性。不要这样做！如果浏览器实现了这个特性而没有实现另一个，您就是自找麻烦。一定要坚持标准。（Mozilla 的开发人员提供了一个很好的 “嗅探器” 来确定 JavaScript 实现，参见 参考资料）。
虽然这种迂回方法造成流量仅占整个 Web 流量的很小一部分，但是值得估计一下为了模仿原生脚本而作为用户代理字符串的一部分发送 “Mozilla” 花费了多少时间。如果 JavaScript 从一开始就用简单的方式检查版本或执行特性测试，并且开发人员更好地利用现有支持，那么这些都可以避免。
其他的变种
近年来的变化之一是专门的、针对特定用途的浏览器的开发，其 JavaScript 实现通常缺乏良好的文档。当然，我指的是涌现出来的雏形。原来的 JavaScript 标准允许脚本执行几种有可能带来干扰的动作。干扰实际上不够准确，一些脚本甚至允许更像是病毒而不是网页的动作（比如，在关闭时使用 onUnload方法打开新窗口的窗口！）
虽然这些不良的程序部分仅仅带来不便或者烦恼（有些播放很响的声音文件希望把周围的人引到倒霉的受害人的桌子旁），另一些可能非常危险。安全恶梦包括创建 URL 隐藏窗口的选项，就是说，供给者可以在用户不知道的情况下加载任何其他页面的窗口。各种浏览器已经开发了针对不希望的脚本行为的防范机制。
随着网站开发出用 JavaScript 代码显示消息的新方法，浏览器厂商寻求压制不希望的消息的新方式，这种冲突继续增多。一些站点使重要的网站功能依赖于用于显示广告的基本相同的脚本技术，如果不接受不需要的广告，用户就不能使用网站的重要功能。
未来的方向
ECMAScript 的进一步标准化仍在进行之中。人们认为，未来的 JavaScript 2.0 语言标准和 ECMAScript Edition 4 标准基本上是同一种语言，虽然 JavaScript 有一些扩展。JavaScript 2.0 主页上解释说，“JavaScript 2.0 仍将包括少数在标准化之前需要更多反馈和试验的特性。”
如果用户幸运的话，开发人员将试验和研究这些特性，但不会作为网页的核心功能使用。过去我曾经坚持合理采用未完成的标准，但是采用新的规范必须要记住不是每个人都有支持它的工具。在决定之前所有人公开、坦诚地展开讨论是一件好事。
关于未来值得专门讨论的是 Ajax，它是 “Asynchronous JavaScript + XML” 的缩写。其思想是页面上的脚本可以作一些动态工作，获取新数据和修改显示结果，而不需要重新加载整个页面。理论上，这可能大大降低某些网站的带宽需求，因为脚本一次装载了页面的大部分内容，然后刷新和上传较小的部分。它本身实际上并不是一种新标准，而是 ECMAScript 语言的一种应用，它促使浏览器更好地标准化和某种程度上的功能扩充。脚本越复杂，它依赖的特性越多，对开发人员来说稳定而灵活的底层平台就越重要。希望将来标准的修订能够解决目前版本的安全问题，虽然不可避免地要损失现有的一些功能。
高效安全地使用脚本
这对于开发人员意味着什么呢？首先，必须尽量减少不必要的依赖性。一些页面使用 onclick脚本加载新页面，用 “#” 代替了网页上所有的 URL。这不过是令人讨厌的小伎俩。不要这么做。
编写脚本时，一定要理解如果禁用脚本会发生什么。一家大厂商的网站，几年以来一直在禁用脚本时显示空白页 —— 虽然使用脚本的惟一原因不过是确定浏览器是否支持 Flash 动画。（最新的版本显示一条消息说各种功能如站点导航需要 JavaScript。这也好不了多少。）如果必须使用脚本，应保持在控制之下，毕竟很多供残疾人使用的浏览器已经限制了脚本功能。
编写脚本时应考虑需要哪些浏览器来运行。如果可以排除较老的版本（或者为其提供不需要脚本的功能），可以大大简化编码。一些比较简单的脚本是可移植的，其他的可能需要多种特性或者同一代码的不同实现，分别针对那些互相竞争的所谓的标准。可以用具有很好可移植性的代码确定常见的 JavaScript 版本（更多信息请参见 参考资料）。将针对特定平台的代码隔离出来。不要简单地假定为 Internet Explorer，很多人使用不寻常的浏览器（移动电话或 PDA）或者更喜欢 Firefox。
要注意流行的设置已经在那儿，用户不愿意改变设置，事实上很多用户不能修改设置，或者是因为用户技术水平，或者是因为系统管理员控制。应该要求脚本即使在至少部分功能被锁定的浏览器上也能显示。
站的越靠近标准中心，离扩展的边缘越远，保持兼容性需要做的工作就越少，新的浏览器版本带来的影响就越小。基本无论何种情况，您都注定会在至少一次重要的浏览器升级中需要维护您的网页。作好准备吧。
参考资料
学习
您可以参阅本文在 developerWorks 全球站点上的 英文原文。
作者在 “My not-so-invisible enemy”（developerWorks，2005 年 7 月）一文中讨论了网页肿胀的问题。（The cranky user专栏中给出了另一个例子。）
阅读 “Retrofit Your Web Pages for Wireless Compatibility”（Brett McLaughlin，developerWorks，2005 年 11 月），建立更加灵活的网页。
浏览 developerWorks 无线专区，提升您的移动开发技能。
阅读 JavaScript versioning。
看看发明了 Ajax一词的这篇短文。
访问 developerWorks Web 架构专区，可以找到关于各种 Web 解决方案的文章和教程。
随时关注 developerWorks 技术事件和网络广播。
获得产品和技术
重温 JavaScript的最初宣言。
讨论
参与 developerWorks blogs加入 developerWorks 社区。
参与 developerWorks 讨论论坛。
关于作者
Peter Seebach 多年使用计算机，已逐渐适应。虽然还不知道为何需要经常清洗鼠标。
本文转自
http://www.ibm.com/developerworks/cn/web/wa-ecma.html
1067
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
