SCSS, Compass and SilverStripe 3.0

Posted by Will Rossiter on 27 March 2012

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.

See how we do icon sprites

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. 

Post your comment

Note: Comments are moderated and won't show until they are approved

Comments

  • Using scss / sass (and compass) is a very good decision imho.

    I have started using lesscss over 2 years ago - and it does have a javascript compilation tpool also available - preferebly from a cdn.

    less css syntax is very similar to scss -- kind of like an extension on top of css. nested selector, functions, variables, mixins - same feature set - a bit different syntax (vars are $ in sass, @ in less for instance).

    So good decision - even if I'd go with less - sstripe is an amazing tool kind of the best stuff since sliced bread :)

    Even if I have to tell that wordpress is kind of becoming a de-facto CMS in the last few years, tons of plugins, tons of possibilities, easy theming, very nice admin gui (sstripe3 now will be on par with the admin now) since I do like well written code and easy changing of stuff around (this depends on a usable and easy to use, all features document guide / docs!) so sstripe is better for me.

    True - the ruby world would be good to have something like silverstripe. In the meantime you can find: http://activeadmin.info/ and http://www.padrinorb.com/ for instance.

    Posted by John, 2 years ago

  • "I prefer sass over scss.
    I tried both and have to say, it's a little sad that silverstripe didn't went with sass all the way.

    All these brackets are really lame ;)"

    The template engine (and by extension the CSS tools) is targeted at front-end developers, and we trialled both Sass and SCSS on a few projects. In the end, we found that Sass broke too many expectations about CSS and just confused people too much.

    If you have a development team who are accustomed to dealing with languages where whitespace matters, then Sass might make more sense, but SilverStripe isn't that kind of project.

    In the end, the pitfalls of Sass proved to be very real, and the benefits proved to be much less concrete. So we went with SCSS.

    Posted by Sam, 2 years ago @sminnee

  • "Quite the opposite is the case, it's a shame that a uber-awesome tool like SS requires you to deal with a shitty language like PHP. A similar CMF for Ruby would be the greatest thing since sliced bread."

    Maybe we should put together another blog post about why we use PHP. ;-)

    Posted by Sam, 2 years ago @sminnee

  • Hi!

    I prefer LESS.
    And with lessphp we can generate CSS automatically on the server using PHP.
    I think that this would be more homogeneous with SilverStripe. Since SilverStripe is developed in PHP.

    Regards,
    Jose

    Posted by Jose A., 2 years ago @jamolina2010hotmailcom

  • I prefer sass over scss.
    I tried both and have to say, it's a little sad that silverstripe didn't went with sass all the way.

    All these brackets are really lame ;)

    Posted by peter, 2 years ago

  • That sprite map sounds super handy!

    Posted by Frank, 2 years ago

  • > 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 […]

    Quite the opposite is the case, it's a shame that a uber-awesome tool like SS requires you to deal with a shitty language like PHP. A similar CMF for Ruby would be the greatest thing since sliced bread.

    Posted by rbq, 2 years ago @rbq

RSS feed for comments on this page | RSS feed for all comments

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.