Subclass UIWebView and put these lines under your implementation:

- (UIView *)hitTest:(CGPoint)point
         withEvent:(UIEvent *)event
{
  CGPoint p = currentPoint;
  NSTimeInterval t = currentTimestamp;
  currentPoint = point;
  currentTimestamp = [event timestamp];

  if (CGPointEqualToPoint(p, point) &&
      [event timestamp] - t < 0.2){
    NSLog(@"double taps");
    return self.superview;
  }

  return [super hitTest:point withEvent:event];
}

Notice: declare ivar currentPoint and currentPoint in your header file.

It works like a charm.

关于本书，可以参考一下我去年的书评。对于前端工程师来说，很多情况下都需要重新捡起以前的代码，不管是不是自己写的，都会面临抉择：重新来过还是基于现状？大部分情况下，后者是唯一选择。勿怨天尤人，重构是你的好朋友。即便是在全新的工作进程中，当你闻到坏坏味道时，也需要很多小型的重构。那么，到底什么是重构？这可不是前几年流行的《网站重构（Designing with Web Stardards）》那本书里说的“重构”，而是”Refactor”，编程术语上的“重构”……说到底，还是得买一本才能了解透彻的，哈哈。

随着网页的程序化（就是 Web Application 越来越多了），眼观六路，耳听八方，前端工程师跟浏览器打交道，除了在掌握浏览器在展示页面上的知识，还需要有浏览器跟后台交互的基本知识，本书涉猎 HTTP 的基本要点，虽不深入但亦可管中窥豹了。

作为第一本在 HTML 领域探讨重构的《重构 HTML: 改善 Web 应用的设计》终于上市了，各大网上书店均已铺货。

有一天想用 iPhone 看一本只有 CHM 格式的电子书（Quartz 2D Graphics for Mac OS X’s Developers），发现 App Store 存在两款软件，试用其中一款，觉得非常不满意，甚至无法满足最基本的阅读需求，就产生了做一个更好的 CHM 阅读器的念头。满足自己的需求，也希望藉此赚点零花钱买个 iPhone 3GS.

于是有了 CHMate, 今天已经可在 App Store 安装，定价 $4.99. 如果有机会对比一下 CHMate 跟其他 iPhone CHM 阅读器，你会发现 $4.99 不会花得冤枉。根据我的老本行积攒的知识，我可以对 CHM 文件内的 HTML 做到最适合 iPhone 的屏幕阅读。CHMate 的优势是：对文档进行了重排，原来文档内的样式，除了那些依附在标签（tag）上的，基本上都被重写优化了，而且通过设置让你有控制样式的机会。当前尚未有同类产品有这个功能，这是我作为一个前端开发者所引以自豪的一件事情。

两种家

我们困惑不解、迷惑不安，很大程度上源于没有指导思想。要摆正自己的位置，我们究竟是想做科学家，还是想做工程师。简明扼要，科学家经常要问“为什么”，他们关心了解人类不懂的知识；工程师则利用科学家发现的知识，制造对人类有用的物体或工具。前者研究，后者实战。很明显，我们大多数人属于工程师，W3C 那一群才是科学家。端正自己的态度，很多疑问就会迎刃而解。

两种用法

HTML 生为标记语言，是组织文档的一种格式。随着技术和社会的不断进步，HTML 的用途也逐渐升级。今天它不仅出现在浏览器上（普通网页），它还出现在桌面程序上（Adobe AIR），出现在手机程序上（PalmPre WebOS）；它不仅用来展示网页，也用来构建程序的用户界面。Web 标准要求我们，HTML 必须有良好的语义化，对于展示内容的文档来说，这是毋庸置疑的，但对于只是作为构建用户界面的程序来说，强调语义是没有多大意义的。要注重语义的时候一定不能松懈，只是用户界面而已的话，怎么方便怎么来，利用最方便的手段做最适合的布局。

实用主义的前提

