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.

I always wanted to play with the browser's canvas element but never really found the right toy project. Then I read Ariya Hidayat's blog post "Let there be color". He has implemented the HSL color pie using Qt's 2D drawing canvas. How hard would it be to put something like this into the browser? I decided to try the port of his code to JavaScript and render the pie using only canvas. If this worked out maybe I could embed it into nice little qooxdoo windows.

Once I figured out how to realize "putPixel" and "getPixel" functions in canvas the port was merely a copy and paste with some minor changes. Right now I use the canvas methods "getImageData" and "putImageData" to obtain and render a pixel buffer. Unfortunately these methods are only available in Firefox. I'm still looking for an alternative for Opera and Safari. The last missing part was the conversion from HSV to RGB but luckily I could drop in a modified version of qooxdoo's hsbToRgb method.

Now the port could start. What really intrigued me was that the main algorithm was nearly the same as the C++ code. Just take this code fragment from the original code:

for (int i = 0; i < radius; i++) {
  qreal hue = 1 - init;
  qreal sat = 1 - qreal(i) / radius;
  for (int d = 0; d < depth; d++) {
    qreal value = 1 - qreal(d) / depth;
    QColor color = QColor::fromHsvF(hue, sat, value);
    img-&gt;setPixel(width / 2 - radius + i + 1, center + d, color.rgb());
  }
}

and compare it to the ported JavaScript:

for (var i = 0; i < radius; i++) {
  var hue = 1 - init;
  var sat = 1 - i / radius;
  for (var d = 0; d < depth; d++) {
    var value = 1 - d / depth;
    var color = hsbToRgb(hue, sat, value);
    setPixel(img, width / 2 - radius + i + 1, center + d, color);
  }
}

Basically only the variable declaration is different. The same is true for almost all of the relevant code. My first version was an all in one HTML file with the JavaScript code embedded. I used no framework, just plain JavaScript.

Of course I wanted to use some qooxdoo, so the next iteration was to put this into a qooxdoo application. Up to now qooxdoo had no support for embedding canvas elements into a qooxdoo widget. I used much of the new 0.8 widget infrastructure to create a canvas embedding widget. With this widget I could take the code from my first version and embed it into a qooxdoo window. You can see this application life or download the sources. This code is based on the latest qooxdoo 0.8 trunk.

Have fun!

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.

Ok, so this is a rather personal rant about my frustration with current Firefox. Firefox is my bread-and-butter tool every day. I don't know how you feel, but my impression is that Firefox falls behind in a central issue for browsers, speed and responsiveness. As a real-time, GUI-based, highly user-interactive, networked tool, a browser has to be top notch in handling concurrency. This is not exceptionally good in Firefox 2, and I can only hope it will improve significantly in the upcoming Firefox 3, with a new rendering engine and - more importantly - a threadmanager (see here). It seems the new theme gets all the attention but I don't care about themes when the reponsiveness is poor. Maybe Webkit is the new hot shot, and I would be interested if they'd released it on Linux.

The issue is, I have easily three browser windows open at any one time, with a total of 20 to 30 open tabs in them. I switch between windows and tabs, starting page loads in one and continue reading in another. And I regularly are blocked by the browser itself. I accept network latency, but why is one window not repainted while the other is loading? Why can't I switch tabs when a script starts in the other? Or why can't I open my preferences window while the browser is loading? Why is Firefox always getting in my way?

My concerns with current Firefox are:

• Page loading. It's not understandable the browser is not able to load pages in the background. Or more practical, why can't I switch to another tab reading what's already there while the browser is loading and rendering a new page in the tab I'm about to leave?!

• Multi-threaded Javascript host engine. I don't see why you couldn't have a multi-threaded Spidermonkey whith a thread for every web page that uses Javascript. This way you could isolate the pages against each other, while handling concurrency so that every page has optimal responsiveness.

• Power to the chrome, which means power to the user. In a multi-tasking browser, the UI has to have top priority. User interaction is always more important than everything else. If I open a menu or invoke a dialog or operate some other control of the chrome, the browser has to respond immediately no matter what it is doing at that time. Loading, rendering, cache management, execution of scripts - you name it, they have to wait.

So, it boils down for me to this: I want a multi-tasking browser with decent (pre-emptive) task scheduling and priorities. Just like a decent operating system. But task management is not only for OS's, the technology is since long available for every application to implement.

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

I have just found some more interesting stuff regarding our Tamarin post today: 

• Inside Tamarin - Adobe’s Open Source Flash VM
• JD on EP
• Adobe press release
• Mozilla press release
• Digg frontpage

Good news, everyone! 

Recently we have been puzzled by some statements of Brendan Eich, the creator of the JavaScript programming language.

In Brendan's blog he wrote "For Mozilla 2, we will have a JIT-oriented JavaScript VM (details soon) that supports the forthcoming ECMAScript Edition 4 ("JS2") language" (October 13, 2006). Well, could hardly wait for any details. Another statement that made us curious was at The Ajax Experience this fall. In his slides about JavaScript 2.0 he mentioned  "Open source optimizing VMs coming soon. Look for an announcement in a few weeks" (October 25, 2006). Interestingly, this mysterious announcement was in a section he called "JavaScript Fun Facts".

Well done Brendan, you are our Master of Suspense! Finally, as a revelation today came the announcement that is going to boost JavaScript. Congratulations to Adobe for their decision of contributing the ActionScript Virtual Machine (AVM) as open source to the Mozilla project. And a warm open-source welcome to all the developers of the AVM! The code has just been committed into the Mozilla repository.

This is great news for qooxdoo being a client-side JavaScript framework. Performance has always been one of our major concerns, and we think we have pushed the limit for JavaScript based web applications, e.g. for qooxdoo's powerful browser-independent layout engine. Can't wait to tweak the last bit of performance out of any new Mozilla browser backed by the new JavaScript VM. This is going to change the future of browser-based applications. Cheers!

In my opinion there was never a reason why JavaScript should be slower than other typical script languages e.g. Python, Perl, Ruby, ... With the newest committment from Abobe to Mozilla we could reach a new level of performance in web applications. 

As news.com reports "Adobe will provide the same software, called the ActionScript Virtual Machine, which it uses to run script code in the Adobe Flash Player 9. This virtual machine is expected to be built into future versions of the Firefox browser by the first half of 2008, said Frank Hecker, the executive director of the Mozilla Foundation."

Via news.com

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)