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. 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).

  2. Sass Mixins to Kickstart Your Project

    Mixins are great, aren’t they? They are like functions that output CSS. According to the Sass docs:

    Mixins allow you to define styles that can be re-used throughout the stylesheet without needing to resort to non-semantic classes like .float-left. Mixins can also contain full CSS rules, and anything else allowed elsewhere in a Sass document. They can even take arguments which allows you to produce a wide variety of styles with very few mixins.

    Mixins are really convenient, especially when working on a large project. How many times have you had to define width and height values in your last project? How many times have you Googled how to do a triangle in CSS? Or haven’t you ever wished there was a shorthand for top, right, bottom, left when using CSS positioning?

    You can solve all those problems with mixins. Even better: you won’t have to write them since I’ve already done that for you. Here we go guys, a couple of Sass mixins to kickstart your projects!


    I bet you already know this one. I use it as a mixin 101 in all my projects: a size() mixin defining both the width and the height. First argument is the width, second one is the height. If height is omitted, it falls back to the width value.

    @mixin size($width, $height: $width) {
          width: $width;
          height: $height;

    Simple enough.

    Example Usage


    .element {
      @include size(100%);
    .other-element {
      @include size(100%, 1px);

    CSS output:

    .element {
      width: 100%;
      height: 100%;
    .other-element {
      width: 100%;
      height: 1px;


    If there is one shorthand I really think CSS misses, it’s a shortcut for offsets: top, right, bottom and left. We have shorthands for everything: padding, margin, background, even text-decoration! But we still don’t have one for offsets… So I built my own.

  3. What’s the Difference Between Sass and SCSS?

    I’ve written a lot lately on Sass, but some recent comments made it clear that not everyone knows exactly what Sass refers to. Here's a bit of clarity:

    When we talk about Sass, we usually refer to the preprocessor and the language as a whole. We'll say, for example, "we are using Sass", or "here is a Sass mixin". Meanwhile, Sass (the preprocessor) allows two different syntaxes:

    • Sass, also known as the indented syntax
    • SCSS, a CSS-like syntax


    Initially, Sass was part of another preprocessor called Haml, designed and written by Ruby developers. Because of that, Sass stylesheets were using a Ruby-like syntax with no braces, no semi-colons and a strict indentation, like this:

    // Variable
    !primary-color= hotpink
    // Mixin
        -webkit-border-radius= !radius
        -moz-border-radius= !radius
        border-radius= !radius
        color= !primary-color
        width= 100%
        overflow= hidden

    As you can see, this is quite a change compared to regular CSS! Even if you're a Sass (the preprocessor) user, you can see this is pretty different from what we are used to. The variable sign is ! and not $, the assignment sign is = and not :. Pretty weird.

    But that's how Sass looked like until version 3.0 arrived in May 2010, introducing a whole new syntax called SCSS for Sassy CSS. This syntax aimed at closing the gap between Sass and CSS by bringing a CSS-friendly syntax.

    // Variable
    $primary-color: hotpink;
    // Mixin
    @mixin border-radius($radius) {
        -webkit-border-radius: $radius;
        -moz-border-radius: $radius;
        border-radius: $radius;
    .my-element {
        color: $primary-color;
        width: 100%;
        overflow: hidden;
    .my-other-element {
        @include border-radius(5px);

    SCSS is definitely closer to CSS than Sass. That being said, Sass maintainers have also worked to make both syntaxes closer to each other by moving ! (variable sign) and = (assignment sign) from the indented syntax to $ and : from SCSS.

    Now, when starting a new project, you may wonder which syntax you should use. Let me enlighten the path and explain the pros and cons of each syntax.

  4. My Favorite Sass Tools

    Sass was introduced about 7 years ago as a workaround for CSS flaws and has come a long way since then. It has played a major role in popularizing CSS preprocessing, to the point where the question is no longer if you should use a preprocessor, but which one you should use. It turns out, the answer to that question is very often Sass — because the syntax is better (and closer to CSS), because it’s permissive, and because it can do a lot of stuff and works well.

    Since being introduced, Sass has become arguably the most important CSS preprocessor available today. It has a whole ecosystem growing around it (starting with Compass) — Playgrounds, applications, grid systems, libraries, and so on… But it’s not always that easy to dig up interesting stuff about Sass. The more there is, the more you have to look in order to find the thing you want.

    Hence this blog post. What if I tried to enlighten the path by showing you what I think are the most valuable Sass tools? Sounds cool right? Let’s go.


    Getting started with Sass is not easy. Mostly because it is written in Ruby. And while Ruby is a popular language, front-end developers usually do not know Ruby. This is the main thing that leads beginners to use LESS or Stylus, which are written in JavaScript (Node, actually). People usually don’t want to add Ruby to their stack just to see what Sass is worth.

    Fortunately, you can try Sass online. There are playgrounds, or online tools, that allow you to write Sass and see the compiled CSS and (sometimes) the way the code will render. As of writing this, there are two major playgrounds to play with Sass:


    CodePen, by Chris Coyier, Alex Vasquez, and Tim Sabat, is by far the best playground you can use. It offers everything you need and beyond for front-end testing. Regarding Sass, it supports the stable version (version 3.3.4 as of writing) and you can use either the old indented syntax or the SCSS one.


    You can also pick between Compass and Bourbon (or none). It also shows you syntax errors. It’s really awesome so if you don’t know about it yet, have a tour and give the Sass features a try.


    SassMeister, by Jed Foster, is a playground that specializes only in Sass-related stuff. Obviously then, it does the job better than CodePen. You can use either stable, or Sass 3.2.14, or even LibSass, the C port of Sass (still running on Sass 3.1.x as of this writing).


    Of course, SassMeister lets you choose the syntax you feel more comfortable with and you even can choose the output style (expanded, compressed, and so on). Most importantly, because SassMeister is specific to Sass, it allows you to import Sass libraries (Compass extensions actually). You can even propose your own extensions if you think they should be added.

  5. Caching Values from Sass Mixins

    Let’s back up a little bit so I can explain the context of this post. In recent weeks I have been actively comparing rendering output between mixins and placeholders. As a result, the more I think about it, the more I believe using mixins and placeholders as they are described in the Sass docs is simply not enough.

    Let’s focus on the main goal here: CSS output. In this whole experiment, I am not considering code complexity or code quality. I’m only considering final CSS output. The point is to have CSS output that is as light and lean as possible.

    If you’ve read my previous SitePoint articles covering placeholders vs mixins and @extend directives, you would be aware that there are a couple of drawbacks with both features. Mixins do not merge selectors while @extend directives are restricted to their scope, hence they are basically unusable in a responsive context with @media blocks (which I tackled and partially solved in my article on cross-scope @extend).

    Today, I would like to deal with another issue: Mixin grouping.

    What is Mixin Grouping?

    Mixins are really handy when you want to create shortcuts in your variable code. For instance, you could have a mixin accepting two arguments to output both width and height. Or a mixin for offset positioning. That’s nice.

    The problem with mixins is every time you call them, they dump CSS rule sets. If you call them twice with the same arguments from 2 different selectors, they won’t be merged into a single rule set. Instead, they will dump the same rule set twice — which kind of sucks.

    For this article, we’ll deal with a very simple use case: A size mixin to assign width and height. Here is what it looks like:

  6. Cross-Media Query @extend Directives in Sass

    If you read my previous article on Sass’s @extend directive or if you have pretty solid knowledge about the way Sass works, you may be aware that you cannot do this:

    [code language="css"]
    %example {
    color: blue;
    font-weight: bold;
    font-size: 2em;

    @media (max-width: 800px) {
    .generic-class {
    @extend %example;

    What’s happening here is we’re trying to extend a placeholder inside a media query from another scope (in this case, the root). It just doesn’t work, and if you try it you’ll get the following error message:

    You may not @extend an outer selector from within @media.
    You may only @extend selectors within the same directive.

  7. A Creative Grid System With Sass and calc()

    Before we even get started talking about Sass and the code for this project, let me remind you this is no more than a quick experiment which by no means should be used in a live context. So what follows is only a proof of concept of what we could do with a couple of Sass variables and the calc() function from CSS.

    There are probably still quite a couple of flaws and edge cases that are not handled in this example. If you have any recommendations for improving this, be sure to share. Otherwise keep in mind it’s just an experiment.

    What Are We Trying to Do?

    In the last couple of days I have been working with the calc() function in CSS. calc() can be a blessing when it comes to cross-unit calculations, and gets even better when you have a couple of Sass variables to make everything easily customizable.

  8. Creating a Rainbow Border with Sass

    p>A lot of modern designs are making good use of a multi-colored border effect (which we might also refer to as a “rainbow” border or “striped” border). For example, look at Treehouse’s blog – it has a multi-colored border under its navigation and it looks really nice.

    Treehouse's colored border

    However, in my opinion, Treehouse is coding it wrong. Since this is strictly concerned with aesthetics, it should be handled by CSS – and CSS only – without requiring any extra work in the HTML. Treehouse uses 50 span elements, each of them with a specific background color and a specific size, to create its nav border.


    It’s overkill to dump such a large load of elements into the DOM just so you can create a striped border. Why not use CSS for this? I mean only CSS. Gradients are awesome for this type of task! Yes, you can create multiple colors in this manner using CSS gradients, and it’s quite easy to do.

    The only caveat is that gradients are kind of a pain to write. They have a tedious syntax that is very likely to result in mistyping and errors. Plus having to repeat color stops in order to achieve multiple colors is annoying.

  9. My Current CSS and Sass Styleguide

    It’s never easy to find a way to write consistent, future-proof, and robust CSS. It’s taken me months, if not years, to come up with a clean way to write mine. In fact, my process is still evolving, and I expect it to change even more.

    In the meantime I have accumulated enough knowledge to write an article about how I feel about writing CSS. I don’t claim that these suggestions are for everyone, and they’re certainly not perfect. But I thought it would be nice to put these into an article to share them with the community.

    Naming conventions

    Naming conventions are a team decision. If, like me, you are dealing with your CSS on your own, you can go nuts and use something that suits you. Personally, I go with Nicolas Gallagher’s methodology which is influenced by the well-known Yandex BEM system.

  10. Dealing with Color Schemes in Sass

    A lot of sites have a specific color scheme for every section. Even this very site you are reading does this – you are in the blue section AKA CSS. This is a clever design trend to create clear distinctions between various parts of the same entity.

    But on the technical side, this can be a pain to work with. Not because it is overly complicated – more because it involves a lot of annoying repetition.

    Unless, that is, you automate the process with — let’s say — Sass. Then you have something really easy to work with. Since I have had to do this more than once, I’ll show you how I handle the situation.