工程师信奉的是实用主义，但不等于可以放弃原则和规范。工程师关键任务是在遵守规范的前提下，发现、理解并结合实际的局限来达到满意的结果。作为一个流量巨大的网站，Google 对待 HTML 的态度是一个非常好的例子，省略</body> 和 </html> 的做法我们何曾想过呢？但这却是符合 HTML 4 规范的。详见： http://code.google.com/speed/articles/optimizing-html.html（需自行翻墙）。

门还在入，欢迎各界人士多多指教。

Objective-C 不像 C 有国际标准，它和 C++ 一样不存在标准。目前主要是 Apple 在维护，最近衍生了 Objective-C 2.0. 使用 Objective-C 的大户也当属 Apple, 因此 Apple 提供的库属于准标准库了。对于开发 Mac 内在观感(native)的 UI 程序来说，使用的是 Cocoa 这个框架，包含 Foundation 和 Application Kit (AppKit).

Objective-C 也使用头文件(header files)，后缀为 .h, 但使用 .m（即 message, 其他面向对象编程语言也叫 method），作为源文件的后缀。

Objective-C 引入了 #import 指令，它的作用不仅解决头文件重复包含的问题，而且只要引入框架的单个主头文件，就可以使用框架的所有功能。

使用和查看 Cocoa 提供的 API 时，通常会发现它们大部分以 NS 打头，它是 NeXTStep 的缩写，至于 NeXTStep 和 Apple 的渊薮，大家还是自己 Wikipedia 吧。这是因为 Objective-C 没有命名空间（name space），为避免冲突而加上的。作为一个良好的编程习惯，开发者不应再以 NS 开头命名自己的类和函数等，通常的习惯是使用自己或公司名称的缩写（Realazy 是否可以缩写成 RZ? 呵呵）。

另外，Cocoa 的编程风格鼓励表达清晰而非含糊的命名，所以你会看到 Cocoa 中非常长的、极少看到缩写的类名或消息名。

1. AIR 的开发对 Web 开发者非常友好，基本上不需要额外的程序知识了，甚至可以使用已有的 JS 库，爱饭就使用了 YUI。但是生成的程序有一通病，那就是占用内存高（爱饭在 Windows 下占用 40m 左右），而且不存在优化之说。做严肃的应用 AIR 还是上不了台面。很多时候觉得，打开一个 AIR 程序，其实就是打开了一个浏览器。
2. absolute 的 CSS 布局方式非常灵活，对窗口缩放这种情况具有非常好的适应性。使用 webkit 引擎的 AIR 对 absolute 完全支持。如果是 IE 这种支持残缺的引擎，那得费非常多的 JS 代码。在 AIR 下写 CSS 有一种莫名的快感。正好 24ways 上发布了一篇关于 absolute 方式布局的文章，免却了我的罗嗦，见：Absolute Columns。
3. AIR 对 Linux 的支持还是存在缺失，比如无法给窗口加阴影，看来是 Linux 下的 Flash 支持跟不上。

完毕。

Ajax 常见的一种使用方法是加载网页片段填充某个区域。假设我们要在网页 foo.com/index 上请求 foo.com/partial。我们假设 partial 就是 HTML，不涉及 JSON 或 XML 格式。在这种情况下：

1. 使用 XMLHttpRequest 直接访问 partial，获取 responseText 后赋予 index 页面上某个元素的 innerHTML 即可完成。partial 必须是一个纯粹的 HTML 片段（基于以上假设）。
2. 在页面上创建一个隐藏的 iframe, 使用 iframe 的 src 请求 partial, partial 可以作为一个完整的页面，里面包含 JavaScript，由 partial 里的 JS 完成替换 index 上页面片段替换。

第二种看起来更繁琐，但能给我们更多控制权。例如，假如用户直接访问 foo.com/partial（这种情况很容易发生，假设您是 unobtrusive 的拥护者，机会更大，例如需要点击网页上的链接更新某部分内容时，用户使用新窗口打开了改链接）, 你希望她看到的是什么内容呢？

在第一种情况中，用户看到的是代码片段，绝大部分下没有任何样式，也没有任何额外提示，导致用户体验的下降。因为只是一个 HTML 片段，你什么事都干不了。

但在第二种情况下，用户看到内容可能也只是 HTML 片段，但这却是一个完整的页面，一个可以执行 JS 的完整页面。我们只需检查这个页面的 parent 对象有没有我们预设的值，就可以判断它是不是在 iframe 之内了，然后我们可以让它跳转到正常的页面。

Demo: http://realazy.org/lab/xhrvsiframe/

google 良久，从 https://developer.mozilla.org/En/Using_Firefox_1.5_caching 中发现一个 window.onpageshow 事件，window.onload 事件无法在后退的页面中出发，但这个可以，所以解决方案就是它了。

window.addEventListener('pageshow', function(e){
    // 重置你不需要 disabled 的按钮
}, false);

更新：网友岁月如歌的解决方案比我的方案简易和正宗多了：给提交按钮加上 autocomplete="off" 的属性。

This is a discussion of high-level application design in Cocoa that aims to explain the major class roles in an AppKit application and how they are connected. I’ll show you much more detail than simply “Model-View-Controller” and I also give a specific example of how all the concepts apply to a real application.

这是一篇关于 Cocoa 高级应用程序设计的讨论，目的在于解释 AppKit 应用程序中的主类的作用，以及它们间的相互联系。我会向你展示比“模型-视图-控制器”更具体的细节，也会给出一个具体例子，展示这些概念是如何应用到一个真实的程序中去的。

The anecdote 轶事

The other day, I was showing a friend how to program in Cocoa. She is a very good programmer but has never really programmed a user-application — working almost exclusively on embedded and server applications.

不久前的一天，我向一位朋友介绍在 Cocoa 中如何编写程序。她是一位不错的程序员，但之前从没实战过用户交互的应用程序——几乎只编写嵌入式或服务器应用程序。

The experience reminded me that even good programmers can be unaware of basic design traits of user-applications which, while common to user-applications on all platforms, are not common to all programming.

这种经历告诉我，即使是好的程序员也不一定知道用户交互应用程序的设计的基本特性——虽然它在所有平台上的用户交互应用程序中非常普遍，但不见得在所有类型的编程都是常见的。

So even though it’s more “novice” than my regular fare, it would appear that even simple topics can be useful to advanced programmers.

所以，即使这里讲到的比较菜，只是简单的主题，但对高级程序员也会很有帮助。

A starting point 开门见山

“Model-View-Controller” is the term normally used to describe the structure of modern applications. Almost every discussion of application design begins with it and I guess I will too. It looks like this:

“模型-视图-控制器” 是用在描述现代应用程序结构的一个常见术语。几乎所有关于应用程序设计的讨论都会以它开头，我猜我也不能免俗。它大概是这个样子：

Your document data (the “model”) notifies the intermediary (the “controller”) and it tells your user interface elements (“the view”) to update. Going back in the other direction, user actions in the user-interface trigger notifications to the intermediary which modifies the data.

文档的数据（“模型”）通知中间件（“控制器”）并告诉用户界面元素（“视图”）更新。从反向来说，中间件响应用户界面中的用户动作，并对数据进行修改。

The rationale may not be immediately obvious. Let me explain it this way:

这个原理并不是那么浅显易懂。看我这样解释行不行：

User applications are big and complex — even seemingly simple applications. To manage complexity, everything is compartmentalised. To keep the boundaries between compartments clean, connections between compartments should be simple and generic.

用户应用程序是大型和复杂的——看起来简单的应用程序也是如此。为了管理复杂性，所有东西都划分管理。为了能保持部件边界的清晰性，它们之间的联系应该是简单和通用的。

Obviously, you don’t want the model and view to be the same thing because then, there is no separation at all and the application will be a tangled mess.

