Skinr’s main purpose is to allow the theme to define a set of reusable and modular CSS styles, and to make those styles available in Drupal’s UI. Skinr was developed for themers to allow them to tap into the power of Drupal’s modularity and apply those same principles to theme development. It does not provide any styles of its own. These styles are defined in the .info file of the theme (or subtheme), by the themer and end up in various places in Drupal’s UI, such as:
It also provides a CSS class field, where you can manually add custom classes.
Who should use this module?
Here are a few examples, though there are many more possibilities.
- You are a themer looking to dramatically reduce the size and bloat of your CSS files.
- You want to be able to apply the same CSS across blocks, panel panes, views, nodes and comments.
- You are developing a theme for a client and want the client to have more flexibility and access to a multitude of existing styles, after you’ve completed the project and handed it off.
- You are a contrib theme developer who wants to provide multiple styles and allow the site administrator to be able to choose where to apply them.
- You are a rebel who wants to rip out CSS classes in every possible template file and use your own instead, but need a better way to add your own classes back to Drupal.
Module developers can take advantage of Skinr using its API. Detailed documentation on how to do this is included in docs.php.
Skinr information excerpted from drupal.org
I attended a great presentation by Jacine Rodriguez this afternoon. I’m going to experiment with it when I get home. Is Skinr the panacea it appears to be?