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:
- Nearly all websites have a title bar, smattering of “most important” links and copyright line.
- Most have some sort of side-bar navigation.
- Nearly all use the rest for replaceable text.
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: <title template:replace='pagetitle'> Example Text here </title>, and <div template:replace='content'> Body text goes here </div>. 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:
index.html, the template for the pages in the site. For processability, it will have to be well-formed XML at least, and preferably valid XHTML.images/, a directory of images used in the design.*.css, the stylesheet files used in the designREADME, text instructions and/or notesManifest, a formatted description of the theme metadata — author, design title, contact information and licensing terms.
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.