显然，你并不想把模型和视图搞成一样的东西，因为完全没有分离的话只会让应用程序一团糟。

Direct connections between model and view are normally frowned upon because it creates a situation where they must know too much about each other’s internal state to interoperate. Instead, a controller object (which knows about connective state but little else) is used to keep the interaction simple and generic.

如果模型和视图之间的联系是直接的，要想实现互用，两者必须深入了解对方的内部状态，这是一个纠葛的过程。反之，使用一个控制器对象（它能掌握大部分联系状态，其他的基本不管）来管理模型和视图的交互，就简单和通用多了。

Better than Model-View-Controller 比模型-视图-控制器更胜一筹

These traits of Model-View-Controller are all good things but in reality, it says little about how to assemble an application. Real applications have many more traits in common than a separation between model and view.

模型-视图-控制器的原理非常好，但在实际操作中，它基本上没有指明应用程序该如何组织。真实的应用程序有着比模型和视图的分离更多的通用特性。

A more complete diagram of a typical application’s design would look like this:

这是一个更完整的流程图，典型的应用程序设计更应如此：

In this diagram, solid black arrows indicate construction and hierarchic ownership. Feint gray arrows indicate communication in response to changes.

在此图中，黑色的实心箭头表示结构和层级属主；灰色空心箭头表示对变化作出响应的通讯。

Application instance 应用程序实例

The application instance incorporates the program entry point and the event loop (which handles all user events like mouse and keyboard actions). As the starting point of the program, the application instance constructs the other top-level objects in the program.

应用程序实例包含了程序入口的指针和事件循环（它处理所有的用户事件，如鼠标和键盘事件）。作为程序的起点，应用程序实例建立了程序中其他顶层的对象。

Application controllers 应用程序控制器

The term “Application User Interface” is used in this part of the diagram to refer to elements of the user-interface that are not part of the document or the main window.

此图中的术语“应用程序用户界面”用于非文档或主窗口的用户界面元素。

These objects are constructed by the application at startup. They should only handle things which exist before the main window or main document is open or which fall outside the bounds of these areas. Example behavior here includes the application preferences window and the Mac OS X menu bar.

这些对象在应用程序启动时就构建。它们应该只处理出现在主窗口之前，开启主文档之前或超出这些范围边界的东西。这种行为的例子包括应用程序偏好设置，以及 Mac OS X 的菜单栏。

Document instance 文档实例

This is the first point where a programmer begins to exercise control over the program’s behavior. The document loads or constructs the program’s data and constructs the windows to show it.

这是程序员控制程序行为的起点，文档载入或构建程序数据，并构建函待显示的窗口。

A common mistake is to think that your program doesn’t have a “document” so you shouldn’t model a document class. In reality, if a program does anything then it is changing some piece of data (a preference file, a set of objects for rendering in OpenGL, the result of a calculation). You should design your program with this piece of data as the document. Even if your program only has one window, even if it only works with the same piece of data, even if you aren’t writing a “Cocoa Document-based Application”; you should always have a class at the heart of your program which can be called “the current document”.

认为程序没有“文档”而不应把文档类模型化，这是一个常见的错误。实际上，程序只要干了活就会改变某些数据（比如偏好设置文件、OpenGL 中的渲染对象集合、计算的结果等等）。设计程序时应该跟文档一样考虑这些数据。你的程序即使只有一个窗口，即使以相同的数据运行，甚至你编写的不是“Cocoa 基于文档的应用程序”，心中都应该怀有这样一个类——你可以称之为“当前文档”。

Window controllers 窗口控制器

A window controller is the class responsible for loading a window and putting it on screen. The window controller is responsible for giving context to the views and controls within the window, connecting them to data controllers which will provide them with data.

窗口控制器是负责把窗口载入屏幕的类，负责给窗口内的视图和控制器提供上下文，连接到提供数据的数据控制器上。

