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. Building a Step Wizard with BEM and Sass

    A step wizard is a user interface component that helps a site’s visitor know what’s going on during a multiple-steps action. For instance, an online purchase. It is commonly used on payment forms describing the different steps to complete the desired action, as well as the current step.

    I think it’s a good UI component as not only does it help in figuring how long an action could take, it also provides some context: what have I done so far? What’s left to do? Can I go back? Can I skip this step?

    This article is not about the pros and cons of such a pattern. Nope. Today, I wanted to show how to build such a component with CSS, making sure to cover a lot of things. Including:

    • The dynamic numbering of steps;
    • A mobile-friendly view;
    • Visually define the current step, completed steps and steps left to do;
    • Use semantic markup;
    • A fallback for old browsers;
    • Create easily maintainable styles.

    Step Wizard

    The markup

    I think that the markup for a step-wizard should be an ordered list. Since steps are advancing one after another, the order matters. Hence, an ordered list (<ol>). Each item should be a list item (<li>), containing a link (<a>) or an anonymous element (<span>) if there is no link. That’s it.

    [code language="html"]

    1. Cart
    2. Authentication
    3. Delivery
    4. Summary
    5. Payment

    [/code]

    Step Wizard 2

    Regarding naming, I went with something BEM-like (Block Element Modifier) since this is a perfect fit for such a methodology. If you are not familiar with BEM, I suggest you read this article introduction by (who else) Harry Roberts.

    Using BEM we would have the class attributes:

    • steps as the block;
    • steps__item for individual steps;
      • steps__item--done for a completed step;
      • steps__item--current for current step;
      • steps__item--first for first step (not mandatory with :first-of-type);
      • steps__item--last for last step (not mandatory with :last-of-type);
    • steps__link for either links or spans.

    Also, we will add a disabled class attribute to items coming after the current step.

    Let’s add those class attributes to our previous markup, considering the 3rd step is the current one (for demo purpose):

  2. Beware of Selector Nesting in Sass

    A couple of days ago, I tweeted about how I thought selector nesting actually caused more problems than it solved.

    Some people agreed, some did not. In any case, it raised a couple of interesting thoughts so I thought I would put together an article to talk about the topic.

    What is selector nesting?

    Selector nesting is a feature of CSS preprocessors, allowing authors to nest selectors within selectors in order to create shortcuts. For instance:

    [code language="sass"]
    .parent {
    color: red;

    .child {
    color: blue;
    }
    }
    [/code]

    Which would compile to the following CSS:

    [code language="css"]
    .parent {
    color: red;
    }

    .parent .child {
    color: blue;
    }
    [/code]

    In this example, .child is nested within .parent in order to avoid repeating the parent selector.

    While this can be quite useful, I feel like this feature is being largely overused to the extent that we now try to solve issues we inflicted ourselves while nesting too much.

    What’s wrong with nesting?

    In itself, there’s absolutely nothing wrong with nesting. The feature makes sense. The problem, as is often the case, is not the feature but how we use it. Allow me to start with a couple of examples I stumbled upon.

    There is this one from Micah Godbolt:

  3. A Bulletproof Function to Validate Length Values in Sass

    Once you start getting comfortable with Sass, playing with some functions and writing your own mixins, soon enough you will want to validate developer input. This means adding some extra checks to your functions and mixins to make sure the given arguments are correct in terms of how they are going to be used within the function or mixin.

    After having seen a dozen different functions supposedly aimed at validating a length, I thought I would give it a try and write something on it. So here we are.

    Let’s first recall what a length is according to official CSS specifications:

    Lengths refer to distance measurements […] A length is a dimension. However, for zero lengths the unit identifier is optional (i.e. can be syntactically represented as the ‘0’). A dimension is a number immediately followed by a unit identifier.

    If we sum up what we just read, a length is a number followed by a unit, unless it’s zero. It’s a bit simplistic but we’ll start with that.

    Setting Up the Function

    If a function returns a Boolean, it is usually good practice to name the function with a leading is-. By the very nature of the question is [this] [that]?, we imply that the answer is either yes (true) or no (false).

    In our case, we want to make sure the given value is a length, so I suggest is-length, in all its simplicity.

    [code language="sass"]
    /**
    * Check whether `$value` is a valid length.
    * @param {*} $value - Value to validate.
    * @return {Bool}
    */
    @function is-length($value) {
    // Do some magic and return a Boolean.
    }
    [/code]

    Returning a Valid Value

    Thanks to our refresher we know that a length is a number with a unit. Let’s start with that.

  4. Sass 3.4 is Out!

    Only a couple of months after Sass 3.3, version 3.4 has already shipped under the code name “Selective Steve”. Quite an odd name but we’ll see that the name is pretty accurate since most new features are about selectors.

    The Parent selector & in SassScript

    “In SassScrwhat?” you ask. You can think of SassScript as the language of Sass. Sass is the eco-system, the preprocessor, while SassScript is what makes Sass, well… Sass, under the hood. Or as Natalie Weizenbaum puts it:

    “SassScript” is what we call the mini-language Sass uses for variables, property values, and so forth. It’s mostly just CSS values, but it also supports custom functions, arithmetic, and so forth.

    Before Sass 3.4, you couldn’t do much with the parent selector (although I hate this name since it’s not a parent selector but a reference to the current selector, which is utterly different but whatever), except things like:

    [code language="sass"]
    .selector {
    .no-svg & {
    // Stuff
    }

    &:hover {
    // (H)o(v|th)er stuff (see what I did there?)
    }
    }
    [/code]

    Well, now we can do much more. At first, this new feature was supposed to come with Sass 3.3 but it got delayed because of technical issues.

    Basically, you can now manipulate & as you can any other variable. It always contains a list of lists, as you would expect it to.

    For instance, if you have a selector like .foo .bar, .baz, then the upper list for & would contain 2 items: .foo .bar and .baz, both of them being lists. Then, the first contains 2 items as well (.foo and .bar), while the second only contains one (.baz).

    Beware, the SassScript representation of a selector made of a single part is still a 2-level deep list. For instance .item would be ((item,),). So if you want to grab .item from &, you’d have to run nth(nth(&, 1), 1) (first item of the first item of &).

    Okay so it’s probably not quite obvious why we would need something like this. Admittedly, while it’s true we’ve been doing without this for a while now, there is one specific thing — which happens quite frequently actually — that we couldn’t do until now:

  5. Keep Sass Simple

    In a couple of months, it will be 2 years since I started using Sass. Almost every day. At work. At home. On side projects. To the point where people ask for my help when it comes to Sass, and believe me I am very glad to provide help whenever I can.

    Some requests are fair. Some are dead-simple but hey, we all started somewhere. And some are just insane. Look, I don’t judge; at some point every single person using Sass (or any other preprocessor for that matter) has been tempted to over-engineer something to make things simple™. Me included, and more than once.

    Let’s Optimise!

    The other day, I was asked how to do this:

    [code language="sass"]
    .class {
    width: 20px;
    }

    .other-class {
    width: em(.class:width);
    }
    [/code]

    Basically, convert .class width to em then use it as the width of .other-class. Think about that for a second. Not only is px to em very difficult to achieve due to the lack of context in Sass, but now it is about referencing the value from the property of a selector as the value to a property from another selector. Nope.

    Nope bear

    Even Stylus — which is well known for being quite advanced — can’t do that. At best, it can refer to the value of the property in the same code block (known as property lookup). Obviously Sass — being much more conservative — can’t do that either.

    But the problem is not about having the ability to do something like this. The problem is about wanting to do something like this. This should not happen. Ever. If you come up with a case where you need this, you’re obviously doing something wrong.

    Note: if you ever wanted to do something like this, don’t feel ashamed or offended. This is just one example among many.

    Because We Can

    Okay, let’s agree on the fact that the above request is indeed a wrong way of using Sass. Do you want a more controversial example? The Sass 3.4 changelog recently got featured everywhere, promoting the incoming selector functions. Those features are meant to be able to manipulate selectors like lists, with functions like selector-nest(), selector-replace(), and so on.

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

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

  8. 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;
    [/code]

    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:

  9. 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
    }
    [/code]

    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
    }
    [/code]

    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:

  10. 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: