There has been a big buzz surrounding Skinr these days especially at Drupalcon SF 2010. There is also a lot of confusion about what it actually is and does. Being that the module was developed by my fellow employee Bala Bosh and the brain child of my sister Jacine Rodriguez, I have a unique view of Skinr. I'm not too involved to the point where I can't explain the basics and how its useful for every themer.
For those of you who don't know about Skinr, in a nutshell it is a module that allows the themer to preset specific styles for content that can be applied through the UI. You can control anything with skinr that has a preprocess function - the entire page, nodes, blocks, comments, views, panels. The kinds of things you can do are limited only by your imagination.
Since its conception, Skinr has grown into a robust powerful module that every themer should know about and use.
OK, so why should I use it?
I know what you're thinking if you're a themer - "HUH? Why would I want MY styles to be available in the UI??" What it basically comes down to is that Skinr gives you the power to make your life easier. My sister showed a site in her Skinr session at Drupalcon SF that she themed in two weeks about a year ago that is still under heavy development. Because she used Skinr she hasn't had to touch the theme once since she completed it! Thats pretty amazing!!
The way I see it there are three main aspects of theming that Skinr helps with tremendously: one is when things change along the way, two is reducing the amount of basic styles you repeat with every theme and the third is making theme changes by page.
Addressing the first aspect: things change
Say on the front page of a site you or the developer decided to use jquery carousel to showcase some items and lets say you styled that based on its unique classes. What you get is one-time use CSS. If, and sometimes ultimately when this changes, say to use node queue instead, you will have to go back into your CSS and re-do the styles. If you had set this up as a Skinr style from the start this change would be as easy as a couple of clicks in the UI. Setting up styles for blocks, panel panes and views etc, in the beginning of the process saves you so much time in the end. No matter what changes along the way you can easily reuse the CSS you have already written.
Reusing basic styles with skins
With the latest dev version of Skinr a new concept of Skins has been introduced (At this point I must say that this version of Skinr is under heavy development and should not be used on client work yet). Skins consist of a .info file declaring all Skinr styles associated with it, and any additional files needed for those styles. The skins folder sits in /sites/all/skins and is available for you in the UI to enable or disable - this functionality is much like enabling modules or themes. One of the best ways to use skins is to package up CSS that you use across every theme you do. Examples range from 960 Grid system, drop downs, font styles, list styles, etc. Having these available for your use cuts out the boring repetitious CSS and allows you to focus on the fun stuff.
Page level styles
In the same fashion that you can control a blocks visibility by page, with Skinr you can set certain styles or classes by page. So if you needed one page to have something styled differently based on user roles, path or PHP you could do so here. More importantly with page styles you can set styles across all pages. Which is generally where you'll set styles for font-stacks and layout.
A lot of the features of Skinr that I'm discussing here are in the 6.x-2.x-dev version. Though this version is not ready for a stable release, the direction the module is going has the potential to really change the way you theme. I use Skinr and I think you should too. I will be working on more posts about how to actually use Skinr, but if you can't wait please check out the Skinr group on G.D.O or test some of the new features and help us get this to a stable release!