It is common for window controllers to double as data controllers for some functions since the window controller knows the state required to make the connection. This is not a bad thing in itself but should be resisted in the long term since it leads to bloat in the window controller (which often has a lot of work to do already). Generic, data-specific controllers should be used for this task.

窗口控制器在一些函数上比数据控制器多一倍，这种情况是常见的，因为它需要知道产生连接的状态。这不是什么坏事，但从长远来说应该要抵制，因为它会导致窗口控制器自身的膨胀（它早已排满了各种任务）。一般来说，应该使用特定数据的控制器完成这些任务。

User Interface Elements 用户界面元素

Where possible, these should be generic elements: buttons, text display, image display. They end up performing specific actions when connected (through controllers) to their contextually supplied data.

可能的话，用户界面元素通常包括：按钮、文本显示和图片显示等。（通过控制器）连接相应的数据时，它们最终会执行指定的行为。

User interface elements are normally hierarchic. The screen contains windows; windows contain views; views contain subviews. One window is normally in front (main window) and one view within this window is normally the focus. The application’s “event loop” will send keyboard actions, mouse events and menu selections to this focus object. Unhandled events get passed up through the hierarchy so that parents can handle events that their children don’t handle.

用户界面元素通常是分级的。屏幕包含窗口；窗口包含视图；视图包含次级视图。窗口一般在最前（主窗口），这个窗口内视图一般也会聚焦。应用程序的“事件循环”会给这个聚焦的对象发送键盘键盘动作、鼠标事件和菜单选择等行为。未处理的事件可以跨越层级，所以父层能够处理子层未能处理的事件。

The handling of events should be managed as low in the hierarchy as possible. Again, consolidation in parents leads to bloat. Even “small” applications can become very big.

事件应该尽可能在低的层级上处理。父层事件的集中会导致应用程序的膨胀。就算是“小”的应用程序也能变得很大。

Data Controllers 数据控制器

These should be as generic as possible. Their purpose should be to relay information from a source to a destination about data changes.

数据控制器应该尽可能通用化。它的目的应是分发从源到目标中关于数据变化的信息。

The simplest manifestation of a data controller is for a third-party to establish or enable the Observer design pattern between two objects.

数据控制器最普遍的表现是为第三方建立或启用两个对象之间的观察者设计模式。

The worst approach (sometimes called an anti-pattern) is an all encompassing arbiter object that receives every change request the program makes, performs the change and then updates everything that needs to be updated. This approach is unsustainable on an application-wide scale. Decomposition is key — data controllers should have small, focussed scope.

最差劲的方法（有时被称为反模式）是使用一个包办一切的对象接收程序产生的一切变化请求，执行变化然后更新所有需要更新的东西。这种方法无法支撑应用程序级别的扩展性。分解才是关键——数据控制器应该是一个小型的、集中的范围。

An example application 一个实例

Now we’ll look quickly at what this means in an AppKit-based application. This application is a simple program that creates and edits lists of names. I know that’s a pretty trivial thing for a program to do but the example must be simple so I can describe it here properly.

现在我们快速浏览一下它们在基于 AppKit 的应用程序中的含义。这是一个简单的应用程序，用以创建和编辑名字清单。我知道对程序来说这是在微不足道，但为了表述清晰才让它必须简单的。

You can download the project described in this diagram, although it isn’t necessary to understand the discussion.

你可以下载这张图所描述的应用程序，尽管对理解这个讨论而言不是必要的。

The application object is an unmodified NSApplication. This will almost always be the case in any Cocoa Application. You can achieve most customisation of the NSApplication object through data (in the Info.plist file) or by attaching an application delegate object (which can intercept control at predetermined points). The application instance handles our startup, event loop and contruction of documents (I have discussed how a Cocoa application loads in a previous post).

