I've been kicking around some ideas for how the CSS system should operate, and I think I've come to some conclusions:
We have a range of different types of CSS data that will need to be combined. First of all, we have the base (default) CSS for the Website; then there will be customizations overrides for that CSS (user). This distinction is the same as that for the interface strings. Next, we have the base CSS for article/contribution display; then, layered on top of that, is the CSS specific to each style guide (APA, MLA etc.); then on top of that come the user customizations of that display. It's really complicated trying to figure out exactly how all of this should fit together.
I need a system which enables a single stylesheet (or possibly two) to be created from the database through an XQuery, which intelligently merges all of these layers of data, which are stored in a range of different XSLT attribute-sets in the db. The problem is that some of the rulesets may be additive (at the base level, for instance, <h2> tags may be set to text-align: center, while further down they're specified as a particular font size), while others may be replacements for each other; it will be difficult to tell the difference. One approach is to gather all the instances of a particular selector from all the db files, then iterate through their attribute @name values, using only the lowest-level one (so that an h2{text-align: center;} at the lowest level would be overridden by a text-align: left setting in a user file further down the cascade). That this is possible shows the advantages of storing this info in XML format -- it's easy to parse and compare values -- but the problem is slightly complicated by the existence of shorthand properties. However, as long as user rules are included after any default rules with which they might clash, the cascade will take care of the problem, albeit at the cost of a larger file.
So the "hard" problem is really how to divide up the data amongst the various types of file. The cascade should probably go like this:
- "Base" file -- controls the site interface, and sets core font choices etc.
- "Style" file (APA, etc.). This is another base file which is added onto the top of the site style, to provide new styles required for the display of articles in the default style, etc.
- "User" file. This is a set of customizations which are added at the end of the cascade. When the user is customizing, they start from the style guide they've chosen (in other words, their GUI will present them with a combined set of existing CSS, based on the combination of the "base" and "style" data). Their customizations are modifications to this.
The only wrinkle here is that, if the user then changes the style choice AFTER adding customizations, those customizations might not interact perfectly with the new style. However, that's to be expected, and the user can be warned about it, and can modify the user styles appropriately after choosing a different style.