Apologia for CSS

2000 two penceThis blog is not about to become devoted to the single topic of experimental CSS theming, but some interesting points were raised in the discussion yesterday, which spilled over to Slashdot.  We should have emphasised the experimental nature of the CSS subsystem in its name: perhaps “CSS On Window Borders Experimental Layout Language”.

Why? Some people have asked why anyone should be interested in CSS theming, given the existence of a stable and mature theme description format.  The answer is that there are perhaps a couple of hundred people in the world who understand the Metacity theme format, and its complexity presents a significant barrier to entry for anyone else attempting to learn it.  By contrast, millions upon millions of people have a basic understanding of CSS.

Efficiency. Some have pointed out that using CSS may cause great increase in memory footprint or execution time. Both of these are of primary importance to us. Furthermore, we know just how fast every theme renders using the standard engine. We are not prepared to introduce a new theme engine unless it is at least as efficient as the old one.

Mismatch. Some complain that the lists we gave of things we would need to ignore and things which would need to be added proved that there was a mismatch between CSS and what was needed.  This is based on a misunderstanding of CSS as a language to style HTML.  In fact CSS is a general-purpose styling language, and there are only a few places where it does not quite meet our needs.  Even in those places the design is flexible enough to accommodate us.

The balance of power. Ray asked whether the structure of the window should be under theme control, as well as the styling. Some ask how we decide what is under the control of the CSS.  We always need to find a balance between giving power to themes and giving power to users. Some things should be under theme control and some under user control, but it’s not trivial to decide which. Here are some examples:

  • Justification of the text on the titlebar. Currently this is entirely under theme control; the user can’t change it. Some people would like this to change.
  • The arrangement of buttons on the titlebar: which are on the left, which are on the right, and which aren’t shown at all. This is currently entirely under user control; the theme can’t change it. (This means that themes which attempt to look like OS X have to ask you to reorder your buttons so that close is on the left, since they can’t do it themselves.)
  • The font on the titlebar. Currently this is entirely under user control; the theme can’t change it. This among other things is something we’d need to reexamine with a CSS theming engine.

(“Under user control” means set in GConf and, generally, modifiable in the control panel.  Some of these options cannot be set in the control panel at present, but that’s a separate problem.)

It may be true that windows should have a more flexible structure, and the ability to have the titlebar elsewhere is certainly something that’s been asked for from time to time. But assuming we should add such abilities, should the decision to use them be made by the theme, or should it be something selectable by the user in the control panel? These are deep questions.

Co-operation with GTK CSS theming. Yes: a good idea.  Whatever they’re doing, we should probably try to share in it.

Complexity. Some have said that CSS is a complex system, and that anything implementing it will therefore also be complex and difficult to implement.  This is an unwarranted assumption.  Take a look at the table of contents of the CSS specification and see how little of it actually applies to a fully-functional system for description of window borders:

  • Syntax and basic data types; Selectors; Assigning property values, Cascading, and Inheritance; Media types:  all handled for us already by libcroco.
  • Box model: we would need to implement this.  Not terribly complex because we have a simple and unchangeable layout model.
  • Visual formatting model; Visual effects: these are complex, and we can ignore them entirely, since our layout needs are simple and unchangeable.
  • Generated content, automatic numbering, and lists: we would need to implement basic generated content (the easy part); we have no content to be numbered, and no lists.
  • Paged media: does not apply to us.
  • Colors and Backgrounds: the most complex part which we would need to implement.
  • Fonts; Text: partially applies to us (since some of it isn’t theme-controlled); mostly involves passing things into Pango.
  • Tables: doesn’t apply to us; we have no tables.
  • User interface: this is about setting cursors and things, and doesn’t apply to us.

Finally, we should probably reiterate that:

  • this is still an experiment, and not an official direction which Metacity is taking;
  • even if it ever happens, there’s certainly no decision to use WebKit.

Photo © johninbkk, cc-by.

4 Comments

  1. Lubomir
    Posted July 20, 2009 at 7:35 pm | Permalink

    Please, be careful about allowing theme designers to set the font of the titlebar. I am pretty sure some of them will use fonts that do not contain non ascii letters and this will make some themes unusable for certain users. For example right now 3 of my 10 currently opened windows have Czech characters in title.

  2. Posted July 20, 2009 at 7:52 pm | Permalink

    @Lubomir:

    Certainly there are many good reasons not to let themes dictate the font. Thank you for a good example of one!

    I’m not sure whether there’s a middle ground. Perhaps it would be safe to let them suggest a font and have the default being to override it. Perhaps it would be safe to let them choose serif/sans-serif etc but not the actual font name.

  3. Anonymous
    Posted July 21, 2009 at 2:27 pm | Permalink

    Why not take advantage of the C in CSS: allow users to override theme settings by way of a user stylesheet which overrides the theme stylesheet?

  4. Arc
    Posted July 27, 2009 at 5:29 pm | Permalink

    That Anon speaks wisely. Also, add a dialog akin to what’s available in Firefox (and most other browsers?).
    ” Preferences >> Content >> Fonts & Colors >> Advanced >> Allow pages (themes!) to choose their own fonts, instead of my selections above. ”

    Or you could make theming modular if you want to get advanced. Instead of having one ‘do it all theme’, allow users to have a list of CSS files/packages as an ‘advanced’ setting. Of course you would have to add some form of warning dialog about the possibility of problems.