Media types

In CSS, you can mark a block as applying only to certain types of media.  You can also import a stylesheet on the condition that you’re rendering to a particular kind of media.  CSS2 defines the available media types as braille, embossed, handheld, print, projection, screen, speech, tty, and tv.  HTML4 also defines aural, which is roughly equivalent to speech in CSS2.

Every CSS renderer, including Cowbell, must render to some media type.  We could render to screen, by which is generally meant “styling web pages on a desktop monitor”.  But window borders are rather different from web pages.  If we do render to screen, would it be useful to allow the distinction between screen and handheld (so if you’re viewing the window borders on an N900, the stylesheet can adapt?)  If we don’t, what should we render to?  There doesn’t seem to be provision or precedent for making up new media types such as window-borders.

If we do make up a new type, perhaps we should make up some media queries to go with it.  Would it be useful to write rules which depended on the width or DPI of the monitor?  To some extent, you can already depend on the DPI by using linear units such as mm instead of px, so on higher-resolution screens the borders don’t shrink away to nothing.  I’m not sure the ability to colour them differently, and so on, is very useful.

You might think that this is only of theoretical interest, since nobody would use a Cowbell stylesheet to style anything other than window borders.  But consider the use of SVG as background images; SVG may be styled by CSS, and it might make sense to refer back to the main stylesheet to do so.  Such styling would possibly have a different media type from the rendering of the window borders themselves.


  • Do we render to screen?
  • If so, do we make a distinction for handheld?
  • If not, what media type do we render to?
  • Is it worth supporting media queries?

Implementa… say it! …tion

I am dithering between three possible ways of implementing all this, and I have bits of written code for all of them.

Option A is to do the whole job of tokenising and parsing and rendering ourselves.

  • We get full control and can do what we like.
  • There isn’t much of the full CSS spec we need to honour just to do window borders.
  • But we also run the risk of obscure bugs specific to our code…
  • …and we’ll have the inevitable need to prove why we didn’t rely on existing libraries.
  • I have a working tokeniser written and some of the parser; I just need to decide whether to use them.

Option B is to do the rendering and perhaps some of the parsing ourselves, and leave the rest of the parsing and all the tokenising to libcroco.

  • But libcroco doesn’t do CSS3.
  • But there are workarounds for that; still, none of them are perfect and they’ll show up very obviously in the language.
  • Of course we could start by modifying libcroco to do CSS3, but that might make this project last forever.

Option C is to use libccss to do almost everything, which depends on libcroco for parsing.

  • This is what the first draft of Cowbell did.
  • This has all the negative points of Option B, and some of its own.
  • However, there were some infelicities, including rather inflexible image handling…
  • …and no way to expand the range of colours that were allowed.
  • We also had to do some things, like rendering the title text, ourselves anyway.
  • Again, we could just fix libccss; again, this will delay this project’s going anywhere in a hurry.


Another thing missing from CSS which is present in Metacity v2 themes is the ability to draw gradients.  In Metacity v2, a gradient can be

  • any one of vertical, horizontal or diagonal
  • between two or more colours, which can be specified as any colour format Metacity supports

How should we best represent this in Cowbell themes?

Option A:

frame {
background-image: -cowbell-gradient (diagonal, green, blue);

Option B:

frame {
background-image: url(“wm:gradient,diagonal,green,blue”);

Option C:

frame {
background-image: -cowbell-gradient();
-cowbell-gradient-direction: diagonal;
-cowbell-gradient-color: green blue;

Option D:

frame {
background-color: -cowbell-gradient(diagonal, blue, green);

Or some combination of these.  Or perhaps you can think of a better way.

Recolouring bitmaps

Occasionally we’ll be publishing polls on how best to represent ideas within CSS syntax.  What we need here is something that’s

  • easy to understand
  • as much as possible, in the spirit of standard webpage CSS
  • what someone who knows basic CSS would expect

Here’s our first question.  In standard Metacity themes, you can include pixmaps.  These pixmaps can then be recoloured: in other words, they are set to greyscale, and then the hue is modified to match the requested colour.  This means that a pixmap theme can match the system colour scheme.  Crux works like this.

How should we best express this in CSS?  Here are two options, but feel free to present your own ideas.  Our choice may be constrained by what libcroco is capable of, but we can also work around that in various ways.

Option A:

button.close {
background-image: -cowbell-recolor(url(“close.png”), green);

Option B:

button.close {
background-image: url(“close.png”);
-cowbell-background-recolor: green;

What do you think?


Col de la BretayeCowbell is a system to allow styling of window borders using CSS, the same system that is used to style webpages.  It will initially be used for Metacity.


The name originally stood for “CSS on window borders experimental layout language”. Since then it has become a little less experimental.

In the first phase, a basic version was built and demonstrated.  This work was supported by Collabora Ltd.  You can still read the documentation for building themes, though the system has changed slightly.  There followed some discussion on the best way to continue.  Here’s an example of the first phase in use, which was created by rendering this stylesheet:

In the second phase:

  • there will be a library, libcowbell, to turn CSS into window borders;
  • there will be a program to edit CSS files and render them on the fly.

Work on the library continues.  Both programs should be ready by GUADEC 2010.  They will probably eventually live on, but for now you can follow them on gitorious.

This blog will follow the development and discuss any choices we have to make as we’re making them.  Next we will need a roadmap.

Photo © spigoo, cc-by.