1. Standard format: I think this is going to be the most difficult to achieve overall, although picking standard formats for various components should be fairly simple (ZIP for archiving, PNG for static images, etc.)

2. Editable: This goal is a black mark against any generic cascading system such as CSS uses; creating a user interface that *depicts* the cascade is fiendishly difficult, I’ve never seen a CSS editor as comprehensive and comprehensible as a plain text-editor.

5. Single file: Unpacked trees should also be supported, for ease of development.

7. Named colours: I notice Ubuntu’s GTK+ theme configurator has buttons that allow you to configure the colours of various things; it seems to work by setting a “gtk-color-scheme” key in the theme file. If it were possible to hook into that, that would be pretty neat.

And here’s some more goals you might want to add to the list:

Resolution independence: v2 themes resize themselves to account for the size of the window title font, but extreme sizes in any non-trivial theme can look pretty silly. CSS is a good example, where every measurement is in terms of some particular unit which is defined relative to some external factor (such as the screen’s DPI, the size of the current font or the size of the window)

Extensibility: No matter what goes into a v3 theming spec, people will ask for more and different things in the future. If the v3 format clearly defines how to ignore unrecognised syntax, it may be possible to avoid having to bump the theme version for a long while. Again, the CSS design principle of “forward compatible parsing” is a useful model to follow, whether or not themes actually use CSS syntax:

http://www.w3.org/TR/CSS1/#forward-compatible-parsing

Declarative syntax: This is sort of implicitly covered by “2. Editing” and “11. Maximum power”, but I think it’s worth breaking out on its own. Theme syntax, where possible, should be expressed as declarative rules rather than as imperative algorithms. This should make editors at least possible, and makes it more difficult for theme-authors to do crazy things (although no doubt they’ll find a way).

Broken features are new features: There’s a number of v2 theme features that have never really worked correctly, and hence nobody really uses them (Thought: it would be useful to download a bunch of Metacity themes from gnome-look.org and do some bulk analysis of how frequently various features are used). Many of those broken features are actually pretty good ideas, though, so they should be dumped into the enhancement-request hopper along with all the other v3 theme features.

Second-system syndrome: There’s a lot of bug reports in bugzilla asking for all kinds of crazy features to be added to Metacity’s theme format (I’ve filed a few myself) and I know if I was responsible for organising a v3 format, the temptation to solve them all at once would be near unbearable. However, if the v3 format is just a reformulation of the working v2 features into a new, extensible format, all the shiny new features can be safely implemented later.