Hugo Giraudel is a front-end developer from France enjoying hacking around Sass just for the heck of it. He is the author of SassyLists, SassyJSON, SassyMatrix, SassyCast, SassySort and Browserhacks.

Hugo's articles

  1. Using Sass to Build Color Palettes

    The other day, UI developer Alexandre Broudin asked me how I would use Sass to build a variety of palettes similar to a given palette where only the base color would change. I love playing with colors in a programmatic way so I decided to give it a try.

    Let’s say you have a palette composed of 7 reddish colors. Maybe you’ve built the palette by hand in Photoshop or with Sass functions. The 4th (middle) color is the base color and there are three lighter tones of it and three darker ones.

    color palette

    Now you want a way to quickly produce a similar palette from another base color. Basically, you want to have another collection of colors where the difference in lightness and saturation between the base color and each color from the palette is the same. So if the difference between the lightest color and the base color is, let’s say, 28% lightness, you want the lightest color from all palettes to be 28% lighter than the base color of its own palette.

    If we’ve made the first palette by hand and don’t know the color manipulations needed to have each color from the palette from the base color, how could we make all palettes identical?

    Note: this article uses pieces of code from another article of mine I’ve published on The Sass Way.

    Building our Functions

    First, we need to initialize the default palette as a global variable.

  2. Semantic Versioning: Why You Should Be Using it

    Semantic Versioning (referred to, for short, as SemVer), is a versioning system that has been on the rise over the last few years. With new plugins, addons, extensions, and libraries being built every day, having a transversal way of versioning software development is a good thing to help us keep track of what’s going on.

    What is SemVer?

    SemVer is a 3-component system in the format of x.y.z where:

    • x stands for a major version
    • y stands for a minor version
    • z stands for a patch

    So you have: Major.Minor.Patch.

    How does SemVer work?

    SemVer relies on bumping the correct component up at the right time. Therefore, determining which type of version you should be releasing is simple.

    If you are mostly fixing bugs, then this would be categorized as a patch, in which case you should bump z.

    If you are implementing new features in a backward-compatible way, then you will bump y because this is what’s called a minor version.

    On the other hand, if you implement new stuff that is likely to break the existing API, you need to bump x because it is a major version.

    Why SemVer?

    Because it makes sense. If there is one thing I’ve learned, it’s that versioning without guidelines basically means nothing. Moving to 4.2? Okay, fine. Why? Why not 5? Why not 4.1.1? Why not 4.11? Why not 4.1.oh-snap-new-version?

  3. SassDoc: A Documentation Tool for Sass

    For a while now I have been using my own comment system to document my Sass functions and mixins. As of today, looks something like this:

    [code language="scss"]
    // Clamp `$value` between `$min` and `$max`.
    // @author Stan Angeloff
    // @param {Number} $value - value to clamp
    // @param {Number} $min (0) - minimal value
    // @param {Number} $max (1) - maximum value
    // @throws All arguments must be numbers for `clamp`.
    // @return {Number} - clamped number

    @function clamp($value, $min: 0, $max: 1) {
    @if type-of($value) != "number" or type-of($min) != "number" or type-of($max) != "number" {
    @warn "All arguments must be numbers for `clamp`.";
    @return null;

    @return if($value > $max, $max, if($value < $min, $min, $value));

    // @var {Bool} - Defines whether the library should support legacy browsers (e.g. IE8).
    $legacy-support: true !global;

    This syntax, while close to that of JSDoc, is quite personal. It not only helps me document my functions and mixins but also provides enough information to other developers using the code so they can understand what’s going on.

    When other developers saw these comments in my code, they thought I was using this syntax to generate documentation. So I thought: What a brilliant idea! Why not using these comments to build a whole documentation system? It sounds like a great project!

    Introducing SassDoc

    So I built SassDoc, distributed as an npm package.

    There are 2 ways to use SassDoc:

    1. Run it from your terminal on your Sass folder; or
    2. Use it in your JavaScript applications.

    In either case, you need to install it first:

  4. Tips to Help You Level Up Your Sass

    Writing code is hard. There are many things to be aware of, many pitfalls to avoid, and there’s always room for improvements. Using Sass makes writing CSS a little less hard. Unless you are doing it wrong, in which case it makes CSS even worse.

    To avoid that, I want to share a couple of tricks to help you write better Sass.

    Use index() Rather than Multiple Equal Assignments

    I love reviewing Sass code. I can spend hours digging into Sass code on GitHub repositories. Something I see quite often, especially in Sass frameworks, is the use of multiple equal assignments.

    Let’s say you want to check if a value is either auto, inherit, or default. The usual way of writing this is like this:

    [code language="css"]
    @if $value == "auto" or $value == "inherit" or $value == "default" {
    // Then do something

    While this does the job fine, not only is it ugly but it is also pretty long to write. What if we simply used the index() function instead? This function…

    Returns the position of a value within a list. If the value isn’t found, returns null instead.
    Sass reference

    Let’s update our example code with this shiny tool:

    [code language="css"]
    @if index("auto" "value" "default", $value) {
    // Then do something

    Some would argue that index() returns a number and not a Boolean, thus shouldn’t be used like this. This is really a matter of choice here. I think this is perfectly fine since we only want to make sure it doesn’t return null (which would be falsy) but if you really want to deal with a Boolean, you can still do:

  5. A Better Solution for Managing z-index with Sass

    Lately we have seen quite a few articles about managing z-index with Sass:

    While that last article from Chris Coyier certainly helped me get started with my solution, none of the previous articles succeeded, from a technical standpoint, in presenting a simple and easy to use method.

    Hence this article. I will walk you through my very simple system, showing you how I built it and how you can use it in your projects today.

    Why the Need to Manage z-index Values?

    First let’s answer this question: why do we need to manage z-index with Sass? We don’t see countless articles popping up about managing padding with Sass, right? So why do it for z-index?

    Well, it has to do with the fact that z-index is mostly misunderstood. Moreover, accepting a unitless value between -infinity and infinity gives you plenty of occasions to screw things up.

    So rather than using values like 9999999 and yelling at your screen because you don’t understand what’s going on, it may be interesting to use an extra tool — a CSS preprocessor in this case — to help improve things.

    What’s the Concept?

    The concept here is mostly the same in all articles on this topic: Build a function that accepts a keyword as an argument, which is mapped to a value. This value is the z-index that will be printed out.

    Jackie Balzer uses lists. Doug Avery uses a mix of lists and maps. Chris Coyier uses maps. Actually, Chris Coyier’s solution is really close to what I have ended up with, except it lacks this little extra that makes the whole system great to use.

    Ultimately we’ll come to this:

  6. Useful Compass Extensions That are Worth a Try

    Compass is a great Sass framework. Not only because it provides a hundred useful mixins and functions and a sprite builder, but also because it allows authors to build their own extensions, thus use other authors’ ones.

    A Compass extension is some kind of bundle packed as a gem, that can be installed, imported then used in your Sass stylesheets. Installing a Compass extension is a 3-step process:

    1. In your terminal, run gem install {extension_name},
    2. In your config.rb file (Compass), add require "{extension_name}",
    3. In your stylesheet(s), add @include "{extension_name}"

    The first step installs the gem on your machine. The second tells Compass to use the gem. The third imports the extension content so it can be used in your Sass files.

    Quite easy, isn’t it? Now that you know how to use them, what if I showed you a couple of Compass extensions that are definitely worth a try? Remember, all you have to do to try them is to run the 3 commands listed above. Also, most of these are included in the SassMeister playground so you can try them online as well.

    Modernizr Mixin

    Modernizr Mixin is a wrapper for Modernizr class API built by Daniel Guillan. This extension provides a clean API to ease and normalize the use of Modernizr’s classes in your stylesheets.

    Let’s say you build something that relies on both CSS transforms and opacity. You might write something like this in your stylesheet:

    [code language="css"]
    .csstransforms.opacity {
    .element {
    /* Do something if both CSS transfroms and opacity are supported */

    Or if you build it the other way around, providing a fallback if any of the two is not supported:

  7. Using Sass Maps

    The third major version of Sass brought a new data type called map. While you might be unfamiliar with this name, we already use maps often in other languages, usually under the names of associative arrays, or hashes. In other words, a Sass map is an array matching keys to values.

    It is not always clear why we need maps in CSS (yes, Sass is CSS), hence this article, to give you some hints. This list is obviously not exhaustive so feel free to find and share other use cases.

    Syntax for Sass Maps

    Before going any further, let’s level everyone up on the topic.

    A Sass map uses parentheses as external delimiters, colons to map keys and values, and commas to separate key/value pairs. Here is a valid Sass map:

    [code language="css"]
    $map: (
    key: value,
    other-key: other-value

    A few things you need to know:

    Yes, keys are not necessarily strings; they can be anything. Even null. Even maps. Chris Eppstein, Micah Godbolt, Jackie Balzer, and I had a conversation about this on Twitter a couple of weeks ago. Having kind of a JavaScript background, I don’t feel comfortable with having anything other than a string as a hash key. Anyway, that’s possible in Sass.

    Okay, now you should be ready to go!

    Project Configuration

    Let’s start with a common use case. Maps are perfect when it comes to project configuration. The idea is simple: You associate values to keys, then you access them from anywhere in the project using map-get($map, $key).

    I already dug into this in my article on managing responsive breakpoints in Sass. Here’s a quick example:

  8. Sass Frameworks: Compass or Bourbon?

    Once in a while, we see this question pop on Twitter, Reddit or StackOverflow. Pretty much anyone who has ever worked with Sass has at some point asked themselves which to choose: Compass or Bourbon?

    In case I’ve already lost some of you, Compass and Bourbon are frameworks for Sass. Sass, as you probably know, is a trendy CSS preprocessor, right? Okay. In the same way you put jQuery or Backbone or whatever over JavaScript, you can use a framework over Sass to help get things going.

    In today’s article, I’d like to give you my opinion on this topic. But first, let me introduce the topic with a little bit of history.


    Compass describes itself as a CSS authoring framework for Sass. It is maintained by Chris Eppstein, one of the two maintainers of Sass (the Ruby version). Compass is half Ruby and half Sass, and provides a boatload of mixins and a toolbox for Sass. More on this later.

    On the other side, Bourbon is built with Sass for Sass by the awesome team at Thoughtbot. According to the project’s home page, Bourbon is more like a library than a framework; a simple and lightweight mixin library for Sass.

    So on one hand we have a Ruby/Sass framework, and on the other hand we have a Sass library. Quite different perhaps?


    When you ask a Compass/Bourbon user what he uses the tool for, the chances are high he’ll tell you: cross-browser compatibility. Okay, maybe he won’t say it like this, but the idea is the same. Both Compass and Bourbon provide a huge collection of mixins to handle CSS3 features so you don’t have to deal with vendor prefixes or CSS hacks.

    [code language="css"]
    // Compass
    el {
    @include box-sizing(border-box);

    // Bourbon
    el {
    @include box-sizing(border-box);

    // Doh. Same API. Awesome!

    In fact, Compass and Bourbon use the same syntax for most mixins, making the switch from Compass to Bourbon or Bourbon to Compass quite easy.

    One important thing between both tools though: Starting with Compass 1.0 (released with Sass 3.3), Compass is directly pulling data from Can I Use…, which means it will (almost) always be up to date with vendor prefixes while Bourbon’s validity, as of this writing, depends on maintainers’ updates.

    Note: if you are using Autoprefixer to prefix your vendor properties, then this section won’t matter much to you.


    Both Compass and Bourbon provide some typography-related mixins, variables, and functions. Compass comes with a whole vertical rhythm module, including a lot of variables and a couple of mixins.

  9. Managing Responsive Breakpoints with Sass

    When dealing with responsive design, you often find yourself defining a lot of media queries, checking various properties, with various values. Because it can quickly get messy, it is usually considered a good practice to use Sass (or any other preprocessor, for that matter) to handle responsive breakpoints.

    That being said, it has occurred to me there are lots of different ways to deal with this, and people keep asking me which one is the best. As with everything in our field, there is no straight answer and quite often, it depends. More precisely, I have noticed that the difficulty is not coming up with a system; it is coming up with a system that is both flexible enough to cover most cases yet not too complicated, which would result in code bloat.

    In today’s article, I will walk you through a couple of ways to use Sass in order to manage responsive breakpoints. All are perfectly valid, but some are obviously better than others. That being said, I’ll let you make up your own opinion on this topic.

    With variables

    First, there is the way used by both Bootstrap and Foundation, which consists of defining variables, then using them in @media directives. In other words, you will have a configuration file somewhere containing a shitload of variables ready to be used as-is.

    Here is how Bootstrap does it:

    [code language="css"]
    // Defining values
    $screen-sm-min: 768px;
    $screen-xs-max: ($screen-sm-min - 1);
    $screen-md-min: 992px;
    $screen-sm-max: ($screen-md-min - 1);
    $screen-lg-min: 1200px;
    $screen-md-max: ($screen-lg-min - 1);

    // Usage
    @media (max-width: $screen-xs-max) { ... }
    @media (min-width: $screen-sm-min) { ... }
    @media (max-width: $screen-sm-max) { ... }
    @media (min-width: $screen-md-min) { ... }
    @media (max-width: $screen-md-max) { ... }
    @media (min-width: $screen-lg-min) { ... }

    Foundation goes one step further, getting rid of the need of typing min-width and max-width by dealing with stringified media queries all together rather than pixel values.

    [code language="css"]
    // Defining values
    $small-range: (0em, 40em); /* 0, 640px */
    $medium-range: (40.063em, 64em); /* 641px, 1024px */
    $large-range: (64.063em, 90em); /* 1025px, 1440px */
    $xlarge-range: (90.063em, 120em); /* 1441px, 1920px */
    $xxlarge-range: (120.063em); /* 1921px */

    // Defining media queries
    $screen: "only screen" !default;
    $landscape: "#{$screen} and (orientation: landscape)" !default;
    $portrait: "#{$screen} and (orientation: portrait)" !default;
    $small-up: $screen !default;
    $small-only: "#{$screen} and (max-width: #{upper-bound($small-range)})" !default;
    $medium-up: "#{$screen} and (min-width:#{lower-bound($medium-range)})" !default;
    $medium-only: "#{$screen} and (min-width:#{lower-bound($medium-range)}) and (max-width:#{upper-bound($medium-range)})" !default;
    $large-up: "#{$screen} and (min-width:#{lower-bound($large-range)})" !default;
    $large-only: "#{$screen} and (min-width:#{lower-bound($large-range)}) and (max-width:#{upper-bound($large-range)})" !default;
    $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})" !default;
    $xlarge-only: "#{$screen} and (min-width:#{lower-bound($xlarge-range)}) and (max-width:#{upper-bound($xlarge-range)})" !default;
    $xxlarge-up: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)})" !default;
    $xxlarge-only: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)}) and (max-width:#{upper-bound($xxlarge-range)})" !default;

    // Usage
    @media #{$small-up} { ... }
    @media #{$small-only} { ... }
    @media #{$medium-up} { ... }
    @media #{$medium-only} { ... }
    @media #{$large-up} { ... }
    @media #{$large-only} { ... }
    @media #{$xlarge-up} { ... }
    @media #{$xlarge-only} { ... }
    @media #{$xxlarge-up} { ... }
    @media #{$xxlarge-only} { ... }


    There is one thing I don’t like with each method: in Bootstrap’s, I have to type (min-width: ...) every time. In Foundation’s, I need to interpolate a variable which is both ugly and annoying to do. Surely we could come up with a way to fix both flaws.

  10. A Sass Mixin for CSS Triangles

    There is a very popular CSS trick consisting on using a mix of solid and transparent borders on a 0 width, 0 height element in order to fake a triangle. If you don’t know technique yet, you can find more information about it in the following articles:

    While it comes with some quirks, it actually does the job well and has the benefit of being very compatible across the wide range of browsers we have to support.

    Now the thing is, I never completely remember how to use this little piece of code. Which borders need to be transparent? Which one should be solid? I just can’t figure this out and I bet it’s the same for many of you as well. So this is typically the kind of thing you would like to automate using Sass.

    There are probably as many CSS triangle Sass mixins as there are Sass developers. What if I showed you my own mixin to deal with CSS triangles/arrows in CSS?

    What Do We Need?

    Before digging into the code, it would be a good idea to check what we need in order to make a triangle out of CSS. First: a direction. We need to define a direction for our arrow, either top, right, bottom, or left. Also, what about a position? Like at 1.5em from the top, 100% from the left, for instance. Also we could define a color, and perhaps a size as well, although those 2 arguments could have defaults.

    So in the end, our mixin is a short way for us to say Generate a triangle pointing to this direction, at this spot, in this color, and in the following dimensions. Sounds good, right?

    Note that in order to avoid using extra markup, I like to use pseudo-elements for triangles. For instance:

    [code language="css"]
    .element {
    /* Container of some kind */

    &::before {
    /* Including triangle mixin */

    Using Our Toolbox

    Last week, I wrote about some functions and mixins to kickstart your project. In case you haven’t read that article yet, go ahead. I’ll wait.

    Okay, done? What if we reused some of our mixins in order to make this triangle mixin as sharp and clean as possible? For instance, we could use the size() mixin so we don’t have to define both the width and the height. We could also keep a consistent API for positioning stuff and make use of the absolute() mixin (more about that mixin here).