For qooxdoo 0.8 we have introduced a layered architecture from low-level DOM to high-level widget system. For instance, we extracted all lower-level implementation details out of the widget system and moved them into a new layer (that could also be used independently). Interestingly, this was already mentioned about a year ago and I thought it would be a good idea to refresh the information from the last report.

The layers of qooxdoo in 0.8:

• qx.dom contains generic DOM methods. This includes basic stuff like information about the different node types, positioned inserts of nodes, a huge range of traversal functions.
• qx.xml contains specific features to work with XML documents. Features include selectNode, createDocument and string escape routines specific to XML.
• qx.bom contains all stuff which is specific to the so-called "browser object model". Included are features to control specific attributes of HTML elements e.g. utilities to work with styles, class names, etc. It also connects elements to the event system. There are many more things: Computing locations of arbitrary elements in relation to the document, scrolling any visible element into the viewport, inserting Flash movies, working with the browser history and creating pseudo bookmarkable pages, dealing with XMLHttp requests in a unified fashion, detecting the client and a number of the most common plugins, creating enhanced shrinkable labels with ellipsis symbol etc. All these features work in all four supported browsers equally well.
• qx.html is the new high-level DOM manipulation API. It is mainly thought for the managed creation of HTML nodes. It wraps most of the features of qx.bom and offers them in the well-known qooxdoo OO style programming fashion. With this API you work with an instance for every DOM node you like to create. This may seem very expensive at first glance, and in fact it isn't without cost, but in practice it performs quite well. And best of all: it automatically gets a lot of stuff right which otherwise had to be done over and over again in an application or the widget system itself. Yes, the widget system uses this API to work with the DOM. The major feature of this API is the managed creation and insertion of DOM nodes. It works perfectly for multi-pane views (e.g. Tab Views) and makes generation of whole areas as lazy as possible without any additional work required. Compared to qx.bom these features do make most sense when creating a huge chunk of HTML. For simple modification of existing nodes or creation of a handful of nodes qx.bom is the better choice.
• qx.ui contains the GUI toolkit of qooxdoo 0.8. Here you can find all things comparable to other (native) toolkits. This means for instance: real layout managers, improved event and focus handling, decorators for all types of styles, full-blown theming capabilities without the need to use HTML or CSS.

Hope this is a useful overview. Feed free to ask questions, your feedback is appreciated. This blog post will become part of the forthcoming documentation of 0.8.

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.

Last Monday I did a presentation about the new layout managers we already started to implement for qooxdoo 0.8. The presentation is meant as an overview of what we propose to do, are actually doing already and why we do it. I think the slides give a good overview even if my spoken comments are missing. If you have any questions or comments feel free to post them as comments to this blog entry, and -- even better -- also to our mailing list to have a better basis for discussion.

Download: qooxdoo 0.8 Layout Concepts slides