这个应用程序对象是一个未经修改的 NSApplication, 在 Cocoa 应用程序中几乎都是这种情形。你可以通过数据（在 Info.plist 文件中）或附加一个应用程序代理对象（它可以侦听特定情况下的控制）实现 NSApplication 的大部分定制。这个应用程序实例处理我们的启动、事件循环和文档的构建（我在前一篇 blog 中讨论了 Cocoa 应用程序是如何载入的）。

This application doesn’t have any preferences or significant data outside the scope of the document, so the “Application Controllers” section just has the Main Menu in it.

这个应用程序没有偏好设置，也没有超出文档的重要数据，所以“应用程序控制器”部分只有一个主菜单。

Documents in AppKit act as both a data controller for the data (in this case, an array of strings) and the window controller for the main document window. The document handles saving and reading to and from any file on disk. This could be done with basic NSKeyedArchiver methods to turn an array of strings into an NSData object for writing to disk. The window is loaded automatically from the window NIB file (specified in the program’s Info.plist file).

AppKit 中的文档不仅作为数据（在这个例子中是字符串数组）的数据控制器，还充当主文档窗口的窗口控制器。这个文档还处理磁盘上文件的读写，是通过基本的 NSKeyedArchiver 方法把字符串数组转为可写入磁盘的 NSData 对象实现的，而窗口是从窗口 NIB 文件（在程序的 Info.plist 文件中指定）自动载入的。

The NIB file for the document contains an NSArrayController which is connected to the list of names from the document via the appropriate keyPath. This allows the NSArrayController to issue key value observing notifications when it changes the array and similarly allows it to update automatically when something else changes the array on the document.

文档的 NIB 文件含有一个 NSArrayController, 它通过合适的 keyPath 从文档连接到名字的清单。这让 NSArrayController 在改变数组的时候可以发出侦听键值的通知，或类似地在其它东西改变文档数组时也允许它自动更新。

The NIB file for the document also contains the window, which in turn contains an NSTableView. The NIB file specifies that the NSTableView’s only column (displayed using the NSTextCell) should get its data from the NSArrayController. In this way, the table is updated to display the list of names contained in the document.

文档的 NIB 文件也含有依次包含 NSTableView 的窗口。NIB 文件规定 NSTableView 唯一的栏（使用 NSTextCell 来显示）应该从 NSArrayController 中获取数据。在这种情况下，文档内的表格作出更新以显示名字清单。

The NSTextCell displays the name for each row and allows editing. If an entry is changed in this way, notifications are sent back through the NSArrayController to the document.

NSTextCell 在每一行上显示名字，而且允许编辑。如果某个条目这种方式下改变，NSArrayController 会把通知发送给文档。

Similarly, the “Add New Name” button can add a new object by communicating with the NSArrayController, asking it to create a new object and insert it in the array, which triggers all relevant change.

类似地，”Add New Name” 按钮通过跟 NSArrayController 的通讯可以添加一个新对象，要求它创建并插入到数组中，这会触发所有相关变化的传播。

Conclusion 总结

All of this may seem like a lot of work — setting up connections and controllers and notifications. When starting a new program, you may think that many of these elements don’t apply to you. Be careful — don’t chase false simplicity.

所有这些需要的工作量看起来很大——设置连接、控制器和通知。当开始一个新的程序，你可能认为这些元素的大部分都不适用。小心——不要追求失败的简洁性。

Remember, Cocoa was written to make the approach described in this article easier than the alternatives. Classes like NSArrayController and protocols like NSKeyValueObserving and NSKeyValueBindingCreation make connecting large amounts of data as simple as point and click in Interface Builder. In many cases, it ends up being faster than manually connecting a button or text field directly to a method on your document class.

记住，对于本文描述的各种方法，Cocoa 是本着更方便而非其他目的而生的。诸如 NSArrayController 等类、诸如 NSKeyValueObserving 和 NSKeyValueBindingCreation 等协议，让大量数据的连接跟 Interface Builder 中的指向和点击一样简单。

You will always have change behaviors that cannot be connected using these generic objects but following the same structural patterns that they use will keep your application clean and make it work better within Cocoa.

