2005/06/17 00:58: A rough specification for a website "theme"

I've been working on a specification for replaceable visual styles on a meta-website I'm working on. So far, I've realized some things:

Therefore, it should be possible to make a drop-in style that works with the facility of something like a Winamp skin. Most websites can be shoehorned into that shape.

What I'm proposing is to mark the replaceable sections with amrita-style attributes: Example Text here , and

Body text goes here
. It's not perfect, but allowing some clean separation between templating engine and dropped-in text is a big plus.

In a "themeball", there would be several elements:

All files should use paths relative to the root of the theme directory, unless normal processing says otherwise (CSS in subdirectories that @import other CSS files should use URLs relative to the base file).

One sticking point is path mapping — each engine using pre-built styles will have a variety of URL schemes, and may not be located at the root of the host. The engine will have to be aware of its own URLs, and generate URLs that map to the parts of the theme. As the templates are read through the engine, the internal paths will be remapped to point to the actual URLs of the design components. A trivial example is one of an engine that lets a user select from themes uploaded to /themes, one theme per directory, named according to the title. A theme called "123 Blue" would have a server URL /themes/123%20Blue, and the components relative to that. Themes could also be assigned GUIDs by the engine, so a URL for a style component might look like /{1234-123467-123446-123345}/style.css. Generated pages would transform the source template's unqualified style.css into /themes/123%20Blue/style.css, and equivalently with images. By re-rooting an entire directory, the conceptual overhead is kept relatively low, and the processing simple for an XML-based parser.

P.S. No, just letting the user switch stylesheets is not enough. Shut up.

Comments.