About half a year ago I talked about how you could use sass do create stylesheets dynamically with different color. I was asked to go further into detail on how to do this. I’ll also illuminate on some of the thing I learned since last time and how I incorporated the new insights.
I have also done a lot of discovering on how to make css more efficient with sass. I have also needed to do some alternative work with colors to have it working for me. Going through an existing css code base there are a lot of issues with optimization of your code. These issues are not new and are quite common in css but sass can solve these common issues.
Color pallets revisited
As I showed about half a year ago this is the schema I made for the multiple color schemes from one compiled base. Basically what I did was create a file with variables, that file would acts as a color pallet. I would include that pallet into the configuration files where I would use the colors and delegate them to a proxy variable that is actually used in the sass. then I would include all the different sass files I had that had the styling in them. One of the things I did to make it easier for me to do that was to make a collector file that would combine all the different style files as a kind of proxy. This way I only needed to include the collector to get all the different style sass files.
Here is some example code for what I have done with the sass and dynamically colored themes:
-------------------------------------------------------- // file: _pallet.sass !text_light = "ffffff" !text_dark = "000000" !home_1 = "6d276a" !home_2 = "a77da6" !home_3 = "c5a9c3" !home_4 = "e2d4e1" !alt_1 = "00554b" !alt_2 = "669993" !alt_3 = "99bbb7" !alt_4 = "ccdddb" // file: theme.sass (this file is called from the templates as a css file) @import pallet !color_1 = !home_1 !color_2 = !home_2 !color_3 = !home_3 !color_4 = !home_4 @import collector // file: _collector.sass (here all the different sass files are combined here) @import style_file @import another_style_file @import and_another_style_file // file: _style_file.sass .someClass background-color= "#"+!color_1 color= "#"+!text_light background-image= "url(/images/background-"+!color_1+".jpg)" --------------------------------------------------------
As you can see in the code example above I used the theme and the collector as a proxy to connect the colors to the styles. If you look closely at the code I did some stuff that is out of the ordinary. Working with strings instead of color variables and using double proxies. The pallet is also used multi level. Straight from the pallet or dynamically from the color proxy.
String vs color variables
I used strings instead of color variables for a good reason. Color variables allow you to calculate within sass, but I needed them for something else. I needed the variables to take care of color and image files. I had files that contained colored images so they needed to become part of the them. In the example _style_file.sass file you can see how I incorporated the string into the URI of the image. Drawback of this technique is that you will need to call the string to value operator every time and add the hash tag (#) to every string. As it is compiled the result will be the same. Doing this with Scss and RGBA color requires a different approach.
Pallet contains all the color codes, the style sass files contain the actual css and the two proxy files in the middle connect the dots.
It was useful for me to have a collector file that combined all the sass files containing the style. I divided my files up into chunks as I had a large system with widgets, components and different layouts. To keep a good overall look at the style the chunking was a good solution.
The pallet allows me to store all colors in one place. This centralized place has the same advantages as a real world painters pallet. An overview and a good origin of color. The files that are called will compile into the actual theme file. This file is also the configuration proxy as it sets the correct colors for that specific theme. This allows me to generate different colored themes from one single set of code.
Static, loose and common colors
One of the issues I also had was that some of the colors needed to be used straight from the pallet. I did this with the text example color where I used the variable name straight from the pallet. I call these static in the themes colors.
The colors that are always going to be a theme specific set of colors I call the common colors. This is useful for areas that always have a different color in a theme. I also have a different problem where some of the themes will need to take on 1 color and another needs to look like a patched blanket with all different colors for different widgets. Here come my final strategy, the loose color. In some I would use the configuring proxy to set the color the same as the common one. In others I would set them their own specific color. Any widget could bare there own color in that way in one theme where the other it would have it’s own color.
Another trick I used was combined parameters. I would separate color style attributes and dimension style attributes. This allowed me to use the same dimension style attributes that would overlap on the different widgets. Creating a css framework so to say. The color would then be determined by a overlaying class name. Using functions that would be mixed in to those overlaying class name. Just an example:-------------------------------------------------------- =function_Name(!widget_color_1, !widget_color_2) background-color: !widget_color_1 color: !widget_color_2 .overlayClassName +function_Name(!home_1, !home_2) --------------------------------------------------------
This combined with the combination of static, loose and common colors allowed me almost unlimited freedom. I can created a set of over 10 themes distributed over 3 different stylsheets with a fairly small amount of code. That is 30 stylesheets with every color set having 16 colors. So 30 stylesheets with about 160 different colors… and all dynamically!
Sass vs Scss
Scss (Sassy CSS) is the new format for sass. The syntax is closer to native css and there are some extra features. Switching is easy because there is a compiler build into the latest version of haml. With this compiler you can go back and forth from sass to scss and back. If you thinking about switching think about it:
- Fairly the same syntax as haml and yml
- Less symbols to write
- More like css
- Newest supported version
- Some minor new features
Things to keep an eye out for
- Generating css is nice but you still need to create good css. You become easily bogged down in a system with over a thousand lines of sass that compile into million lines of css. Browsers sometimes choke on that… Like internet explorer only permitting 31 external stylesheets with a specific maximum capacity (I was trying to compile the jQuery UI css files raw through my color proxy… went horribly wrong).
- If you are creating chunked css files that you are combining later. Start the file names with an underscore ( _ ). This will prevent them from compiling on their own. And in my system without the pallet and config proxy it would not compile at all and give a warning on production servers.
- The use of mixins and functions can become really confusing as it is only a functional language… If you use them, keep them in the same file and use clear naming.
- DONT FORGET! write good css first and then apply it in sass later. It should not be a solution for crappy css coding! You can start writing sass but remember to optimize your css use as much as possible!