Robin Winslow
on 5 August 2015
We recently introduced Vanilla framework, a light-weight styling framework which is intended to replace the old Guidelines framework as the basis for our Ubuntu and Canonical branded sites and others.
One of the reasons we created Vanilla was because we ran into significant problems trying to use Guidelines across multiple different sites because of the way it was made. In this article I’m going to explain how we structured Vanilla to hopefully overcome these problems.
You may wish to skip the rationale and go straight to “Overall structure” or “How to use the framework”.
Who’s it for?
We in Canonical’s design team will definitely be using Vanilla, and we also hope that other teams within Canonical can start to use it (as they did with Guidelines before it).
But most importantly, it would be fantastic if Vanilla offers a solid enough styling basis that members of the wider community feel comfortable using it as well. Guidelines was never really safe for the community at large to use with confidence.
This is why we’ve made an effort to structure Vanilla in such a way that any or all of it can be used with confidence by anyone.
Limitations of Guidelines
Guidelines was initially intended to solve exactly one problem – to be a single resource containing all the styling for ubuntu.com. This would mean that we could update Guidelines whenever we needed to update ubuntu.com’s styling, and those changes would propagate across all our other Ubuntu-branded sites (e.g.: cn.ubuntu.com or developer.ubuntu.com).
So we simply structured the markup of these sites in the same way, and then created a single hosted CSS file, and linked to it from all the sites that needed Ubuntu styling.
As time went on, two large problems with this solution emerged:
- As over 10 sites were linking to the same CSS file, updating that file became very cumbersome, as we’d have to test the changes on every site first.
- As the different sites became more individual over time, we found we were having to override the base stylesheet more and more, leading to overly complex and confusing local styling.
This second problem was only exacerbated when we started using Guidelines as the basis for Canonical-branded sites (e.g.: canonical.com) as well, which had a significantly different look.
Architecture goals for Vanilla
Learning from our experiences with Guidelines, we planned to solve a few specific problems with Vanilla:
- Website projects could include only the CSS code they actually needed, so they don’t have to override lots of unnecessary CSS.
- We could release new changes to the framework without worrying about breaking existing sites, allowing us to iterate quickly.
- Other projects could still easily copy the styles we use on our sites with minimal work
To solve these problems, we decided on the following goals:
-
Create a basic framework (Vanilla) which only contains the common elements shared across all our sites.
- This framework should be written in a modular way, so it’s easy to include only the parts you need
-
Extend the basic framework in “theme” projects (e.g. ubuntu-vanilla-theme) which will apply specific styling (colours etc.) for that specific brand.
- These themes should also only contain code which needs to be shared. Site-specific styling should be kept local to the project
- Still provide hosted compiled CSS for sites to hotlink to if they like, but force them to link to a specific version (e.g. vanilla-framework-version-0.0.15.css) rather than “latest” so that we can release a new version without worry.
Sass modularisation
This modular structure would be impossible in pure CSS. CSS itself offers no mechanism for encapsulation. Fortunately, our team has been using Sass to write our CSS for a while now, and Sass offers some important mechanisms that help us modularise our code. So what we decided to create is actually a Sass mixin library (like Bourbon for example) using the following mechanisms:
Default variables
Setting global variables is essential for the framework, so we can keep consistent settings (e.g. font colours, padding etc.). Variables can also be declared with the !default flag. This allows the framework’s settings to be overridden when extending the framework:
We’ve used this pattern in each of the Vanilla themes we’ve created.
Separating concerns into separate files
Sass’s @import feature allows us to encapsulate our code into files. This not only keeps our code tidier, but it means that anyone hoping to include some parts of our framework can choose which files they want:
Keeping everything in a mixin
When a Sass file is imported any loose CSS is compiled directly to the output. But anything declared inside a @mixin will not be output unless you call the mixin.
Therefore, we set a goal of ensuring that all parts of our library can be imported without any CSS being output, so that you can import the whole module but just choose what you want output into your compiled CSS:
Namespacing
To avoid conflicts with any local sass setup, we decided to namespace all our mixins with the vf- prefix – e.g. vf-grid or vf-header.
Overall structure
Using the aforementioned techniques, we created one base framework, Vanilla Framework, which contains (at the time of writing) 19 separate “modules” (vf-buttons, vf-grid etc.). You can see the latest release of the framework on the project’s homepage, and see the framework in action on the demo page.
The framework can be customised by overriding any of the global settings inside your local Sass, as described above.
We then extended this basic framework with three branded themes which we will use across our sites:
You can of course create your own themes by extending the framework in the same way.
NPM modules
To make it easy to include Vanilla Framework in our projects, we needed to pick a package manager to use for installing it and tracking versions. We experimented with Bower, but in the end we decided to use the Node package manager. So now anyone can install and use any of the following packages:
Hotlinks for compiled CSS
Although for in-depth usage of our framework we recommend that you install and extend it locally, we also provide hosted compiled CSS files, both minified and unminified, for the Vanilla framework itself and all Vanilla themes, which you can hotlink to if you like.
To find the links to the latest compiled CSS files, please visit the project homepage.
How to use the framework
The simplest way to use the framework is to hotlink to it. To do this, simply link to the latest version (minified or unminified) directly in your HTML:
However, if you want to take full advantage of the framework’s modular nature, you’ll probably want to install it directly in your project.
To do this, add the latest version of vanilla-framework to your project’s package.json as follows:
Then, after you’ve npm installed, include the framework from the node_modules folder:
The future
We will continue to develop Vanilla Framework, with version 0.1.0 just around the corner. You can track our progress over on the project homepage and on Github.
In the near future we’ll switch over ubuntu.com and canonical.com to using it, and when we do we’ll definitely blog about it.
