At Subtrakt we build websites that intentionally make it super easy for a client to create their own content using our excellent page builder Construkt.
Construkt is an extension of the Advanced Custom Fields‘ flexible content builder with our own twist, and means that content pages don’t need to follow a rigid template, but that each section of the page can be split into smaller sections tailored to the content.
The result of this from a front-end development point of view is that we need our code to be flexible and easy to manage. Sass variables play a big part in this, making sure we only write code once from multiple potential outcomes.
The basics – setting a primary colour
At it’s very most basic, a Sass variable can be used to store values that are repeated throughout the site that in CSS a change to one would mean a find and replace to all. An example here would be setting a primary brand colour. Let’s say when you start the project a client’s primary colour is rich red with the value hex of #bf1818. In standard CSS that colour will be listed in various ways, e.g.
What if, midway through the process, the client decides that the red is too rich and they want to go for something a bit softer – say #e94c45? You’re going to have to find and replace all those instances of #bf1818. Sass can reduce your work to a one line change by setting a variable to the primary brand colour with a value of $primary.
Now you can repeat the variable every time you want to call on the colour, and only need to change it in one place to change it in multiple files.
Important note: For variables to be accessible they need to appear ahead of any code using them. Always a classic blunder to call a variable in a file that loads ahead of where the variable is stored, leading to errors.
Global variables – handy values that help with consistency
Using variables in Sass gives you the opportunity to take common values and repeat them throughout the site, improving consistency and reducing workload.
This is a common element that will typically appear (or not appear) across every button, box, container and element across the site depending on your design. In CSS we’d have to define that value in every instance – what if we decide that we’d made our buttons too round or want to reduce the harshness of the edges at a later date. With a $border-radius variable we can set this up at the start of the project so that there’s one master to rule them all.
Sass variables can be used to set global breakpoints for the site – typically these values carry through from project to project however depending on the design you might want to tweak the values or add some custom ones. We us these in conjunction with mixins to set media queries on a per-object basis.
A simple but effective one, if you have a fixed header and a bunch of elements that have to rely on knowing the header height (e.g. a site wrap with a margin-top, or a sticky element) you can set a global variable that controls the height – that way if you ever make the logo smaller or add in a sub nav you can just change the variable and hey preto your other elements shift accordingly. Combine this with a some responsive breakpoints and you’re covered at different screen sizes:
Next steps for improving workflow
Once these top level global elements have been implemented you should start to find it much easier to keep a handle on elements that have common values and it’ll speed up the process both in terms of creation of elements and editing further down the line. If you find yourself repeating attributes for multiple elements throughout the site its likely the value is a good candidate for a variable.
In a future post we’ll look at how we take these principles for variables and apply them to arrays allowing you to create colour maps that streamline your workflow even further.