After some investigation and a major release jump (0.1.4 → 0.5) we have switched from a purely CSS-based styling to basically a non-CSS-based styling. While this may be surprising, we think it is better not to use CSS for styling graphical user interfaces that more closely resemble native applications. Sure, it is all about styling, but the use of CSS and its external stylesheets simply is not appropriate. Cascading Style Sheets’ intention is to style web pages, not advanced GUIs. Not even CSS3 addresses all the aspects of user interfaces that developers want to take advantage of. Qooxdoo does internally apply CSS styles directly to the DOM nodes to accomplish the task of rendering visuals. It does not, however, require CSS instructions from the programmer.

The qooxdoo appearance model is intended to be the perfect match for advanced web applications. It can handle many more interface related details than CSS can. Qooxdoo is supposed to be easier to learn, easier to use, more powerful and - in the end - faster than traditional CSS.

There are toolkits, like Dojo and many others, which are based on traditional web pages that try to augment HTML. As they rely on HTML for their interface description, it is somewhat natural for them to rely on CSS for all aspects of styling (or even layouting) as well. This may have some advantages, but it also has many disadvantages:

• You need to handle cross-browser quirks. The more advanced your layout and styling, the more nasty your CSS hacks. That means that the typical web application developer not only needs to know a lot of HTML, but also needs to be a CSS guru to get advanced interfaces implemented, cross-browser.

• You are limited to the functionality of CSS. Well, not just to a particular CSS standard. In fact, you are limited to the common subset of CSS standards that your set of target browsers implement in a non-buggy way. This usually means:
  • no cross-browser support (min-width, max-width, ...)
  • no appealing 3D-borders
  • no themed colors
  • no custom or resource specific paths (image resources, icons, ...)

Another reason not to use pure CSS is due to complex layouts based on powerful layout managers - which are not available in CSS. If the layout engine depends on CSS the only way to obtain the value of a property is to ask the browser for the computed value. For example, the dimensions of a widget including its width and height, padding, border and margins. The browser’s rendering engine becomes the only source for this information.

The problem with relying on the browser like this is that you cannot retrieve any computed values of an element before it has actually been placed inside the final document structure. This also means that the element must be visible before it is rendered. If your children’s layout depends on the parent’s layout, the children must wait before completing their own layout processes until all the parents have been processed and are ready. This leads to multiple view updates which is often slow and can result in temporary visual artifacts or flickering. In total it is surprisingly slower than doing similar calculations in JavaScript yourself, despite the fact that the rendering engine is compiled, optimized code. Overall, the more complex your web GUI is, the more important it is to have a complete rendering engine that you have full control over.

The focus of qooxdoo is primarily to help programmers create complex and advanced GUIs and not the supplementation of traditional web pages. Qooxdoo is more than just adding just a few fancy widgets to a page. The concepts of appearance or theming are superior in terms of features and performance compared to solutions based on CSS.

Any web developer can produce astonishing results without being a CSS or HTML expert. Cross-browser. Now.