Last week I started to implement a (still basic) low-level Text Selection API which especially the high-level form widgets like TextField and TextArea can make use of.

As some of you might already know working with the native Selection and Range / TextRange objects is not one of the things a developer dreams of

However, looking at the basic implementation one thing is quite amazing. Besides a little tweak for Opera three (Gecko, Safari and Opera) of the four major browsers share the same implementation.
Sure there will be some more differences to encounter when the development of this low-level layer moves on, but the start looks quite promising.

With the recent release of Safari 3.1 the WebKit team has completely reworked the handling of key events. John Resig has an interesting blog article with some details. Safari 3.1 now behaves pretty much like Internet Explorer and is in general much more sane than before. For instance, all those strange key codes larger than 64000 for special keys are gone and finally modifier keys like "shift" and "control" fire key events as well. Interestingly, Safari is now the first browser to support the key identifier property defined in the DOM level 3 event specification. In qooxdoo we already emulate this property in key events for quite some time now, and it really helps to simplify key handler code in our widgets.

Unfortunately, this change in Safari 3.1 broke the existing qooxdoo key event handler. But it is already fixed and available in our subversion repository for legacy_0_7_x branch and trunk. The fix was basically to detect the current WebKit version and use the existing Internet Explorer key handler code also for Safari 3.1 and above. Since all browser quirks are handled separately this was a pretty simple fix. Of course, it will be part of the next minor release 0.7.4 as well as the final 0.8. If you need Safari 3.1 support now, please checkout the latest version from the legacy_0_7_x branch.

In qooxdoo 0.8 we will introduce the concept of widget decorators. This has already been described in an earlier blog article. Decorators allow a widget's background to be styled independent of the widget's content. To demonstrate the flexibility of the decorator concept I have written a decorator, which uses native CSS rounded borders in Firefox and Safari/Webkit and emulates the same behavior in Internet Explorer. The screenshot shows the same qooxdoo 0.8 application in Internet Explorer 7, Firefox 3 Beta 3, WebKit r30082 and Firefox 2.0.11.

The widget shown in the screen shots is generated by the following snippet of qooxdoo code:

 
doc = new qx.ui.root.Application(document);
 
var border = new qx.ui.decoration.RoundedBorder().set({
  radius: [10, 20, 30, 40],
  width: [3, 10, 20, 5],
  color: ["red", "green", "yellow", "blue"],
  backgroundColor: "gray"
});
 
doc.add(new qx.ui.basic.Label().set({
  html: qx.bom.client.Engine.NAME,
  decorator : border,
  width: 140,
  height: 100,
  padding: 20
}), 10, 10);

I think the most interesting question is about the IE implementation. Since IE has no native CSS rounded border support, the borders must be rendered using a different technique. A common approach is to render the borders using pixel-sized DIV elements like e.g. RUZEE.Borders does. We have used a different and in my opinion much more powerful approach.

