Will is a senior developer at DNA Design, Wellington, New Zealand. He has been a contributor to SilverStripe since 2007, maintains several modules and is a well known face around the IRC and Forums as willr.
Over one year ago now, a group of us got together and started thinking about how we wanted to implement Felipe's awesome new UI for SS3.0, and how should SilverStripe go about turning the pretty pixels into reality. The design itself was a product of some fresh thinking from the UX front, so it felt right that we take the same care in designing the front-end architecture.
The CSS behind SilverStripe 2.X was the result of over six years of battle-hardened and tormented stylesheets. Cluttered over the years with more and more styles, hacks, odd classes and work arounds for undisclosed edge cases that arose over the long years as SilverStripe grew and grew. While at the same time, the entire landscape of front end development was evolving, and it has now morphed into a totally different beast to the one that was around when SilverStripe 2 was first conceived (though IE7 is still around!).
As everyones putting a huge amount of effort into developing, testing and bugfixing the new CMS for 3.0, it makes sense for us to use a tool that could take some of the pain out of quickly implementing the modern, dynamic CSS that we need while giving us a solid base to last another six years.
To help us with this, we turned to a stylesheet language called Sass and a Ruby-based tool called Compass. At this point I can hear the sighs and murmurs about how you don't want to be forced to use Ruby to develop with SilverStripe, but truly, as the uber cool engineer you are, it's good to get out once in a while. We shouldn't be scared of new things, go meet them, relax, and you'll be fine. Plus, we've got an easy module to help run Compass, and you only need Ruby and Compass installed if you want to customise or alter the core CMS and framework styles. If you want to include plain old CSS in 3.0 you still have the freedom to do so, but personally I love some of the features Compass has to make my life easier.
I should also mention at at this point, I'm still experimenting with what's possible in our Compass - SilverStripe integration, as well as some of the implementation details of our CSS, so if you have thoughts or opinions please post on the dev mailing list.
SASS / SCSS?
Sass (Syntactically Awesome StyleSheets) is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance which is compiled into standard CSS. It comes in two syntax flavours; SASS and SCSS. Each have their own ins and outs to the syntax but in 3.0 we've gone with SCSS, which has a similar style to original CSS.
Compass?
As the Compass site puts it, Compass is an open source CSS Authoring Framework. I mentioned in the previous paragraph that SASS is compiled into CSS; Compass handles this compilation for us and provides a further set of tools on top of that. Things like reusable common patterns (such as clearfixes), functions for operations and mixins for CSS 3.0 properties. These tools, on top of the language features of SASS/SCSS, all help decrease the SLOC of CSS that we'd need to maintain in the core.
SCSS + Compass + SilverStripe 3.0 =
Since this is only a short introduction, I recommend you pursue the Compass and Sass websites for more extensive information on each, but I want to highlight a couple things we're using.
SCSS Variables
One thing I love about the SilverStripe community is that I'm surrounded by amazing fellow web developers choosing to invest time and effort into building applications and websites for their clients on SilverStripe. I was once asked by a developer if they could re-brand SilverStripe; not only is this allowed, we're trying to make it even easier in 3.0. In 2.4 you could easily change the name and logo but any CSS changes had to be hacked on top. Now, by building the back-end interface out of SCSS variables, we can open a range of possibilities for branding.
We're still working out the kinks as to how this is going to work, but you can see a quick example of an admin 'theme' on github. We use a lot of the Compass helpers such as darken() and lighten() as well as the linear gradient mixin in Compass to change the whole interface based on that short list of variables.
Our goal is that module authors and site developers will be able to easily create their own SCSS variables for the back-end and replace existing ones in their own themes. In theory, allowing for a branded CMS experience to be developed easily and quickly.
sprite-map();
This clever little helper comes out of Compass and helps build sprite maps dynamically. A sprite map is a single image that includes a collection of smaller images. The purpose is to reduce the number of HTTP Requests as rather than loading 12 images, the browser loads the one map. When the first designs came out, SS3.0 included a magnitude of icons that we knew needed to be accounted for, but at the time didn't have a complete list, or any actual icon libraries, so by using sprite-map() we could include the individual icons in a folder and let compass build the sprite for us. As designers added more icons, they could just put the single icon files into the folder and allow compass to do all the hard work.
Nested Selectors
As part of our goal to write cleaner, more encapsulated code for the back-end, a significant portion of the back-end is written in nested selectors which reduces repetition and encourages intelligent thinking about where selectors should be placed.
Conclusion
The current implementation of the new back-end CSS is only the start of our process of building a new solid, extendable core back-end CSS architecture. While the 3.0 UI and UX is still being teased out, we as developers have a long journey of refactoring and constant refinement ahead. Help SilverStripe by staying vigilant and we can all contribute to ensuring SilverStripe has clean, extensible and maintainable SCSS for many years to come.
