support skins+discussion

Design needs/questions

1. What's our convention for handling different num columns?  class attribute of body tag?  on sections?  should we make js set this?
2. Shall we uglify these stylesheets? (meaning precompile them into one smushed up sheet for speed) done
3. Should we support sass?  Should that be the default? (inclined to say yes -- you can use basic CSS if desired; that's how sass works) added SCSS type
4. Do we want to support inclusions in stylesheets? qualified yes.  will explain in skins documentation
5. To what extent should we separate colors / fonts / spacing? somewhat.  explained in CSS / SCSS cards (visible soon)
6. Is it safe to move to HTML5?  Need this shiv? (wow, there are a bunch of other polyfills)  moved to HTML5; using shiv
7. are there parts of this that are so frequently of interest that we should give them separate cards and include?  eg background color (with color interface) (inclined to say wait til later on that one)  progress on this. will show
8. a more conventional approach (eg google sites) might have it so that you can turn certain sections on and off (eg, click to turn sidebar off).  is there a compatible way to offer something similar?  punt

a. active components for choosing themes (skins) from a list of canned ones wagn sends out - Prototype: Nautical theme - skin:  knotty

b. js is the skin, css is the theme - skin.js, theme.css

c. Uglify? hmmm

Anyway.. just trying to find places to jump in. Gerry's pretty much taken me under his wing.

My specialty is style and grace. --cq *Use POE or die*

  --cquin.....2013-02-26 06:11:37 +0000

a. in the solution above, the active component is the "*style" rule. You'll edit styles just as you would any other rule (currently through the advanced tab). We could choose to use the word *skin or *theme, but I think *style is the best fit, because we'll often combine multiple stylesheets. Also, to my mind, the "skin" is really the combination of the *layout and the *style setting.

b. javascript is for (in our case) client-side functionality. skins are by definition superficial and should not impact functionality, just appearance. The difference between skins and themes is usually just depth of configurability.

c. "uglify" is a tool for smushing all the css into a single file; it makes page loads faster (and it means fewer web requests)

  --Ethan McCutchen.....2013-02-26 16:05:47 +0000

what's POE?

  --Ethan McCutchen.....2013-02-26 16:06:57 +0000

http://en.wikipedia.org/wiki/Perl_Object_Environment

  --cquin.....2013-03-22 05:04:28 +0000

process:

1. add new types
2. add new settings
3. get pointers translating into scss includes
4. locally move all nonfunctional css to cards
5. add in uglify
6. get file caching working

Thought: assets like these that are sourced in Wagn cards, or in particular the CSS part, we could use something like what is used for File/Image cards where the served file is processed into a real file complete with version identification. then we can do something similar and serve up .../CSS-card-name- .css from the web server cache.

Will we ever want custom javascript on some pages too? Should we add cardtype and settings for that too?

re assets, that's not quite how it works now. we're using standard asset pipeline fingerprinting, which means it's not a web server cache at all, but instead the browser is instructed not to make repeat requests. So, in fact, every time you get a file request to the server, it does go to wagn to process the permissions.

My hope was to follow this pattern for CSS files, though, and have a real file initially (though we could ultimately do it from memory if we prefered).

Javascript is not relevant here, but if you have a use case we could explore it (elsewhere). My general assumption has been that we'd only be compiling one js file, but that it would use standard jquery wagn patterns to assign behaviors to sets of cards as needed. I doubt that it's common to need a lot of different behaviors for different layouts, but if so, even that would be relatively easy to accomplish with a single file.