We use VML to render the background including the border. The VML code is dynamically created and inserted into the decoration DIV using plain innerHTML. Since the decorator is informed about size changes by the qooxdoo layout engine, it can update its borders accordingly. The rendering quality is amazing and looks pretty much like the best native browser implementation of Firefox 3. This is the code automatically generated and applied by qooxdoo:

 
<style>v\: * { behavior:url(#default#VML);display:inline-block }</style>
 
<xml:namespace ns="urn:schemas-microsoft-com:vml" prefix="v" />
<div style="left: 10px; width: 140px; position: absolute; top: 10px; height: 100px">
<div style="z-index: 10; left: 25px; width: 85px; position: relative; top: 23px; height: 37px" usehtml="true">mshtml</div>
<div style="z-index: 5; left: 0px; position: absolute; top: 0px">
    <v:group style="left: 0px; width: 140px; position: absolute; top: 0px; height: 100px; antialias: true" coordsize = "140,100">
    <v:shape style="width: 140px; height: 100px" coordsize = "140,100" fillcolor = "gray" path = " m10,1 ns l120,1 qx139,20 l139,70 qy110,99 l40,99 qx1,60 l1,10 qy10,1 x e"></v:shape>
    <v:shape style="width: 140px; height: 100px" coordsize = "140,100" fillcolor = "red" path = " m10,3 ns at5,3,15,13,10,3,5,3 wa0,0,20,20,0,0,10,0 wa100,0,140,40,120,0,140,0 at110,3,130,23,130,3,120,3 x e"></v:shape>
    <v:shape style="width: 140px; height: 100px" coordsize = "140,100" fillcolor = "green" path = " m130,13 ns at110,3,130,23,130,13,130,3 wa100,0,140,40,140,0,140,20 wa80,40,140,100,140,70,140,100 at110,60,130,80,130,80,130,70 x e"></v:shape>
    <v:shape style="width: 140px; height: 100px" coordsize = "140,100" fillcolor = "yellow" path = " m120,80 ns at110,60,130,80,120,80,130,80 wa80,40,140,100,140,100,110,100 wa0,20,80,100,40,100,0,100 at5,40,45,80,5,80,25,80 x e"></v:shape>
    <v:shape style="width: 140px; height: 100px" coordsize = "140,100" fillcolor = "blue" path = " m5,60 ns at5,40,45,80,5,60,5,80 wa0,20,80,100,0,100,0,60 wa0,0,20,20,0,10,0,0 at5,3,15,13,5,3,5,8 x e"></v:shape>
    </v:group>
  </div>
</div>
 

Generated HTML for Internet Explorer

The first two lines are required to enable VML support and are only added once into a page. Note that only one of the DIV elements contains VML code. The rest is typical HTML code generated by the qooxdoo GUI toolkit, which does all the layouting itself, just using JavaScript. It consists of a couple of nested, absolutely positioned DIV elements with the appropriate CSS styles applied.

The code for Firefox is much simpler and just sets the browser-specific CSS styles:

 
<div style="position: absolute; z-index: 0; left: 10px; top: 10px; width: 140px; height: 100px;">
<div style="position: relative; z-index: 10; left: 25px; top: 23px; width: 85px; height: 37px;">gecko</div>
<div style="border-style: solid; border-color: red green yellow blue; border-width: 3px 10px 20px 5px; z-index: 5; position: absolute; left: 0pt; top: 0pt; -moz-box-sizing: border-box; width: 100%; height: 100%; background-color: gray; -moz-border-radius-topleft: 10px; -moz-border-radius-topright: 20px; -moz-border-radius-bottomright: 30px; -moz-border-radius-bottomleft: 40px;"></div>
</div>
 

Generated HTML for Firefox

Native browser support

The quality of rounded border implementations differ a lot between browsers. The CSS3 draft defines the property border-radius and a property for each corner like border-top-left-radius. These properties take two values, one for the horizontal radius and one for the vertical radius. That way it is possible to define (quarter-)elliptical borders. If only a single value is given, the border is (quarter-)circular.

Current browser implementations

• Firefox 2: Firefox supports only circular borders. Border definitions always take a single parameter - the radius. The CSS property is called -moz-border-radius and -moz-border-radius-topleft, respectively. -moz-border-radius supports the CSS shorthand mode. If only one parameter is given, the radius of all four border is identical. If four parameters are defined, the radius for all four corners is set individually. The rendering quality is very poor since Firefox 2 does not use anti-aliasing to render the border (cf. screen shot).
• Firefox 3: The same as Firefox 2 but borders are rendered using anti-aliasing, which looks much better (thanks to the Cairo 2D graphics library).
• Safari/WebKit: The CSS property names differ from the W3C spec (-webkit-border-radius and -webkit-border-top-left-radius). Besides that, WebKit implements pretty much the CSS3 standard. Rendering looks fine as long as all border widths are equal. If they differ, the rendering looks quite ugly (cf. screen shot). This has already been reported in the WebKit Bugzilla and hopefully is going to be fixed soon.
• Opera: Opera also does not support CSS rounded borders but there is a description online on how to emulate them using SVG backgrounds.
• Internet Explorer: No native support either. I suppose the VML approach presented here works only well in the controlled environment of the qooxdoo widget toolkit, but I may be proved wrong.

Adobe AIR is a new system to allow typical web applications to better integrate in the desktop. This includes access to file system resources, a local SQL database, and a controlable chrome for the "browser" window and some other goodies. The whole thing uses Webkit to render HTML pages. This is a great choice -- for qooxdoo based applications Webkit currently easily outperforms the other engines.

I have integrated AIR into the build system (trunk only). For a small demonstration I have created an AIR based API-Viewer of the current trunk. This can be used as an offline application. Including all API data the download is about 700 KB which is really small. (I had to zip the download again because of security limitations features of wordpress.)

In the current trunk each skeleton based application can be converted to an AIR application easily. Just execute "make air" in the root folder of your application. Unfortunately this feature required changes in a lot of files. This will be a trunk-only feature for now and will not be backported to legacy_0_7_x.

Download AIR based qooxdoo API Viewer (r9197)

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

Safari support for qooxdoo is coming along nicely. qooxdoo support for the nightly build of WebKit is near to complete. Most demos and examples are working, including the API viewer . The screenshot shows the “At a Glance” example running in WebKit. Safari 2.0.4 shipped with the current OS X 10.4 is usable but still has some rendering issues.

For the next qooxdoo release we plan to fully support WebKit, which hopefully builds the basis for the next major release of Safari shipped with the upcoming OS X 10.5. We decided to target WebKit because of its improved standard support and its dramatically faster JavaScript engine. Some qooxdoo examples are up to seven times faster using WebKit compared to Safari 2. Even if we would fully support Safari 2, it will never be a good platform for big JavaScript applications.

A interesting read at webkit.org: David Hyatt explains the problems with the execution order of stylesheets and scripts and the well known "Flash of Unstyled Content" (FOUC) problem. Thank you David for this insight.

This is a small continuation of our original box model test. We added some tests to explicitely check for overflow problems already noticed during development of qooxdoo 0.5. We simply wanted to be sure about the current state of browsers before starting the development our new layout engine.

Results

Good news first: Konqueror (version 3.5.3) renders equally perfect for both overflow:hidden and overflow:visible. The box-sizing is correct. In all examples! Again kudos to the developers!

Opera 9.0 shows the same errors for overflows as without overflows. Fine. We are already happy if we need not to handle another special situation...

Internet Explorer 6.0 renders 2 boxes smaller in Standard Mode and even completely fails to render 2 boxes using "overflow:hidden" in Quirks Mode. The boxes were already wrong layouted before. So luckily it is not getting worse.

Firefox 1.5 shows differences compared to Firefox 1.0. Now we noticed the first box model difference between Gecko 1.7 and Gecko 1.8. Firefox 1.5 renders two more boxes wrong than without the overflow statement, both using "box-sizing:border-box". All other boxes are identical.

Surprisingly, for Firefox 1.0 the "overflow:hidden" fixes all the bugs on the right columns, i.e. making "box-sizing:border-box" to work perfectly, but breaking many boxes on the left side. This means Firefox 1.0 is the only browser in this roundup which fails to render the W3C-default "content-box". In general it supports all other CSS standards used in the tests (compared to Internet Explorer for example).

Complete set of test scenarios

• Standard Mode, Overflow visible
• Standard Mode, Overflow hidden
• Quirks Mode, Overflow visible
• Quirks Mode, Overflow hidden

Updated Screenshots

• Firefox 1.0 (Overflow, Visible, Overflow: Hidden)
• Firefox 1.5 (Overflow: Visible, Overflow: Hidden)

In preparation of our new layout engine we did a roundup of all modern browsers' abilities to render under the two different box models. It definitely is one of the most compelling questions in advanced web development: "Which browser supports what layout features and how well?". Like most other javascript toolkits qooxdoo currently depends on a box-sizing of "border-box". While not being the default box model in current browsers, many people think that it is the most natural way to define web layouts, if not layouts in general. The W3C-favored "content-box" model on the other hand is often seen as a rather counter-intuitive solution. Our tests particularly reveal how well the common use cases work in "border-box" regime.

Tested browsers and Screenshots

• Firefox 1.5 (Standard, Quirks)
• Internet Explorer 6.0 (Standard, Quirks)
• Internet Explorer 7.0 Beta 3 (Standard, Quirks)
• Opera 9.0 (Standard, Quirks)
• Konqueror 3.5 (Standard, Quirks)
• Safari 2.0 (Standard, Quirks)

Firefox 1.0 and Firefox 2.0 beta 1 behave identically to Firefox 1.5. Browsers based on Gecko 1.6 behave differently (screenshots may be provided soon).

Results

Konqueror is the only current browser which renders all test examples flawlessly. There seems to be no box model layout bug. Just perfect. Kudos to the developers! Internet Explorer 7.0 (only in Standards Mode), Firefox 1.5 and Opera 9.0 show perfect results as well, but only in the "content-box" tests. Unfortunately, each of these browsers exhibits individual problems in the "border-box" model.

Internet Explorer 6.0 and Internet Explorer 7.0 render equally (wrong) in Quirks Mode. Internet Explorer 7.0 comes with support for stretching (i.e. define left and right or top and bottom together) and min- and max-dimensions, but only in Standards Mode. At least one of the very few improvements due to the IE7 revamp. Both Internet Explorer versions do not support the handy "box-sizing" property at all. Choosing either standard compliant or quirks mode is achieved by an appropriate doctype declaration as usual. Keeping in mind IE's inability to work in a "border-box" regime, it is obvious that the second part of each test document (the two columns to the right) are always wrong. While Internet Explorer 7.0 renders flawlessly in Standards Mode, Internet Explorer 6.0, lacking many CSS features, only renders exactly one of all the squares correctly. Which one depends on the current render mode, of course. Quite dissappointing, but not unexpected results.

Mozilla Firefox as of version 1.5 shows an almost perfect rendering behavior. Surprisingly, it doesn't follow the "box-sizing" rule, if no width or height is explicitly defined. This means for example that it isn't possible to only define a min-width without setting a (bogus) width as well. Long distance calling cards. A work-around for such a bug in "border-box" mode could be to add an appropriate width or height to each min-width, min-height, max-width or max-height statement. As already mentioned the W3C default value "content-box" yields absolutely perfect results.

Opera 9.0 has many strange problems. Sometimes the box is too large, sometimes too small. It appears to be somewhat inconsistent as well: while the box widths are often ok, the box heights are plain wrong. Hard to make sense of such an asymmetric behavior. Opera 9.0 in the "content-box" model is perfectly well-behaved, though.

Please have a look at our tests documents online, either our standard compliant test or quirks mode test.

Any ideas or comments welcome!