Currently you have to edit CSS (the *css card) and HTML (the *layout rule) to change a site's look. We want it to be super easy to change skins and add new ones. At the same time, we want to retain the possibility of letting power users go down to the lowest level.
explained on Skin card.
- What's our convention for handling different num columns? class attribute of body tag? on sections? should we make js set this?
- Shall we uglify these stylesheets? (meaning precompile them into one smushed up sheet for speed) done
- 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
- Do we want to support inclusions in stylesheets? qualified yes. will explain in skins documentation
- To what extent should we separate colors / fonts / spacing? somewhat. explained in CSS / SCSS cards (visible soon)
- Is it safe to move to HTML5? Need this shiv? (wow, there are a bunch of other polyfills) moved to HTML5; using shiv
- 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
- 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
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.
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
--Ethan McCutchen.....2013-02-26 16:06:57 +0000
--cquin.....2013-03-22 05:04:28 +0000
- add new types
- add new settings
- get pointers translating into scss includes
- locally move all nonfunctional css to cards
- add in uglify
- 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.
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).