你总会碰到不能使用这些通用对象连接的变化行为，但遵循这些它们用到的相同结构模式会让你的应用程序更清晰，也能更好地运行在 Cocoa 下。

<form method="post" action="_some_action_uri_" id="_form_id_">
<input type="hidden" name="method" value="1" />
</form>

试想一下，使用 document.getElementById('_form_id_').getAttribute('method') 会出现什么情况。Firefox 3, Safari 3, Opera 9.5 都会得到预期 “post”, 但是IE 6 和 7 就没有那么幸运了，得到的是一个 object: 其实就是 <input type="hidden" name="method" value="1" /> 这个元素。

因此，为避免混淆和挽救IE，最好是，as the title.

一个已经有内容的 textarea 元素，在执行该元素的 .focus() 方法后，不同的浏览器有不同表现。我们的预期是能够出现在内容后面，但只有 gecko 浏览器能做到。

修复

注意：这个函数不能直接运行，函数内的 isIE, isOpera 和 isWebkit 需要你的库提供或你编写，这并不难，对吧。

function fixTextareaFocusCursorPosition(elTextarea){
    if (isIE || isOpera){
        var rng = elTextarea.createTextRange();
        rng.text = elTextarea.value;
        rng.collapse(false);
    } else if (isWebkit) {
        elTextarea.select();
        window.getSelection().collapseToEnd();
    }
}

中国特色的网站上有一个很中国特色的应用就是，在一个输入框 focus 时自动帮你把内容复制到了剪贴板中。老实说访问剪贴板是个不安全的操作，因此即使是 IE, Windows 在后来的升级中都加入是否允许访问剪贴板的提醒。如果能够做到跨浏览器的“邪恶地悄无声息”地实现中国特色的剪贴板应用，确实是个不小的挑战。

遗憾的是老外在 2006 年就帮我们做到了：使用 Flash。参考 Clipboard Copy. 原版没有考虑不安转或禁止 Flash 的情况，我做了一个小改进：

function copy(inElement) {
    var get = function(id){
        return document.getElementById(id);
    },
        elId = 'flashcopier',
        embedId = 'flashembed';

    if(!get(elId)) {
        var divholder = Document.createElement('div');
        divholder.setAttribute('id', elId);
        document.body.appendChild(divholder);
    }

    var divholder = get(elId);
    divholder.innerHTML = '<embed src="http://static.hainei.com/swf/cp.swf"\
                    FlashVars="clipboard='+encodeURIComponent(inElement.value)+'"\
                    width="0" height="0" type="application/x-shockwave-flash"\
                    id="'+embedId+'"></embed>';

    // 检测是否安装了 Flash
    var flashObj = window[embedId] || document[embedId] || {};
    if (!flashObj.SetVariable){// 没有 flash
        try {
            return window.clipboardData.setData("Text", inElement.value);
        }
        catch(ex){
            return false;
        }
    }

    return true;
}

原版是 GPL 的，这个版本也请爱咋咋用……

注意，这不需要任何 JavaScript，是浏览器内部实现的功能。很遗憾的是到目前为止只有 Opera 9+ 有部分实现，作为前端开发者，每天都在为表单验证、自动完成等提升表单用户体验的事情上拼了老命，重复发明轮子。好消息是，基本上这些都可以通过 JavaScript 来模拟实现，项目当然有人在做了：webforms2，不妨下载一试。

当然，它们是根据表单的字段名称进行猜测与匹配的。如何给表单字段起个好名字，以方便自动填写工具的匹配，就变得有必要起来。

既然说“标准”，那名字肯定不是乱取的。RFC3106 据此而生。比方说，用户 ID 使用 Ecom_User_ID, 密码使用 Ecom_User_Password 等等，你可以访问该页面查看更多的对应实例。虽然商业气息比较浓重，但不妨碍我们的使用，以及给用户带来的便利。