I think you’d still need frame_style_set elements, you might want a particular frame_style to be used for two or more disjoint sets of tags.

The more I think about this, the more I remember that a bunch of clever people have already done the hard work of designing a language for composing visual styles from least to most specific: CSS. Rather than matching elements, you’d match pieces; you could use psuedo-element syntax to match states, class syntax to distinguish buttons by location and ID syntax to distinguish buttons by type… something like this:

window:active:maximized title_bar {
/* Styles the title-bar in a focussed, maximized
* window
*/
padding: 2px;
}
dialog:active:resizable(X,Y) #close_button:hover {
/* Draws the close_button in the prelight state on a
* focussed dialog that is resizable both
* horizontally and vertically.
*/
draw: url(“#draw_close_glyph_prelight”);
}
modal_dialog .left_button {
/* Sets the inter-button spacing for buttons that
* appear on the left-hand side of the title bar
* of a modal dialog.
*/

/* I would imagine that unlike HTML, margins would
* only be relevant on button elements, and margins
* would collapse horizontally (rather than
* vertically)
*/
margin: 0 5px;
}

I can think of a couple of problems with this model, of course – firstly, there’s no good way to express draw_ops elements in CSS syntax. This could be addressed by having themes be XML documents containing a style element for the CSS as well as a collection of draw_ops elements with id attributes, and the CSS could refer to draw_ops with “draw: url(#draw_dialog_border);”.

Another problem that springs to mind is that ideally the CSS styles would handle both drawing and layout; that is, they would subsume the current frame_geometry and frame_style elements with “padding” and “margin” and “draw” styles. This might be so radically different from Metacity’s internals as to ruin any chance of implementation.

Lastly, CSS is not a perfect syntax – there are any number of proposals for improving it. Most of those don’t really apply here, because the “document model” for windows is vastly simpler and more static than for HTML, and the most practical need in standard CSS is for colour and size constants – which we cleverly side-step by keeping draw_ops in their XML syntax and re-using Metacity’s existing constant system.

Hmm… that was a lot of typing. Should I file that as an enhancement bug?