Rethinking Your Sass Variables26 February 2015
Using variables in Sass or any other preprocessor makes it easier to populate your stylesheets easily without having to remember the exact hexadecimal code for the Facebook blue 261 times.
As well as making it easier on the developer to use something like
$brand-color--primary instead of
#D37E4A using a variable means if you need to change the shade of your clients main brand colour by a smidgen across the site, it's relatively easy to do so.
This is all good, but can we take our variables partial too far. Listening to an episode of The ShopTalk Show where Chris and Dave talk to Mark Otto, amongst other things, about Bootstrap. At some point Mark mentions that the variable partial in the UI library has around 860 lines and that navigating it can be a bit laborious because it's so long.
My, pretty basic, Sass variable partial is only 80 lines or so. Not huge by any means but they're still all in one place.
It's probably re-inventing the wheel a little as there's already projects like Bootstrap,, Foundation, Refills that include ready made components and patterns to use but as I've previously mentioned I'd "be happy in the knowledge of what every line of code I produce is doing"" and the idea of patterns is that I only really have to do the main bulk of the coding once.
Base and Component Variables
After reading Hugo's article on Breakpoints and Tweakpoints in Sass on SitePoint where he shows a really neat idea in creating a CSS Media Queries mixin to allow for 'global' breakpoints that are more suited to overall layout decisions and component based breakpoints, 'tweakpoints' for "polishing the look and feel of the page"".
I've been thinking this would work really well for other variables too. To have a (small) list of variables for site wide values like font families, colours, gutters, and so on which can either be called into a component with it's own variables which would then allow those component variables to be overridden.
For example, we would have a main variables file:
// Default Variables // -------------------- $brand-color--primary: #C69; $brand-color--secondary: #699; $brand-color--tertiary: #F2ECE4; ...
And then we would have a component variables file. Something like:
// Tabs Pattern // ------------------- $tabs-navigation-border-color: $brand-color--secondary; $tabs-navigation-text-color: $brand-color--tertiary; $tabs-main-background-color: $white; ...
Here we would have the various variables relating to the pattern named to match the pattern. This can take in variables from our global file
brand-color--tertiary for example. It also gives you the option to override and replace the global variable with whatever is required.
Nothing Is New
Having decided upon creating 'component' and 'global' variables over the last couple of weeks I often felt that this idea cannot be new. There must be another front-end developer, agency, or software company that has been 'rolling their Sass' like this for quite a while.
After a quick tweet to Mark last night consultant front-end architect Harry Roberts replied saying that this is an idea he has been employing in Inuit for a while now.
You could argue that this just takes things a little too far, but I think it makes sense. Rather than going through a document of 800 or so variables to see the
$jumbotron-border-color is the same as the
$brand-color--primary at the top of that file seems a little laborious and having the variable for a 'Jumbotron' component within the rest of the CSS makes it much to check and to edit if need be.
Turn And Face The Change
There's a chance I might change my mind on this. The underlying idea around patterns is for me to have some 'go to' code for client projects so that I don't have to reinvent my wheel on each project.