The third in a popular series of DOM scripting primers. This example demonstrates a consistent cross-browser, cross-platform interface for keyboard input monitoring. The very simple example script is inline, commented and should need little explanation (though at least some will follow in the near future). The pivotal function is attachKeyboardListeners. An example:
attachKeyboardListeners(el, charListener, keyListener, shortcutCharListener, navKeyPressListener, thisObject, suppressControlKeyAutoRepeat);
The first argument is the element in question, which is typically an input control, but may also be another type of element that has been made editable or a document. The next four arguments are listener functions for key actions, characters rendered, shortcut combinations (e.g. Ctrl+C on Windows and Meta+C on Mac) and navigation key presses (typically canceled by widgets as seen in the spinner demo). The last two arguments set the this identifier for the listeners and prevent duplicate key actions to pass through to the key listener. All but the first two arguments are optional.
Once again, there is no need to date scripts with logic that branches based on observations about currently used browsers (cross-browser scripting is largely about abstractions, not observations). It should be clear that scripts that are dated in such a way will invariably need to be changed and re-tested as new browsers and browser versions are introduced. The idea that such a strategy would save time is patently absurd. Anyone making that pitch is either confused or trying to sell something while investing as little of their current time as possible (with the possibility of selling more time in the future, of course).
There are numerous legitimate uses for such a script, including monitoring and/or reporting the length and/or content of user input in something approaching an efficient manner. Unfortunately there are lots of possibilities for abuse as well (e.g. stealing credit card numbers).
As for efficiency, the typical auto-complete feature (usually a canned solution) found on the Web today is so inefficient as to slow down the entry of characters, which can be extremely annoying to proficient typists. Furthermore, such solutions are usually built on top of huge, complicated and often dubious libraries or frameworks, which will likely need periodic maintenance just to keep pace with the latest versions of four or five browsers. For instance, the author recently attempted to sign up with a "Web 2.0" music site, but was unable to enter his name into the first input on the sign-up form due to the age of the browser in use at the time. This is the perfect example of overzealous script developers (or cobblers) getting in the way of a site's primary goal (to sign up visitors in this case). What was the problem? Some wacky special effect that was triggered by keyboard activity seemed to be the culprit. It wasn't investigated thoroughly as it was preferable to just find another site.
This code has been tested successfully (meaning consistent results) in Firefox 1–3.6, Opera 7–10.5, IE5.5–8, Netscape 6.2–9, Safari 3–4 and Chrome 3–4 for Windows. Some of the browsers have also been tested on Macs. Note that key actions that cause an input control to lose focus (e.g. S shortcut typically loads the OS Save As dialog) will usually result in a loss of keyup events as the test callbacks do not attempt to prevent the default action.
The following tests are a proving ground as empirical data is useful to ferret out design failures and this problem is widely believed to be impossible to solve in cross-browser fashion. Once it has been determined that the design is sound (as best that such a thing can be determined on the Web), the code will be added to My Library.