When building a web-application you’ll need to do some sort of styling to get it looking a kind of decent. To enhance your web app you would probably like to do some more advanced styling with lots of css, images and other stuff… But what if you needed a styling system that dynamically changes the colors of your style?
I’ve designed and implemented an application that uses Sass to created dynamically colored styling for such a system!
Why did I need this?
There are several options! My first solution back in 2003 was to add color variables to my php generated .css files. This created stylesheets that would dynamically be colored by the page call. Although this is a decent solution it was not a very efficient method or was it a very technically sound method…
Later in 2009 I encountered the same problem. I worked on a project for the (dutch) company Operator Groep Delft. They were creating a new type of social intranet system that was very user based. By design it had different sections/modules and all these modules were designed to have their own color. For this to work on all the pages and with all the different needs from the styling I needed to come up with a plan.
There were very specific needs and the project was already using ruby as it’s language. So I started to created a couple of solutions that suited the given requirements. It was presented in a short paper (css design justification) with a presentation to make the choose the solution. This was all done in one short week.
What is the solution?
The idea chosen to be implemented was the compiler generated css files for the different colors. The compiler would use files that had no colors but just locations where different colors needed to go. The compiler would then generate the differently colored style sheets according to a configuration files. These configurations would contain the colors that were needed. The compiler would also minimize the css file size by removing whitespaces and breaks from the code.
The advantages of this solution are:
- keeps code readable but contains the file size by optimization.
- allows for different themes to be generated out of the same source.
- it is very modular as code can be separated in files that are later combined.
- load on server is minimal as the file generation happens during build and will not slow down traffic.
The disadvantage of this solution is:
- you have a different file for all styles when they are mostly the same.
We started out with the idea to build our own compiler. This was not a good idea and after struggling to create a good implementation we found Sass. Sass stands for Syntactically Awesome Style Sheets, and they are awesome! Sass is a different and more dynamic notation of css that allows for selector nesting, parent referencing (for pseudo selectors), variables, operations, interpolation, mixims, arguments, importation and optimization.
With Sass I created a structure where we had different .sass files for all the different sections that needed style. These were modular build so that they could be used for specific modules or re-used for others as well. the different files would then all be imported by a collector that imported all the styles needed. This was useful as it is a single call for more then 100 files (it’s a big system). the actual style sheet would be generated out of the configuration file for a certain theme. the configuration file would set the colors and then import the collector to complete the picture. To define the colors, more then 150, I created a pallet as that made it easier to manage the different colors and edit them on one place. This changed the configuration to only assign colors from the pallet to specific variables used in the system.
It might seem odd but we needed to have the 150 different colors behave in a different way on different kinds of parts. Some parts were always a specific color, other would always change to the module specific colors and the some would use the module color in one theme and their own colors in the other. So I identified:
- Common colors: have the color of the module
- Loose: could have the colors of the module if forced
- Static: always have their own color
These colors types were used as basis for the variables in the configuration files. so a common color set, a loose color set for all the modules and the static set comes directly from the pallet. The configuration always has the pallet included and calls the rest of the css, in this way the configuration will not break and it will save code.
More about Sass
We intended to create our own compiler to optimize our use of css, but we stumbled upon Sass. Sass as a plugin that comes with haml had already caught our intention as haml makes it easier to write html. We use sass, but where does it come from and why does it work so well?
Sass works so well through it’s simplicity. Install the haml gem, install the sass plugin into your app and it is ready to use. You can convert regular css to sass without any big problems, it even optimizes the code automatically. Although the transition may not be completely smooth with complex css it is far better than one would expect. It does not only work well because of the transition from css to sass is smooth. It is more about the use of dynamics in your code to generate css and about the short nature of the syntax. Sass work very elegantly with variables and some kind of functions/models to reduce your code and allow for different dynamic implementations.
One interesting side note is that sass does not interpret the code, it just shows what you’ve created. So an attribute called foo with the value bar can be created without any problem. This is useful with the specific mozilla and webkit style attributes and the compatibility with css3.
more information about sass can be found on the sass website.