Promiscuous stylesheets in Drupal 7

One common practice when using CSS frameworks such as 960 Grid System, Blueprint, or Baseline is to use a CSS reset. Each web browser applies a set of default styles to HTML elements, and these styles vary among browser vendors. A CSS reset is a stylesheet that clears these default styles so that you know what you’re working with as you implement your theme’s CSS.

The caveat with a CSS reset is that it needs to come before all of your other stylesheets. This presents a problem if you want to use a reset in your Drupal theme: all of the theme’s CSS will be added after Drupal’s system CSS and after any modules’ CSS. If your reset is loaded after these, the system and modules’ styles will all be undone, which probably isn’t what you want. Drupal loads theme styles last because, usually, you’re just adding to or overriding the existing styles, not wiping them all clean. It is possible, however, to have Drupal output a stylesheet from your theme before the system and module stylesheets.

In Drupal 6, the easiest approach is to hard code the link to the reset stylesheet in your page.tpl.php template. Unfortunately, this approach doesn’t take advantage of the built-in CSS aggregation and caching capabilities that Drupal offers, and it might get lost by a sub-theme that provided its own page.tpl.php template. Doing it programmatically in your theme isn’t easy, but a good example can be found in the ninesixty_css_reorder function in Joon Park’s NineSixty theme.

Drupal 7 makes life easier with an enhanced drupal_add_css function. CSS files can now be added to groups and then weighted within those groups to control the order of their presentation. Three numeric constants for groups are provided:

• CSS_SYSTEM: Any system-layer CSS.
• CSS_DEFAULT: Any module-layer CSS.
• CSS_THEME: Any theme-layer CSS.

This is the actual ordering of the groups; stylesheets in the CSS_SYSTEM will be added first, followed by those in the CSS_DEFAULT group, and finally by your theme’s CSS files which are automatically added to the CSS_THEME group. At first glance, this may not appear to help much, but your theme can put its stylesheets in groups other than CSS_THEME. Consider this code snipet from a template.php file:

/**
 * Preprocesses the wrapping HTML.
 *
 * @param array &$variables
 *   Template variables.
 */
function yourtheme_preprocess_html(&$variables) {
  $reset = drupal_get_path("theme", "yourtheme") . "/reset.css";
 
  $options = array(
    'group'  => CSS_SYSTEM,
    'weight' => -10,
  );
 
  drupal_add_css($reset, $options);
}

Assuming that your reset.css is listed in yourtheme.info file (required in Drupal 7), your reset is moved to the same group as Drupal’s system CSS files. So what weight should you use to make sure your CSS gets loaded first? Well, really, you don’t know unless you dig through Drupal’s source to figure out how the system stylesheets are weighted.

Or you can get a bit promiscuous.

Remember that those stylesheet groups are actually numeric? CSS_SYSTEM, CSS_DEFAULT, and CSS_THEME are (currently) the numbers -100, 0, and 100, respectively. The groups are output by their natural numeric ordering, so let’s change one line in the example above:

/**
 * Preprocesses the wrapping HTML.
 *
 * @param array &$variables
 *   Template variables.
 */
function yourtheme_preprocess_html(&$variables) {
  $reset = drupal_get_path("theme", "yourtheme") . "/reset.css";
 
  $options = array(
    'group'  => CSS_SYSTEM - 1,
    'weight' => -10,
  );
 
  drupal_add_css($reset, $options);
}

We’ve changed the group from CSS_SYSTEM to CSS_SYSTEM - 1 , giving it a value of -101. This creates a new grouping that is numerically less than CSS_SYSTEM causing our reset to be output before the system stylesheets.

So why is this promiscuous? This tecnique relies on an implementation detail of Drupal’s internals that could potentially change. Techncially, you’re abusing the system, and you should only use it when you have a good reason. Of course, you can also just hard code the reset in your html.tpl.php template, but this carries the same disadvantags as it did in Drupal 6.

Commenting on this Blog post is closed.