Break out skin-specific properties into *-skin.css modules

[msweeney]

As @jshirley alludes to in his comment on the preprocessor thread (#68 (comment)), in order to make customization easier (and following our modular approach) it would be nice to have all of the styling that we consider "skinnable" broken out into separate files. I propose that we move "skin" specific styling into separate src/build files.

This would provide consumers with a template file for customizing skins and the option to include their skin as an alternative to the default *-skin.css module(s).

[msweeney]

I took an initial pass at this: https://github.com/msweeney/pure/tree/skin-breakout to see how feasible it would actually be.

I broke out colors, borders, and padding for now. Adding margins and fonts seems reasonable as well.

The only real gotcha that I've hit so far is that the *-r.css (responsive) versions of some modules (forms-r.css and menus-r.css) contain skin styling. Having separate *-r-skin.css files feels like overkill, and having them applied when only using the *-nr.css file breaks the "non-responsive" nature of these files.

[ericf]

@msweeney after talking with you last week about this, it seems like a reasonable idea. I think we should start small when we look at what rules we want to move over into the *-skin.css files. I think we start with what Skin Builder allows you to customize.

You mentioned fonts, some of those settings are coming from Normalize.css, and I think we should avoid settings fonts in Pure (besides those cases).

I also agree *-r-skin.css feels like overkill. It would be good if we can refactor things to avoid the need for these "responsive skin" files.

[tilomitra]

Whoops! My bad.

[rictorres]

+1
I was actually thinking about porting Designmodo's Flat UI into Pure as a separate theme and this modular approach will come in handy.

[jamesalley]

At first I was interested in this proposal, since in my own work I like to keep skinning/theming as a separate layer. But I also do like to have default colors (preferably monochrome) and borders in place, so that components work well without any theming. Pure has a similar approach; just dropping in pure-min.css should get the vast majority of users going. They shouldn't have to think about stitching in a skin or theme.

If we followed this proposal, it would make the code DRYer in one way: for developers who omitted the default skin files in favor of their own, rules wouldn't have to be wasted on override. But we'd likely bundle the skin files with pure-min.css, and those skin files have large selector blocks which would be repeated, making the code a bit bigger and less DRY in that respect.

I vote for keeping the existing, default styling properties baked in.

[jamesalley]

Despite my last comment, in the case of Menu, when I refactored it recently, I ended up doing just what Matt proposed. I still bundle the skin by default, but if you do your own rollups you'll more easily be able to omit the skin properties.

This is something I plan on doing going forward. I'm not going to break out all skinnable properties all at once, but as I refactor any given module I will be keeping this in mind.