CSS in the Hippo Canvas

This page was originally posted here.


We added some simple theming support to the Online Desktop sidebar a while ago. The way it worked is that there was a global ThemeManager object with a get_current_theme() method, and a set of "themed" subclasses of the different Canvas objects that got colors from the theme object (so, ThemedText, ThemedLink, etc.)

There were a couple of problems with this: one is that having these subclasses was ugly and inconvenient. A second problem was that we didn't actually want consistent theming in all places: the online desktop sidebar is themed, but the same UI elements could appear in a "browser" window that was meant to match the system appearance.

So, the same PersonItem would need ThemedLink objects in one context, but in another context, would need plain old hippo.CanvasLink objects. Trying to make this work meant threading a 'themed' boolean through all our construction code and lots of conditionalization.

This idea of having the same objects appear differently in different contexts is something we've hit before. A particularly bad example was the appearance of "hushed" blocks in the Mugshot stacker. When you "hushed" a block, all the links in the block are supposed to appear hushed. Implementing this required:

  • Propagating the 'hushed' status down to all the descendant elements within the block (so things like the quip preview have this as a property.)
  • Adding code in each of them to adjust the appearance of the links when the hushed status changed.

Now, of course, controlling appearance in a way that depends on context is exactly what you do with CSS for a web page. Rather than adding something that was "like CSS" but different, I thought I'd try to literally use CSS stylesheets using libcroco to do the parsing.

I have this working pretty well now and have ported both the online desktop sidebar (in Python) and the Mugshot client (in C) to work with the CSS-ified canvas.

Basic API

The basic API for this is pretty simple:

/* Any parameter can be NULL */
HippoCanvasTheme *hippo_canvas_theme_new (HippoCanvasThemeEngine *theme_engine,
                                          const char             *application_stylesheet,
                                          const char             *theme_stylesheet,
                                          const char             *default_stylesheet);

void hippo_canvas_set_theme (HippoCanvas      *canvas,
                             HippoCanvasTheme *theme);

void hippo_canvas_window_set_theme(HippoCanvasWindow *canvas_window,
                                   HippoCanvasTheme  *theme);

So, you can set a stylesheet for a canvas, and you can have a cascade of stylesheets:

  • application_stylesheet: styling for the application ... highest priority
  • theme_stylesheet: styling for the "theme" ... middle priority
  • default_stylesheet: "default" stylesheet ... lowest priority

To specify how selectors work on the items HippoCanvasBox also gains a couple of extra properties:

  • "id": the ID for CSS matching
  • "classes": the class (or space separated classes) for CSS matching

"classes" is not "class", because that would cause a problem in Python where 'class' is a keyword - you couldn't do:

 text_item = hippo.CanvasText(class='highlighted', text="foo")


Much of the CSS 2.1 selectors specification works. You can match on element name - the way this works is that you can match on *any* objects type in the HippoCanvasItem's type hierarchy, so a HippoCanvasUrlLink will match

 * HippoCanvasText  * HippoCanvasBox

To match on a Python type, you replace the .'s in the module name with -'s, so bigboard.big_widgets.Separator matches:


You can match on element ID and class.

The :link and :visited pseudo-classes are supported (out of the box for HippoCanvasLink subclasses)

You can use the '>' combinator

Some things aren't:

  • Adjacent sibling selectors ('+') are not supported
  • Attribute selectors ('[att=val]', etc) aren't supported
  • :first-line, :first-element, :before, :after are not supported


Some of the CSS properties that are supported by the standard items in my current patch:

  • border[-width,-color][-left,right,...]
  • padding[-left,right,...]
  • color
  • background-color
  • text-decoration
  • font[-style,-family,-weight,-variant,-size]

I've attempted to follow the actual CSS specified behaviors pretty closely, though there are deviations both from what's possible without major changes to the canvas, and what I just didn't bother to get 101% right. (As an example, a compliant CSS parser should reject and ignore 'border: 1px solid solid black', but I treat it the same as 'border: 1px solid black'.)

I'm not going to list all the CSS properties that aren't supported - that would be a looong list. Speaking generally, layout properties like display, float, left/right/top/bottom don't make sense to me. The HippoCanvas deviates substantially from the CSS box model and this (and the ability to write custom layout managers) are one of the big reasons you'd use it instead of a HTML widget.

