Since the 0.6.3 release, qooxdoo includes a complete rewrite of the key event handling layer. The old one was basically a wrapper for each browsers native key event handler. It fixed many cross-browser issues but nonetheless the differences between browsers were still visible to the application developer. The new key handler aims to unify key event handling across all supported browsers (Internet Explorer, Firefox, Opera, Safari) so that qooxdoo application developers always see the same behavior. This ambitious task turned out to be harder than expected...

Key events are one area of web browser functionality where standardization has not yet taken place. Although there is a W3C draft for keyboard events, it is more or less useless because no browser currently implements it. Even if it would be implemented, it would not solve all problems, because the standard is still incomplete. Pretty sad. For example, it has no concept of repeated key events which are fired repeatedly while the key is held down.

At first glance key event handling doesn't look so different across browsers. All major browsers support the three key events keydown, keypress, keyup and all key event objects have a keyCode property and properties for the modifier keys altKey, shiftKey, ctrlKey, metaKey. Unfortunately, under the hood all browsers behave quite different. Even the same browser can behave different on different platforms, e.g. Firefox under MS Windows and Mac OS X, respectively.

Key event handling is so challenging because of (at least) the following five shortcomings:

1. Key code vs. Char code: Key events return codes for the actual key that is pressed (the key code) and the character that will be printed on screen (char code). Theses codes are represented as numbers and it is sometimes hard to figure out if a given code is to be understood as a key code or rather a char code. This is a severe problem because some numbers can be interpreted as either key code or char code. For example in key press events in Opera it cannot be decided whether the returned code is a key code or a char code.
2. Keys that require shift on some keyboard layout: The key code of keys that require the shift key on some keyboard layouts are not reliable. The key code which is generated depends on the current language-specific keyboard layout of the user. The key “#” for example can be reached on a German keyboard layout without the shift key and generates the key code 35, while the same character composed with Shift+3 on an American layout produces a key code of 51.
3. Repeated key events: If the user keeps pressing a key the browsers fires some events repeatedly. Normally, only the keypress event is expected to be repeated, but no other events. Under Windows however, both Internet Explorer and Firefox repeat the keydown event as well.
4. Incomplete event sequences: Not every browser fires for every key the complete event sequence of keydown, keypress and keyup. Internet Explorer does not fire keypress events if the corresponding key is non-printable (i.e. function key F1). Firefox does not fire keypress events for modifier keys (i.e. Ctrl or Alt) and Safari does not fire any key events for modifier keys at all.
5. Char code only reliable in keypress events: Only Safari sets the char code also in keyup and keydown events. The good news is that the character code in keypress events is reliable and always represents the Unicode number of the character that would be printed on the screen.

qooxdoo's new key handler solves most of above challenges by browser specific key handlers which differentiate between key and char codes and normalize the event sequence. This means for example that repeated keydown events in Internet Explorer are intercepted and passed on as keypress events and that the missing keypress events for special keys are synthesized if the corresponding keydown event is detected. To simplify the programming interface for qooxdoo developers we chose the W3C draft for orientation and implemented their keyIdentifier property. The keyIdentifier maps the key codes to a (human readable) key identifier strings. To prevent the developer from accidentally using keys which seem to be working in one browser but might not work in another, we introduced a white list of keys which can be detected reliably with the new key handler.

Unfortunately, a completely unified key handler is still not possible with today's browsers. Issues like the ambiguity of Opera's key code in keypress events or Safari not firing any key events for modifier keys can only be solved by the browser manufacturers/programmers. Nonetheless, we think that we came pretty close to the, to our knowledge, best possible solution and can offer one of the most advanced key event handlers out there.

For more detailed information you may consult the corresponding documentation of qooxdoo's new key handler and the following sources:

• Document Object Model (DOM) Level 3 Events Specification
• Mozilla Developer Center on DOM events
• Hallvord R. M. Steen about key events

Today we have added a new qooxdoo tutorial to our Wiki. It gives a step by step introduction of how to download and set up qooxdoo and how to build a first qooxdoo "Hello World" application in just 10 minutes.

This tutorial shows how to set up a new qooxdoo project using qooxdoo best practices. This project can serve as the basis for more complex qooxdoo applications.

The tutorial is targeted mainly at qooxdoo newbies who want to get an idea of what qooxdoo is but also advanced qooxdoo users might be interested to see how we suggest building new qooxdoo applications.

The guys at ajaxian.com have reported about a current survey regarding the popularity of common AJAX frameworks. It is quite clear why prototype is the winner. It's well-known, small and easily embedable into existing pages. However I think it is interesting that Mochikit is less widely used, because the targets of these libraries are comparable in my opinion. And Mochikit does not depends on extensions of native objects (especially Object.prototype) which makes it the better choice.

I should mention that in my opinion the whole survey is quite problematic because of their comparison of different levels of so named "AJAX frameworks". For a next survey I would suggest to divide the list into these groups:

AJAX wrappers & DOM utilities:

• Prototype & Scriptaclous & Rico
• Moo.fx
• jQuery
• Yahoo UI
• Mochikit
• XAJAX
• DWR (includes backend code, too)

Framework & Toolkits:

• Dojo
• Atlas
• GWT
• qooxdoo (seems to be missing ;)) 

I've grouped together Scriptaclous and Rico because they both depend on Prototype which means they are more or less an extension of this library and not a real separate solution.

What do you think?