![Call... (4 of 4) [2007 - Day 174 - Edge]](http://farm2.static.flickr.com/1135/600869019_9aadfd512b.jpg)
The recent discussion about CSS themes looks as though it may become one of the most interesting new ideas in theming in recent years. Here are some further thoughts on what may evolve from this.
An alternative. There is no general way, and few special ways, to convert expression-based v1 and v2 themes to the hypothetical box-based CSS themes. Therefore this would need to be an alternative theming system, without any upgrade path leading to it.
Document structure. CSS exists to style documents. In our case the document is purely notional rather than existing somewhere as a file, so we have great leeway in its representation. As I mentioned earlier, there are multiple ways in which we can use the ideas of element name, ID, and class to represent what we want to do. The guiding principle is not what would be easiest to implement but what would cause least astonishment to new theme authors. After some thought, I think such a layout might look like this:
<frame class=”maximized”>
<area class=”titlebar”>
<button class=”menu”/> <!– possibly others –>
<title/>
<button class=”minimize”/>
<button class=”maximize”/>
<button class=”close”/> <!– possibly others –>
</area>
<area class=”content“/>
</frame>
- Feel free to disagree and to come up with alternatives.
- There are no attributes on any element. Attempts to select on attributes will fail. The class is written as an attribute only for notational convenience: hence the italics.
- Class is used instead of identifier because it’s not impossible that some implementation of this scheme will wish to have multiple buttons with the same function on a frame.
CSS3. Almost everything we already have can be represented in CSS level 2, and there is no immediate need for level 3. The sticking point mentioned earlier was the window icon being part of the title in Atlanta. However, this can be implemented in CSS2 as follows:
title:before {
content: url("metacity:icon");
}
where metacity:icon is a magic URL which returns the current application icon. (But it might be wise not to use the name “Metacity” in this format, in case other window managers might like to use it; that goes for vendor-specific extensions, too. Maybe we should use -wm-.) That said, I am salivating over the possibilities of the new round attribute to background-repeat.
However, there is one piece of level 3 we absolutely need: we will need to allow border-radius at least on the frame, if not on the subsidiary elements.
Implementation. A format is independent of implementations, of course, but we need at least one implementation in order to test things. There have been a few possible implementations suggested:
- webkit. This would work and reuse a lot of code, but I’m a little wary of embedding a web browser into the window manager.
- nbtk. This seems to be missing a lot of what we need at present.
- libccss. This has more of what we need, but still there’s a lot left open to us to implement, and a lot of what it implements we don’t need. It also doesn’t allow us to define new colours, which we need, and appears not to implement sibling selectors, which we will probably also need.
- Using libcroco for parsing and cascading and building the rest ourselves. This is slightly more work than using nbtk or libccss, but may be necessary because of the particularly specialised nature of what we are doing here.
Justification. One of the things people seem very keen on is how the window title is justified. In the box model, the correct way to do this is with the auto keyword on the padding or margins of the title, and not using a text-justify declaration (since the title only has one line of text which fits snugly in its own content box). However, since people are bound to try to use text-justify anyway, perhaps we should allow them to do so, and merely interpret it as another way of setting the padding.
Things we need to implement: The whole box model; several kinds of border pattern; basic generated content for the title; various kinds of text styling for the title; ability to use pseudoclasses to prelight and press buttons.
Things we should ignore: Padding on the frame. Height and width set on the frame, or the content box. Perhaps: Any theme without proper metadata. If we’re doing things the same way as in v2, the font-family, font-weight, and font-style set for the title. (Or should we allow themes to specify a font?) Should we give a warning if a theme attempts to use anything we don’t support?
Photo © Jonathan W, cc-by-nc-nd.
syndicate