Another thing that generally isn't supported is percentage values for lengths - you can do 'border: 2px' or 'border: 2em', but you can't do 'border: 25%'. (Percentage values for lengths that affect layout are inherently circular and anybody who has done significant work with CSS on the web will have had lots of fun with their oddities and traps.)

"Theme engines"

You'll note the "theme_engine" parameter above; the idea of a theme engine is that it is an object that knows how to draw named objects. The HippoCanvasThemeEngine has a single parameter:

 gboolean (* paint) (HippoCanvasThemeEngine *engine,
                     HippoCanvasStyle       *style,
                     cairo_t                *cr,
                     const char             *name,
                     double                  x,
                     double                  y,
                     double                  width,
                     double                  height);

This is manifestly *not* enough to do a full widget theme (with things like notebook tabs), but it handles the simple stuff that we do for the Online Desktop sidebar.

Implementation Notes

The way I did things was rather than to have CSS matching be done directly on the tree of HippoCanvasBox, was to create a parallel tree of HippoCanvasStyle objects.

This has several advantages:

  • It doesn't tie things directly to HippoCanvasBox which is, after all, supposed to be only one implementation of HippoCanvasItem.

  • It avoids making hippo-canvas-box.c yet longer and more complicated.
  • We don't have to worry about style mutation - if the element ID or class of an object changes, we just drop the style object and recreate a new one on demand.

My initial plan was to make HippoCanvasStyle general - to have API like:

gboolean hippo_canvas_style_get_length (HippoCanvasStyle *style,
                                        const char       *property_name,
                                        gboolean          inherit,
                                        gdouble          *length);

But the desire to actually match normal CSS made this work out not so well. In this framework, how do you handle the interaction of:

 border: [ <border-width> || <border-style> || <'border-top-color'> ] | inherit
 border-left: [ <border-width> || <border-style> || <'border-top-color'> ] | inherit

You need to know what order they appear in the style rules. So, I ended up adding more specific API like:

 double hippo_canvas_style_get_border_width (HippoCanvasStyle *style,
                                             HippoCanvasSide   side);

Being specific also makes it easier to cache property values instead of computing them over and over again. (For this reason, some things that are currently handled generically like the 'color' property for foreground text color probably should be switched to being hard-coded.)


My concerns about this change (especially in the context of usage of HippoCanvas in OLPC/Sugar) are two-fold: compability, and performance issues. (And among performance I include memory usage.)

I've tried fairly hard to preserve compatibility with this change - I've left almost all the individual item object properties the same. But there are a couple of incompatible changes:

  • The color-cascade property is gone. What this property was about was whether colors where inherited (not "cascaded") from parent items is gone.
  • Font and color set by object properties are now never inherited by child widgets. (Previously, fonts were always inherited, colors inherited depending on the color-cascade property.)
  • The ability to set the default color for an item type by modifying a class property, and the ability to modify the background color for an item by setting the background_rgba field directly are gone. Neither of these was bound into Python so there is likely no effect on the Sugar usage of the canvas.

It didn't take me very long to fix up the Mugshot stacker to deal with these changes, but the lack of inherited color does mean that you'll have to add a stylesheet in some cases where one wasn't used before.

(Digression: why did I decide to make font and colors set through GObject properties not inherited? I had to decide one way or the other since 'color-cascade' was (IMO) a bad idea, and non-inherited was simpler. Keeping object property styles as a layer on top of the CSS styles also allowed doing something like adding a custom style property -hippo-mouseover-color: and use that modify the color object property.)

There is obvious CPU overhead both to match CSS styles and memory overhead to keep the HippoCanvasStyle objects around. The CPU overhead should be basically zero if you don't have any stylesheets or style rules, but the memory overhead doesn't .. right now it is ~150 bytes per canvas item.

The bulk of this is:

  • A copy of the font description
  • The border-width/-color/padding properties for each side of the item

