Conditions

When a user agent (i.e a Browser) makes a page request, all the resources registered in the registry are evaluated against their condition field. If the condition is true, the resource is served to the browser. If the condition evaluates to false, the resource is not served.

This gives you the ability to conditionally serve different style sheets or scripts based on logic like whether the user is logged in, whether you are in the "Human Resources"-section of your intranet of if the content-type is a news-item.

Read more in my small and general how-to on CMF Expressions

Merging

Whenever you click the save-button in a registry, a new set of css or javascript files are created. The registry will try to assemble the different resources into bigger lumps/files to server to the browser. This is to reduce the number of http-requests necessary and can improve performance considerably.

The rules for merging resources

1. The registry will only try to merge resources that are adjacent in the list. Otherwise you would risk that the order of operations in the browser would be affected (order of code in javascript and the order of the cascade in CSS. This would possibly affect rendering or execution in the browser in a negative way, and is therefore not available ).
2. Two adjacent resources are only merged if their condition is exactly the same (more about conditions in the next chapter)
3. Two adjacent resources are not merged if they don't have the 'allow merging' checkbox checked
   

The magically assembled 'Files' are assigned a new random number as their name. So you'll find entries like <link rel="stylesheet" href="plone2341.css" /> in your html source.
You can inspect how the resources will be merged if you click the second tab in the registry; "composition". It will present you with a list of 'magic' files, like 'plone2341.css', and nested within them the component resources they are constructed from. You can click each entry to inspect what it will look like when served.

The CSS-composition UI

Each merged resource will have a small snippet in the source identifying its origin so that you can get hold of the full unmodified source if you need.
The comment stuff usually looks like the following.

/* ----- base.css ----- */
@media screen {
/* http://yourhost/plone/portal_css/base.css?original=1 */
/* */

Caching and HTTP

The merged resources are automatically served with HTTP-headers optimized for being cached a long time. Since the auto-generated number is being changed every time you save the registry settings, the browser will request the new 'files' and not use its old cached values anyway. The scheme is actually rather clever.

The potential problem with the caching scheme is that the registry doesn't know if you change the files in the skins directories unless you touch the "save" button in the registry. This  is only an issue while you are working on your CSS (or Javascripts) to get them right, but can cause massive confusion if you make changes and only see cached styles/scripts in the browser. To avoid this issue, we have added a handy "debug and development" mode to the registries.

Debug and development mode

To enable the debug and development mode, check the corresponding checkbox in the registry configuration page and click "save".
Enabling the debug and development mode

• Disables merging of resources (great for finding bugs and specific declarations with the inspectors and development tools like Firebug)
• Sets HTTP-headers for not caching so that you get a fresh copy every time
  
• Disables compression

These settings affect performance in an adverse way, so make sure to disable the debug mode when your Plone goes live.