In the past I have talked about my latest work in the lab: creating an integration between and ZURB Foundation. I have also talked about the benefits you can gain by using such a system. Yesterday I shared a video where I walk you through the actual process to create color design tokens in

Today, I will get more technical about how that integration works. Ok, engineer hat on.

Here I have modified the basic ZURB Foundation template. This same technique will work with Bootstrap or any other gulp + sass based build.

The first thing you will want to do is to add a few more features to Gulp.

Here I have added gulp-clean, gulp-download, and gulp-rename.

See highlighted code on GitHub

After making those changes you will need to run npm install to install the proper modules.

Next we need to change the standard ZURB Foundation gulpfile.js. This is behind the scenes of what happens when you run gulp from the command line.

  1. Add variables to access the new gulp modules we added.
    View change on GitHub
  2. Add a set of variables to hold the url, filename, key etc.
    View change on GitHub
  3. Create a download task. This downloads a copy of the generated scss file from
    View change on GitHub
  4. Create a rename task. This is to remove the ?key= hash added to the end of the url. Note the dependency of the [‘download’] task. This overrides the parallel nature of gulp and forces the tasks to run in a step-by-step fashion.
    View change on GitHub
  5. Create a clean task. Since the rename is more of a copy, we want to remove the filename with the hash.
    View change on GitHub
  6. Change the default gulp task to include the tasks above.
    View change on GitHub

Now, it is a good idea not to check in files that are part of the automated build process, so you should add our new ~/scss/brand-ai directory to the .gitignore file.

So, we have updated our build system and every time we run gulp from the command line, it will connect to and download the latest copy of our generated scss file and save it with a consistent filename and location. ~/scss/brand-ai/_style-params.scss

But, we have one more step before we can use it.

We have to add an import to our Sass build so we have access to these new Sass variables.

This is a single line change and I added the following line to the top of the ~/scss/app.scss file

@import “brand-ai/_style-params.scss”;

Also important to note is the change that I made on line 6. Rather than importing the default _settings.scss (ZURB Foundation’s set of user configurable Sass variables) I make a duplicate copy of that file and call it _brand-settings.scss.

I do this for several reasons, but because I have been using ZURB Foundation since version 3, I don’t want to introduce breaking changes into a project. I can easily run a diff against my original settings.scss file. I can also run it against an updated version of that to see what has changed. From time to time the variable names can change in ZURB Foundation and this gives you some extra protection from introducing breaking changes as you upgrade to the latest version.

So at this point we have everything automated and ready for us to roll out into the ZURB Foundation framework.

What follows is just a proof of concept for this idea. Take a look at lines 53 – 65 in the ~/scss/_brand-settings.scss file to get an idea of how this is working.

// from brand-ai
$foundation-palette: (change<br/>  primary: $color-brand-primary,
secondary: $color-brand-secondary,
emphasis: $color-brand-emphasis,
success: #3adb76,
warning: #ffae00,
alert: #cc4b37,
$anchor-color: $color-link-color;
$body-font-color: $color-text-normal;
$body-font-family: $font-paragraph-font-family;
// end brand-ai

If you remember the video example from yesterday, you will notice that these are the exact Sass variables that are being created by Although this seems like a lot of work, the benefits are huge.

First off, you might think, well I could have done the same thing just by using some Sass variables. In fact, I have been doing this exact thing for years. But there are several reasons it falls short.

  1. It is a developer (and perhaps design systems engineer) only friendly format. For designers and others on the project, not so much.
  2. A knowledge of the command line is needed: gulp, sass and others just to create simple changes.
  3. Merging a feature branch or a pull request is required.
  4. It is not possible to use these colors via JavaScript, and increasingly difficult situation with the popularity of frameworks like React, Angular and Ember. It is also important for popular libraries such as D3 and Snap.SVG that generate dynamic and interactive graphics on the fly.
  5. You cannot use the colors to coordinate with an iOS or Android app.
  6. Not future proof. Much as #4 and #5 is an issue. You are locked into Sass technology. What if you want to use Less or Stylus? Or desktop apps. Or a new technology that doesn’t exist yet.

These are just six issues with using hard coded sass values. As your project team expands into new platforms or expands into a larger product line, it becomes much more difficult to maintain.

Now, this email is long and you might wonder what is a good way to get started. The absolute fastest way to experiment with this is to create a free account and download a copy of my entire repo.

If you are looking for someone to get you up and running with a system like this fast that’s something I can help with.