150 bytes per item isn't horrible - even for a 1000 item canvas, that's only 150k, but it certainly is noticeable. Possible improvements:

  • Storing border/padding as a double is really wasteful. guint8 is probably fine. (You don't want non-integral margin/padding since it will give you blurred lines and blurred child elements)

The style of an object is determined by:

  • The matched rules
  • The parent style

We could conceivably hash those and have only one copy of the HippoCanvasStyle object for each combination. When you have a canvas with a lot of objects, you'll probably have a high hit rate for this. This would also save CPU since while the rule matching would have to done for each element, converting from a list of matched rules to a set of properties only needs to be done once.

TODO / Refinements

Much of HippoCanvasStyle is not bound into Python. Partly this is because I'm less certain of the HippoCanvasStyle API, partly because I didn't need things like hippo_canvas_style_get_border(style, side) in the Python code of the online desktop sidebar.

As mentioned above, I want to move color and background-color to be hard-coded in the HippoCanvasStyle API instead of going through a generic get_color().

Some of the generic API of HippoCanvasStyle (get_length()/get_side()/get_enum()) probably should be eliminated.

It would be handy to allow setting a CSS fragment as an object property similar to the HTML CSS attribute so you could do

    hippo.CanvasText(style="text-decoration: line-through;")

I'm not sure if libcroco exports a suitable API to allow parsing a fragment like this.

The 'id' and 'classes' properties perhaps should be moved to HippoCanvasItem instead of HippoCanvasBox ... in the theory that a non-HippoCanvasBox should still support this properties.

Having hippo_canvas_box_add_class()/remove_class() convenience functions would be useful.

I'd like to support RGBA colors through the style file, but the CSS3 syntax of rgba(...) is not supported by libcroco, so this would require a cut-and-paste of libcroco or getting a patch upstream.

(cut-and-pasting libcroco has some appeal, in that it allows getting rid of the useless libxml dependency, but is clearly community-unfriendly.)

The way that you support :link and :visited is really ugly: you override hippo_canvas_context_get_style() and do something like:

static HippoCanvasStyle *
hippo_canvas_link_get_style(HippoCanvasContext *context)
    HippoCanvasBox *box = HIPPO_CANVAS_BOX(context);
    HippoCanvasLink *link = HIPPO_CANVAS_LINK(context);

    if (box->style == NULL) {
                                         link->visited ?
                                              HIPPO_CANVAS_LINK_VISITED :

    return box->style;


Probably should just add a "protected" hippo_canvas_box_set_link_type(). This does mean that if more things like hippo_canvas_style_set_link_type() they would also need to be added to HippoCanvasBox, but I don't see a need to keep on extending that set.

The patch

So I don't get accused of vaporware:


A little more raw:


Appendix: So why not just use an HTML widget?

Once you start adding CSS to HippoCanvas, the obvious question becomes "OK, why aren't you just using WebKit or GtkMozEmbed or something. There are a couple of reasons I see hippo.Canvas as still better for certain purposes:

Subclassing: When writing the Mugshot stacker and the Online desktop sidebar it has worked out really really well to be able to subclass standard HippoCanvas items and bind them to data, whether it's an item for a headshot of Mugshot person or group, or a timestamp item that automatically updates from "1 minute ago" to "1 hour ago".

This is not something you get out-of-the box with an HTML widget: a HTML DOM tree is strictly generic. There are of course Javascript widget systems, and there is XUL, but (with certain complex exceptions like GWT) Javascript widget systems are generally speaking hack-jobs, and XUL is *not* a HTML widget. It's a different toolkit.

Subclassing in HippoCanvas + python is just a really nice way to create items with custom appearance and behavior with minimal code.

In your language: While it's conceivably possible to use other languages than Javascript within a HTML widget, the web ecosystem is a Javascript ecosystem and doing something else is asking for pain.

(And by use, I don't just mean a bit of manipulation of the DOM tree, I mean establishing event handlers, and so forth.)

And integrating canvas items in Javascript into a program written in another language means that you have a language barrier to fight that you have to cross with XPCOM or whatever.

Better layout: The CSS layout model is flexible and powerful, but it is really designed for incremental layout of text, not squeezing the most information into a small space. HippoCanvas has box layout, it has ellipsization.

Ability to write custom layout managers: doing something like a icon list that wraps to a given width in Javascript is horrible and almost always a bad idea... after all, you are fighting another layout system built into the HTML engine. With HippoCanvas you can participate in the layout system as a real peer.

Rich GTK+ integration: you can embed HTML widgets into GTK+ several ways, but I don't know any provisions for embedding GTK+ widgets into HTML.

(Of course, in other cases using a HTML widget *is* the right way to go.)

Attic/HippoCanvas/CSS (last edited 2024-04-11 15:42:01 by EmmanueleBassi)