The Assemble-a-site system works by assembling all the required parts into a whole, like a jigsaw puzzle. Every project is different, being comprised of a different set of modules arranged in a different way. This creates challenges when it comes to CSS.

Variables

The most obvious issue with CSS is the requirement to make skins variable; in other words allowing the user to decide on what colours, fonts, etc they want to use on their site. This is easily managed by dynamically building the CSS files whenever they’re required. When the developer creates a new skin, he creates CSS files for that skin with a .css.php extension. Within the CSS code, he places variables whenever he needs them. When the file is called, it is parsed by the PHP server, and all the variables are replaced by the appropriate values.

Each skin defines its own set of variables according to the needs of its design and layout, and this variability of variables causes its own problems.

Unit-specific CSS

The much larger problem is the situation that requires each unit in the puzzle to have its own CSS file. For efficiency, if nothing else, we only want to include the CSS for a particular puzzle piece (generally a module or content block) if that piece is actually used in the project. Further, we actually only want to include it if it is actually used in the current page.

To do this, we have to provide a separate CSS file for each piece. This also aids with the modular nature of the project (keeping all the code for a module or content block in one place), and allows a developer to build a piece in isolation, without needing to work on the core systems at all. This architecture will allow external developers to build modules and content blocks for the project, laying the platform for an infinitely expandable system.

The difficulty here is that the module developer doesn’t know what skin his module will be used in. Each module or content block must define a certain set of minimum layout and style classes to make sure that they display correctly, but must take into account the vast range of possibilities within which it must do so.

The module and block CSS files will, therefore, define layout far more than style. They will use techniques to make their definitions relative to the parent styles (eg: using “inherit” a lot, or using ems rather than pixels to define sizes). If we define the skin CSS carefully, and define the module and block CSS to work with the skin, we should be ok. However, this is a wishful thinking scenario, and we’re not relying totally on that.

We also allow each skin to provide a CSS file for a module or content block as well. This file will take precedence over the module CSS file, and may include variables (module and block CSS files cannot include variables because their developers don’t know what variables are available to them – this is only defined once the skin is chosen). The order of precedence for CSS files in a skin goes like this:

1. Skin layout CSS

2. Skin Design CSS

3. Module CSS

4. Content Block CSS

5. Skin Module CSS

6. Skin Content Block CSS

Note: later CSS definitions override previous definitions. So, if a style is defined in the Skin Content Block CSS, it will be used even if the same style is defined differently in the Content Block CSS.

The Circular CSS Issue

Allowing a skin to override a piece’s CSS creates a bit of a circular problem. It means that whenever we develop a new module or content block, we need to access each skin we have, and decide whether it needs to override the default CSS for the new module or content block. This is going to become quite a challenge when we have hundreds of skins available, but I can’t really see a way around this issue at the moment. Careful CSS design should minimise this issue, and we’ll see what we can come up with later.

Caching

This architecture may result in a single complex page loading a lot of CSS files, and this may become an issue with efficiency and load times. For the initial release of Assemble-a-Site I am leaving this issue alone, but I have plans to build a more complex CSS generator that will dynamically build the CSS file as needed for each page by parsing all the required CSS files, including only the styles and classes that are required, and removing any that are going to be overwritten.

These CSS files can then be cached, so they only need to be built once. The cache would be cleared every time that page was edited, or any time anything was done that might affect the CSS, but this is likely to be far less often than the CSS file will need to be built. This may also be able to be expanded to solve our circular CSS problem. We shall see.