<![CDATA[ Sass - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ Sass - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Mon, 25 May 2026 22:38:27 +0000 60 <![CDATA[ How to Customize Bootstrap with Sass ]]> https://www.freecodecamp.org/news/how-to-customize-bootstrap-with-sass/ 66d461734bc8f441cb6df831 Tue, 21 Jun 2022 20:59:02 +0000 Bootstrap is an awesome CSS framework that can help you create stylish and sleek websites.

Some developers and teams find that code written in Bootstrap is easier to maintain than regular CSS, so they prefer Bootstrap to vanilla CSS.

But if everyone used Bootstrap with its default styles, then every site would look the same – and quickly, the internet would become pretty bland. Fortunately, Bootstrap is also highly customizable.

How to Customize Bootstrap

If you're a beginner, you can customize Bootstrap with a custom CSS stylesheet. CSS specificity is important here. You write custom CSS, with the same or higher specificity, and link to it in the head section of your index.html after the line which links to the original Bootstrap CSS.

<!-- index.html -->
<head>

    <link rel="stylesheet" href="./node_modules/bootstrap/dist/css/bootstrap.min.css">
    <!-- custom CSS should come after Bootstrap CSS -->
    <link rel="stylesheet" href="./custom.css"

</head>

For small tweaks this is OK. But for larger projects, this can be time-consuming and there may be a lot of redundant style declarations. So there has to be another, cleaner, way.

How to Use Sass with Bootstrap

The solution is to use Sass – a CSS preprocessor. Sass is compiled down to CSS before it's used on web pages.

Until Bootstrap version 3.x, you had a choice between CSS preprocessors: Less or Sass. But since version 4, Bootstrap uses only Sass. The source code for the Bootstrap 4 and 5 frameworks is written entirely in Sass, which is a testimony to how mature Sass has become.

You may have heard the tagline, "Sass is CSS with superpowers". If you want to learn Sass, the official website is an excellent resource. You can also refer to other tutorials on freeCodeCamp, like this one on how to use Sass with CSS, or this video course on how to use Sass with Bootstrap 5.

Sass comes with two syntaxes. The older one uses indentation and the newer SCSS syntax (SCSS for Sassy CSS) uses CSS-like curly braces.

SCSS is a superset of CSS. So CSS code saved with a .scss extension (or SCSS interspersed with CSS) is also valid Sass code.

In this tutorial, we are going to use the SCSS version. Whatever the style is, indented Sass or CSS-like SCSS, the Sass compiler will transpile it to vanilla CSS to be used on the browser.

What we are going to do in this tutorial

  1. We will change the primary and secondary theme colors Bootstrap ships with.

  2. We will also change the default media breakpoints Bootstrap uses.

Once we can do these, it will become easy to do other customizations.

The Prerequisites

  1. Node.js with npm or yarn

  2. A code editor, preferably VS Code.

  3. A basic understanding of Sass

Download Bootstrap from the official website: https://getbootstrap.com

Since we have Node.js installed, I'm going to use the npm version.

npm i bootstrap

We also need to install the Sass compiler. We can get the official dart-sass version from their website. Whether you're on Windows, Mac, or Linux you just need to download the dart-sass package, unzip it, and add it to the path (environment variables).

There is a npm sass package. Also, there is a Live Sass Compiler VS Code extension with over 2 million installs. Feel free to use whatever Sass compiler you're comfortable with.

Here, we are going to use the npm package: sass.

After downloading Bootstrap, and the Sass compiler, in the node-modules directory, there is a folder named bootstrap.

There are also three folders inside it: dist, js, and scss.

All the compiled CSS is in dist, the Bootstrap JavaScript code in js, and all the Sass files are in the scss folder.

How to change the primary and secondary theme colors

For customization, our idea is to override the .scss files and recompile them.

The official Bootstrap documentation advises against changing the core bootstrap files whenever possible. So we are going to create a custom.scss stylesheet.

And we are going to import all of Bootstrap in the custom.scss file.

//custom.scss

@import "../node_modules/bootstrap/scss/bootstrap";

Variables are suffixed with a !default (a Sass flag) in Bootstrap. The !default flag tells the compiler to set the value only if the value is not defined.

So, we set the variables before the @import directive so that, later, the compiler sets our value instead of the default ones.

//custom.scss

$primary: teal;
$secondary: green;

@import "../node_modules/bootstrap/scss/bootstrap";

We also need an HTML file to preview the results.

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Welcome! Customize Bootstrap with Sass</title>
    <link rel="stylesheet" href="./node_modules/bootstrap/dist/css/bootstrap.min.css"
</head>
<body>
 <div class="container" >
 <div class="row">
    <nav class="navbar navbar-expand-lg navbar-light bg-primary">
        <div class="container-fluid">
          <a class="navbar-brand" href="#">Customize Bootstrap</a>
          <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
            <span class="navbar-toggler-icon"></span>
          </button>
          <div class="collapse navbar-collapse" id="navbarSupportedContent">
            <ul class="navbar-nav me-auto mb-2 mb-lg-0">
              <li class="nav-item">
                <a class="nav-link active" aria-current="page" href="#">Home</a>
              </li>
              <li class="nav-item">
                <a class="nav-link" href="#">Link</a>
              </li>
              <li class="nav-item dropdown">
                <a class="nav-link dropdown-toggle" href="#" id="navbarDropdown" role="button" data-bs-toggle="dropdown" aria-expanded="false">
                  Dropdown
                </a>
                <ul class="dropdown-menu" aria-labelledby="navbarDropdown">
                  <li><a class="dropdown-item" href="#">Action</a></li>
                  <li><a class="dropdown-item" href="#">Another action</a></li>
                  <li><hr class="dropdown-divider"></li>
                  <li><a class="dropdown-item" href="#">Something else here</a></li>
                </ul>
              </li>
              <li class="nav-item">
                <a class="nav-link disabled" href="#" tabindex="-1" aria-disabled="true">Disabled</a>
              </li>
            </ul>
            <form class="d-flex">
              <input class="form-control me-2" type="search" placeholder="Search" aria-label="Search">
              <button class="btn btn-outline-success" type="submit">Search</button>
            </form>
          </div>
        </div>
      </nav>
<div class="container">
<div class="row">

  <div class="col-xl pt-3">
    Lorem ipsum dolor sit amet consectetur adipisicing elit. Vero, laborum hic, quia maiores animi nobis eligendi est eos saepe architecto reiciendis! Aliquam inventore distinctio reprehenderit corporis amet assumenda officiis dolorem, animi delectus sunt dolor commodi. Adipisci nam nemo labore eligendi quas, rem ipsum iusto eveniet itaque vero necessitatibus! Quas, cupiditate tempora unde nam exercitationem libero aut labore deserunt nesciunt voluptate dignissimos quis porro reprehenderit maiores excepturi, esse, nisi dolores sit tenetur voluptatum corrupti alias provident pariatur? Quam illo unde autem, fugit numquam dolores, odio sed rem saepe exercitationem fuga, nisi soluta sunt officiis! Similique, vero repudiandae quae dignissimos fuga natus!
    </div>

  <div class="col-xl pt-3 ">
    Lorem ipsum dolor sit, amet consectetur adipisicing elit. Numquam, aliquid, cumque nisi tenetur similique labore repudiandae voluptas qui hic blanditiis beatae sapiente autem dolore! Quam, cupiditate nostrum laboriosam blanditiis vel ratione, repellat, incidunt modi tempore soluta ab nesciunt? Ab similique illum suscipit exercitationem et, aut quisquam neque atque recusandae rem delectus facilis. Magnam rerum fugit minus explicabo vel! Hic quibusdam laudantium dolorum, pariatur ipsam veritatis voluptate animi, nesciunt dolorem autem dicta. Debitis quae nam dicta autem ipsum mollitia! Ipsum ipsa, molestias fugiat officiis aut illum ullam architecto maxime labore vitae. Ipsum quos neque rerum, esse iste quo explicabo eos ipsa?
    </div>

</div>
</div>

<div class="mt-5 pt-5 mb-5 text-center">
  <button type="button" class="btn btn-primary">Primary</button>
  <button type="button" class="btn btn-secondary">Secondary</button>
  <button type="button" class="btn btn-success">Success</button>
  <button type="button" class="btn btn-danger">Danger</button>
  <button type="button" class="btn btn-warning">Warning</button>
  <button type="button" class="btn btn-info">Info</button>
  <button type="button" class="btn btn-light">Light</button>
  <button type="button" class="btn btn-dark">Dark</button>
  <button type="button" class="btn btn-link">Link</button>
</div>

 </div>

 </div>

</body>
</html>

We have not compiled Sass yet. To see the default styles, run Live Server.

If Live Server is not installed, you can download the free extension from the VS Code extensions marketplace.

This is what we see:

Image

It is time to compile our custom Sass file.

Compilation syntax is simple: Specify the source and destination folders separated with a colon.

I have my custom.scss file in a folder called custom_scss.

sass custom_scss/custom.scss:assets/css/custom_bootstrap.css

After recompiling, we have the customized bootstrap in the assets/css/custom_bootstrap.css file.

Instead of the default bootstrap file, we are going to use this customized bootstrap stylesheet.

<!-- index.html -->
<head>

<link rel="stylesheet" href="./assets/css/custom_bootstrap.css"> `

</head>

Then run the Live Server again.

We get the webpage customized with our new styles.

Image

How to change the grid breakpoints

We'll now customize the media breakpoints. Alongside, we have to redefine container-max-widths also.

The easiest way is to simply override the variables:

$primary: teal;
$secondary:green;

$grid-breakpoints: (
  xs: 0,
  sm: 576px,
  md: 768px,
  lg: 992px,
  xl: 1280px,
  xxl: 1600px
);

$container-max-widths: (
  sm: 540px,
  md: 720px,
  lg: 960px,
  xl: 1220px,
  xxl: 1520px
);

@import '../node_modules/bootstrap/scss/bootstrap'

Since this would violate DRY principles (Don't Repeat Yourself), using the map-merge() function is a better option.

We have to import functions first in the custom.scss file to make map.merge() available.

We have to import variables also because $grid-breakpoints (to be used inside the function) is defined there.

//custom.scss

$primary: teal;
$secondary: green;

@import '../node_modules/bootstrap/scss/functions';
@import '../node_modules/bootstrap/scss/variables';

This is the code:

//custom.scss

$primary: teal;
$secondary: green;

//We have to import the functions first to use map.merge()

@import '../node_modules/bootstrap/scss/functions';

// We have to import the variables beforehand to 
//use the variable $grid-breakpoints.
// Otherwise, compiler will show error - '$grid-breakpoints 
//undefined.'

@import '../node_modules/bootstrap/scss/variables';

$new-breakpoints: (
    xl: 1280px,
    xxl:1600px
);

$grid-breakpoints: map-merge($grid-breakpoints, $new-breakpoints);

$new-container-max-widths: (
  xl: 1220px,
  xxl:1520px
);

$container-max-widths: map-merge($container-max-widths, $new-container-max-widths);

@import "../node_modules/bootstrap/scss/bootstrap";

We compile again and use the newest file in place of the older one.

<link rel="stylesheet" href="./assets/css/custom_bootstrap.css">

This is the final result:

Image

It is not just theme colors and media breakpoints. Borders, spacing, box-shadow, fonts, icons...you can customize anything.

I have put up all the above code in this GitHub repo.

For exploring further, the official Bootstrap documentation is an excellent resource in this regard.

Conclusion

In this tutorial, I've shown you how we can use Sass to customize Bootstrap.

Even if we are in a project that uses React with Bootstrap, the idea is the same. Create a custom .scss file, make customizations, import bootstrap, recompile, and then link to the customized file in place of the original bootstrap file.

Happy Learning!

]]> <![CDATA[ How to Use Sass with CSS ]]> https://www.freecodecamp.org/news/how-to-use-sass-with-css/ 66d84c8cf6f7ca5a6046249d Mon, 25 Apr 2022 22:32:38 +0000 Hi there! If you are reading this article, you're probably trying to understand what Sass is and how it works.

Sass is a CSS preprocessor that helps you manage tasks in large projects where the style sheets get larger, you have a number of lines of CSS code, and it becomes difficult to maintain your CSS codes.

This is where Sass becomes useful, as it has features that don't yet exist in CSS like nesting, creating functions with mixins, inheritance, and more. These features will help you write maintainable CSS code.

Sass lets you reuse your code, split it into files, and it also helps you create functions, variables, nest your CSS selectors, and other shortcuts.

How Sass Works

The web browser does not understand Sass code, though – it only understands CSS code. This means that you have to transform the Sass code into CSS code.

To do this, the compiler will generate a file with the CSS code. This transformation is called compilation. When you write Sass code in a .scss file, it is compiled into a regular CSS file that the browser will use to display it on the web page.

Why Use Sass?

There are many advantages to using Sass, so let's look at some of them now:

First, Sass is easy to understand if you know CSS. Since it's a CSS preprocessor its syntax is similar.

Also, if you use Sass, your CSS code will be compatible with all versions of browsers.

Sass also makes it possible to reuse your code by creating variables and functions with mixins (cutting up pieces of code) that can be reused over and over again. This helps you save time and allows you to code faster.

Speaking of saving time, Sass reduces the repetition of writing CSS code. This is thanks to its features like functions, variables, inheritance, and so on.

Finally, Sass is compiled to CSS and adds all the necessary vendor prefixes so you don't have to worry about writing them manually.

How to Install and Configure Sass

In this article, I'll show you two ways to install Sass.

How to Install Sass with Node.js

First, we'll download and install Node. Then we'll use the JavaScript package manager npm to install Sass and configure it in your project.

We are going to do a global installation, because this will save you from installing it every time you plan to work in your projects with Sass.

Here are the steps to follow to install and set up Sass in a project:

First, open your terminal and type:

npm install -g scss

Again, this is global installation. If you do this, you avoid installing it every time you plan to work with Sass in your projects.

Then, in the project folder, create a Sass file in the one you are going to work on:

style.scss

style is the file name and .scss is the Sass extension name.

Then you will use the following command to generate a style.css file from the SASS file:

sass --watch style.scss style.css

style.scss is the source file and style.css is the destination file where Sass generates the CSS code.

Now installation and configuration are complete! You can use Sass in your projects.

But before we get into how to use Sass, I want to show you a second way of doing it. I recommend this way, as it is the simplest and easiest way to install and configure Sass.

How to Install Sass Using VS Code

First, download and install Microsoft's VS Code editor if you haven't already. Then launch the editor so you can download the Live Sass Compiler extension.

Image

And that's all you have to do. Once the installation is done, you'll be able to use Sass in your projects. Easy, right?

How to Use Sass in a Project

To understand how to use Sass, we will work on an example project where we will create two grids. The idea here is not to learn everything about Sass but what you see is mostly what you need to know to start using Sass.

Here is an overview of what we will create to understand Sass.

Image

You might be wondering why I took the grid example? Well, because we often use grids in web pages and they're simple to understand.

First of all, you should know that we'll do all the coding in the Sass file (style.scss) and not in the style.css file. It is Sass that will generate a CSS file for us with the same code.

To start, create a folder with two folders inside, CSS and images. Then inside the CSS folder create a file with the Sass extension – in my case it's style.scss.

Then open it and the file will be detected right away. Below the editor a button will appear named Watch Sass. Just click on it to tell Sass to watch this file and start generating (compiling) code in the CSS file.

Image

Image

Once SASS finishes compiling it will create three files in the project's CSS folder: style.css, style.scss, and style.css.map. It tracks all the changes and it is ready to generate CSS code.

If you come back soon to continue working, all you have to do is open the file which has the extension .scss. Then click on Watch Sass for Sass to start generating the modifications in the CSS file (otherwise nothing will be generated in the CSS file).

I hope it's going ok so far. You have just seen how to install, configure, and start using Sass in your project. So now let's continue with our example of the grids to understand the different functionalities Sass brings.

How to Use Variables in Sass

Before seeing how to create Sass variables, create an index.html file copy and paste the code below in the file:


<!DOCTYPE html>
<html lang="en">
      <head>
            <meta charset="UTF-8">
            <meta http-equiv="X-UA-Compatible" content="IE=edge">
            <meta name="viewport" content="width=device-width, initial-scale=1.0">
            <title>card with sass</title>
      </head>
      <body>

            <div class="card">
                  <img src="https://images.unsplash.com/photo-1524749292158-7540c2494485?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxzZWFyY2h8MTd8fGRldmVsb3BlcnN8ZW58MHx8MHx8&auto=format&fit=crop&w=500&q=60" alt="">
                  <div class="card_content">
                        <h2 class="card_title">Lorem</h2>
                        <p class="card_description">Lorem, ipsum dolor sit amet consectetur adipisicing elit. Rerum porro dolores sapiente.</p>
                  </div>
            </div>

            <div class="card card_dark">
                  <img src="https://media.istockphoto.com/photos/put-more-in-get-more-out-picture-id1291318636?b=1&k=20&m=1291318636&s=170667a&w=0&h=UvVIk7wwkN3X9OFm8gBlWWviV5vAjfrq2ejYP30JmnA=" alt="">
                  <div class="card_content">
                        <h2 class="card_title">Lorem</h2>
                        <p class="card_description">Lorem ipsum dolor sit amet, consectetur adipisicing elit. Atque amet obcaecati nihil.</p>
                  </div>
            </div>

      </body>
</html>

Run the file in your browser to see the result.

Image

Sass lets you create variables, but I want to show you a difference between Sass and CSS.

body {
    font-family: 'Poppins', Helvertica, sans-serif;
    background-color: #ab99ca;
    padding: 2rem;
    min-height: 100vh;
    display: flex;
    align-items: center;
    justify-content: center;
}

If you look at this example, it's CSS. But if in the project I want to reuse any color, padding, or font, I have to rewrite the same code (in CSS).

But with Sass I can create variables so I can reuse these features. To create a variable in Sass, we use the dollar sign $ followed by the variable name and a colon for the value. Keep in mind that it's best to create a name that reflects the object you're going to use.

/* Creating and Using Variables */

$fonts: 'Poppins', Helvertica, sans-serif;
$primary-color: #ab99ca;
$spacing: 2rem;

body {
    font-family: $fonts;
    background-color: $primary-color;
    padding: $spacing;
    min-height: 100vh;
    display: flex;
    align-items: center;
    justify-content: center;
}

Add the above code in the style.scss file. Since we are working with a Sass file and HTML does not recognize Sass, to see the results we'll specify the CSS file that has been generated in our file index.html.

It's really important to link the CSS file to index.html, to allow the CSS file to apply the CSS styles to the HTML. Otherwise there will be no styling applied and you will only see the code produced by the HTML.

So we will link our CSS file in the index.html file. In my case:

<link rel="stylesheet" href="css/style.css">

Image

Run the file in your browser to see the result.

Image

We will now see how to organize the code thanks to IMPORTS. The code will be cut into files while we keep using our example.

When creating a file, the file name will be followed by an underscore(_) at the beginning to prevent it from being compiled by Sass.

Create three files:

  • _variables.scss: to add the variables

  • _mixins.scss: to add the functions that we will reuse

  • _card.scss: to add the styles of our cards

Image

Copy and paste the variables you created in the style.scss file and put them in the _variables.scss file:

    $fonts: 'Poppins', Helvetica, sans-serif;
    $primary-color: #ab99ca;
    $spacing: 2rem;
    $dark-grey: #999;

For the _mixins.scss file, this is where we'll create the reusable functions with mixins.

Mixins allow you to create reusable functions. To declare a function you must enter @mixin name_fonction { content } or if your function has a parameter, you must enter @mixin name_fonction($name_variable) { content }.

To use mixins, you have to import it by typing @include namefunction(); which saves time in a large project.

Add this code to the _mixins.scss file:


@mixin flex-center {
    display: flex;
    align-items: center;
    justify-content: center;
}

/* $radius is the parameter of the function */

@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;
}

For the _card.scss file, add this code to it:

.card {
    background-color: white;
    width: 20rem;
    overflow: hidden;
    margin: 2rem;
    box-shadow: 5px 5px 5px 5px #000;
    @include border-radius(0.5rem); /* using the mixins function */

    img {
        height: 15rem;
        background-size: cover;
        background-position: center center;
    }

    .card_content {
        padding: $spacing;
    }

    .card_title {
        margin: 0;
        color: black;
    }

    .card_description {
        margin: 0;
        color: $dark-grey;
    }

    &_dark {

        background-color: black;

        .card_title {
            color: white;
        }
    }

}

In the code above we're using nesting and aliases. Nesting helps us simplify the way we write our CSS styles and allows us to nest CSS selectors.

For aliases you can use (&) or (and) followed by the class name that will resume the parent selector's code.

To use an alias, you must import it by typing the alias followed by the name of the variable (&_dark).

If you try to run the index.html file, nothing will change. It does not change because we have created files that are not related to index.html and our style.sass file only generates the code it has.

To fix this, we'll import all the files we've created into the style.sass file so that when SASS does the monitoring, it'll generate the code of those files.

/* file import */
@import 'variables';
@import 'mixins';
@import 'card';

For the style.scss file, add the above code. The style.scss file should be like this:


/* file import */

@import 'variables';
@import 'mixins';
@import 'card';

body {
    font-family: $fonts; /* variable usage */
    background-color: $primary-color;
    padding: $spacing;
    min-height: 100vh;
    @include flex-center(); /* using the mixins function */
}

In the previous code, I imported the files (SASS import) into style.css so that they can be tracked and generate code when there are changes.

Run the index.html file in your browser to see the result.

Image

If you get the same result as in the capture above, congratulations, you now understand how Sass works.

Here is the preview link for the project we built: https://adalbertpungu.github.io/card_with_sass/

And here's the GitHub repository link:

https://github.com/AdalbertPungu/card_with_sass

Conclusion

In this article, you learned how Sass works by building a simple photo grid. In this small project, we've covered many core Sass features, but not all of them. So I hope you will start using it in your projects to learn more.

You can check the documentation if you want to dive deeper: https://sass-lang.com/documentation.

That’s all for this article. Thank you for reading! I think you’re ready to try using Sass.

Happy coding.

Follow me on Twitter: twitter.com/AdalbertPungu

]]> <![CDATA[ The Beginner's Guide to Sass ]]> https://www.freecodecamp.org/news/the-beginners-guide-to-sass/ 66d45f37264384a65d5a9544 Mon, 04 Apr 2022 23:39:31 +0000 Have you ever wondered what SASS stands for? Or perhaps you already know what it is but haven't taken the time to study and use it.

Whether you're learning about it for the first time, or want to brush up on your knowledge of the subject, this is the article for you.

In this post, you'll learn the fundamentals of Sass, what it is, and how to use Sass's awesome features to speed up the process of writing styles.

Prerequisites

This article assumes that you have:

  • Basic understanding of HTML & CSS

  • A code editor (VS Code recommended). If you don't have it installed, download it here.

  • And a browser (Chrome or Firefox recommended)

What exactly is Sass?

Sass (Syntactically Awesome Style Sheets) is a CSS preprocessor that gives your CSS superpowers.

Let's face it: writing CSS can be difficult at times, especially in today's world of increasingly complex user interfaces.

And many times, you'll find that you're repeating yourself often.

Sass comes to the rescue in this situation. It helps you stick to the DRY (Do Not Repeat Yourself) philosophy when writing CSS.

Sass provides a compiler that allows us to write stylesheets in two different syntaxes, indented and SCSS. Let's look at each now.

Indented syntax

This is the older syntax that is indented, and gets rid of the curly braces and semi-colons. It has a file extension of .sass.

nav
  ul
    margin: 0
    padding: 0
    list-style: none

  li
    display: inline-block

  a
    display: block
    text-decoration: none

SCSS syntax

This is the newer and more popular syntax. It is essentially a subset of the CSS3 syntax. This means that you can write regular CSS with some additional functionalities.

Due to its advanced features it is often termed as Sassy CSS. It has a file extension of .scss.

nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }
  li {
    display: inline-block;
  }

  a {
    display: block;
    text-decoration: none;
  }
}

Quick Disclaimer: This article uses the SCSS syntax because it's more widely used.

How Does Sass Work?

Sass works in such a way that when you write your styles in a .scss file, it gets compiled into a regular CSS file. The CSS code is then loaded into the browser.

That is why it's called a Preprocessor.

Why should you use Sass?

  • Easy to learn: If you are familiar with CSS already, then you'll be glad to know that Sass actually has a similar syntax, and so you can start using it, even after this tutorial ;)

  • Compatibility: It is compatible with all versions of CSS. So, you can use any available CSS libraries.

  • Saves time: It helps reduce the repetition of CSS, because of its powerful features.

  • Reusable code: Sass allows for variables and chunks of code (mixins) that can be reused over and over again. This helps you save time and makes you able to code faster.

  • Organized Code: Sass helps keep your code organized by using partials.

  • Cross Browser Compatibility: Sass gets compiled into CSS and adds all the necessary vendor prefixes so you don't have to worry about manually writing them out.

Features of Sass

Here are some of the features that make Sass truly CSS with Superpowers:

Variables in Sass

You can declare variables in Sass. This is one of Sass's strengths since we can define variables for various properties and use them in any file.

The benefit here is that if that value changes, you simply need to update a single line of code.

This is done by naming a variable with a dollar symbol $ and then referencing it elsewhere in your code.

$primary-color: #24a0ed;

.text {
  color: $primary-color;
}
button {
  color: $primary-color;
  border: 2px solid $primary-color;
}

Nesting in Sass

Most of the time, while writing CSS, classes are often duplicated. We can avoid this duplication by nesting styles inside the parent element.

In CSS,

nav {
  height: 10vh;
  width: 100%;
  display: flex;
}

nav ul {
  list-style: none;
  display: flex;
}

nav li {
  margin-right: 2.5rem;
}

nav li a {
  text-decoration: none;
  color: #707070;
}

nav li a:hover {
  color: #069c54;
}

With Sass, the above code can be written like this:

nav {
  height: 10vh;
  width: 100%;
  display: flex;

  ul {
    list-style: none;
    display: flex;
  }

  li {
    margin-right: 2.5rem;

    a {
      text-decoration: none;
      color: #707070;

      &:hover {
        color: #069c54;
      }
    }
  }
}

Parent Selector

In the Sass code above, you might notice the ampersand symbol & used with the hover pseudo-class. This is called a Parent Selector.

The parent selector, &, is a special selector invented by Sass that's used in nested selectors to refer to the outer selector. Source – Sass Documentation

So, in the case of the code above, & will refer to the parent which is the anchor tag a.

You can check out my article on how to implement Sass using BEM methodology.

Partials in Sass

This is one of the many awesome features of Sass that gives you an advantage.

As stylesheets grow large over time, it gets difficult to maintain them. Because of this, it just makes sense to break your stylesheets into smaller chunks. In other words, Partials help you organize and structure your code.

To declare a partial, we will start the file name with an underscore _, and add it in another Sass file using the @import directive.

For example, if we have a _globals.scss, _variables.scss, and _buttons.scss, we could import them into the main SCSS file main.scss.

@import "globals";
@import "variables";
@import "buttons";

You'll notice that the underscore and the .scss are not added. That is because Sass automatically assumes that you are referring to the .sass or .scss file.

Mixins in Sass

Another major issue with CSS is that you'll often use a similar group of styles. Mixins allow you to encapsulate a group of styles, and apply those styles anywhere in your code using the @include keyword.

An example of when you'd use mixins is when using Flexbox.

@mixin flex-container {
  display: flex;
  justify-content: space-around;
  align-items: center;
  flex-direction: column;
  background: #ccc;
}

.card {
  @include flex-container;
}

.aside {
  @include flex-container;
}

Sass Functions and Operators

Sass provides a suite of tools to help write more programmatic code.

Sass offers built-in functions that enable us to do calculations and operations that return a specific value.

They range from color calculations to math operations like getting random numbers and calculation of sizes, and even conditionals.

It also provides support for mathematical operators like +, -, \, *, /, and %, which we can use with the calc function.

Here is an example using a pixel to rem conversion function:

@function pxToRem($pxValue) {
  $remValue: ($pxValue / 16) + rem;
  @return $remValue;
}

div {
  width: pxToRem(480);
}

However, it's important to note that the / operator for division is deprecated, and will be removed in Dart Sass 2.0.0. You can read about it in the Docs.

So, this is how it should be written:

@use "sass:math";

@function pxToRem($pxValue) {
  @return math.div($pxValue, 16px) * 1rem;
}

div {
  width: pxToRem(480px); // gives 30rem
}

Here is an example of conditional logic in a mixin:

@mixin body-theme($theme) {
  @if $theme == "light" {
    background-color: $light-bg;
  } @else {
    background-color: $dark-bg;
  }
}

Sass also provides the lighten and darken functions to adjust a color by a certain percentage.

For example:

$red: #ff0000;

a:visited {
  color: darken($red, 25%);
}

How to Set Up Sass for Local Development

Great! Now that we have learned about the "theoretical" aspects of Sass, let's get into the code to better understand how it works.

In this section, you will learn how to set up a local development environment, and also go through a simple landing page I have prepared.

Check out the demo on Codesandbox and code repository on GitHub.

Ways to compile Sass

There are different ways of compiling Sass files which are:

  • VS Code Extension

  • Install using NPM globally

  • Install using open source apps such as Compass.app, Live Reload, and Koala.

  • Install using Homebrew (for MacOS)

In this tutorial, we will be using the VS code Extension option because it is the easiest to get started with.

How to Set Up Sass for VS Code

Step 1: Install Live Sass Compiler

First, launch Visual Studio Code. Once it's loaded, go to the side panel on the left and select the extensions tab.

Image

Extensions tab in VS Code

In the search bar, search for "Live Sass Compiler" and install it. This extension helps us to compile the Sass files — .scss (or .sass) – into .css files.

Step 2: Set the Save Location

Now change the file path so that Sass gets compiled into the styles folder.

To do this, you will make changes to the settings.json file.

In VS Code, go to File > Preferences > Settings. Now search for live sass compile to change the global settings.

Click on Edit settings.json.

Now, on the first few lines, where you see this code:

{
  "liveSassCompile.settings.formats": [
    {
      "format": "expanded",
      "extensionName": ".css",
      "savePath": "/"
    }
  ],

Change "savePath": "/" to "savePath": "/styles", so it now looks like this:

{
  "liveSassCompile.settings.formats":[
    {
      "format": "expanded",
      "extensionName":".css",
      "savePath":"/styles",
    },

    // You can also use this minified extension for production, as it reduces the file size

    {
      "format": "compressed",
      "extensionName":".min.css",
      "savePath":"/styles",
    }
  ],

Step 3: Compile Sass

Now, after saving the settings, go back to the Sass file, and click on the button that says "Watch Sass" at the very bottom of the window.

Image

Click on "Watch Sass"

After you click the button, two files get created: .css and a .css.map in the styles folder.

You should not, however, change any of them. Because it already helps you compile the Sass into CSS every time you save new stylings.

Then, link the CSS file in your index.html. In our case:

    <link rel="stylesheet" href="/styles/main.css" />

Now run the file in your browser. This should be the resulting layout in CodeSandbox below:

Walking through the code

Here's an explanation of the code from the previous section:

  • We have a basic markup in the index.html file which contains a header and home/hero section.

    • It contains a link to the CSS file which the extension compiled for us.

    • And some JavaScript for the responsive menu toggle.

  • The main.scss gets compiled, and the resulting CSS file main.css is what is imported in the index.html:

      <link rel="stylesheet" href="/styles/main.css" />

  • The Main Scss file main.scss imports all of the partials: _base.scss, _components.scss, _home.scss, _layout.scss _responsive.scss, _variables.scss.

      @import "variables";
  @import "base";
  @import "layout";
  @import "components";
  @import "home";
  @import "responsive";

  • The base partial contains the mixins of flex and grid which are included in the places where we need them.

Conclusion

Congrats! If you made it to the end, that means you have learned about how Sass works, its cool features, and hopefully you start using it soon.

If you want to learn more about Sass, I recommend checking out freeCodeCamp's course.

If you found this article useful (which I'm sure you did 😉), do share it with your friends and network, and feel free to connect with me on Twitter and my blog where I share resources and articles to make you a better dev.

Thanks for reading, and happy coding!

]]> <![CDATA[ How to Use Mixins in Sass and Pass Arguments – With Code Examples ]]> https://www.freecodecamp.org/news/how-to-pass-arguments-to-mixins/ 66d46040e39d8b5612bc0dc0 Thu, 02 Dec 2021 18:45:59 +0000 Mixins are my favorite thing about Sass. They made my life so much easier, so I wanted to show you how they can do the same for you.

Mixins can be a bit tricky to understand at first, but don't worry. You'll get the hang of it by practicing and will fall in love with mixins like I have.

Before I get started, let me show you what you will read in this article:

  • What mixins are

  • How to write mixins and include them in your code

  • How and when to pass arguments

Now let's get to the point, shall we?

What Are Mixins in Sass?

First, let's take a quick look at what a mixin is:

"Mixins allow you to define styles that can be re-used throughout your stylesheet. They make it easy to avoid using non-semantic classes like .float-left, and to distribute collections of styles in libraries." – Sass Docs

To put it simply, a mixin is a code block which allows you to write your styles in it and use it throughout the whole project. You can also think of it as a reusable component. It also helps you to write cleaner code without having to repeat yourself.

How to Write a Mixin

This is how you write a mixin in Sass:

@mixin name {
    properties;
}

And here's how to include it in your code:

div {
    @include name;
}

Here's an example of using a mixin in your code:

@mixin circle {
    width: 200px;
    height: 200px;
    background: red;
    border-radius: 50%;
}

div {
   @include circle;
}

Now let's see what's happening in the above code:

  1. First we define a mixin using the @mixin at-rule.

  2. Then we give it a name – choose whatever you think will fit what you're gonna be using it for.

  3. Add your CSS properties.

  4. By simply using @include you pass it to the mixin block.

Mixin Example

Now let's look at an example of a mixin in action.

Here's how to create a pink circle with a mixin:

@mixin circle {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    background: #ea0185 ;
}

.circle {
    @include circle;
}

Image

Now you might ask "why should I use a mixin to create a pink circle? I could just give my element a class and style it."

Mixins are reusable, remember? We use them when we know we'll be repeating ourselves a lot. So the whole point is to avoid repetition and keep the code clean.

Passing Arguments

Now that we've seen how to write a mixin, let's move on to the next section. I want to divide this section into smaller parts:

  • What are mixin arguments?

  • When to pass arguments?

  • How to pass arguments? + Examples.

What Are Mixin Arguments?

An argument is the name of a variable which is separated by a comma.

When Should You Pass Arguments to a Mixin?

I'll start this section with an example:

What if you were to create two different circles? Like a green circle and a pink circle?

You could create two separate mixins, one for the green one and one for the pink one:

// a mixin for the green circle
@mixin green-circle {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    background: green;
}

// and another mixin for the pink circle
@mixin pink-circle {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    background: pink;
}

But this isn't great because you're repeating your code. And we should stick to the DRY (Don't Repeat Yourself) principle, remember?

And that's where mixin arguments come in.

In a regular mixin (and by regular I mean a mixin when no argument is passed) you define some certain styles. But an argument allows you to define different styles by turning them into variables. It's like customizing each style for each element. Let's move on to the next section and see some examples.

How to Pass Arguments to Mixins

We've seen what an argument is and when to use it. And now it's time to see how to pass the arguments:

@mixin name($argument,$argument) {
    property: $argument;
    property: $argument;

}

Here's an example:

@mixin circle2 ($width,$height,$color) {
    width: $width;
    height: $height;
    background: $color;
}

You can think of arguments as customizable variables that you can use in different situations to create different things without repeating yourself.

Like when you pass $width to the width property, you can define it in different situations. Maybe you need the width to be 50px in one place and 500px somewhere else.

Does that make sense? Let me break it down for you with another example.

Okay, back to our circles.

I want to make one big red circle and one small green circle (two different things) with just one mixin.

Image

Now what properties do I need to make a circle?

width, height and background-color, right?

Since we're building circles, the border-radius will be 50% in both situations. So I will leave it alone and won't pass any argument to it.

Now we're down to 3 properties:

  1. width

  2. height

  3. background-color

That means we only need 3 arguments:

@mixin circle($width,$height,$color) {
    // We passed $width to the width property
    width: $width;

    // We passed $height to the height property
    height: $height;

    // And we passed $color to width background-color
    background: $color;

    // no argument for this property, beacuase it's gonna be the
    // same in both circles
    border-radius: 50%;
}

So now let's see how we can pass arguments to our mixin:

For the big red circle

.circle-red {

    // circle ($width,$height,$color);
   @include circle (350px,350px,red);
}

For the small green circle

.circle-green {

     // circle ($width,$height,$color);
    @include circle (200px,200px,green);
}

And here's the result:

Image

If you want some more info about passing arguments to mixins, here's a little video to help you out:

Alright, back to our tutorial. As I said earlier, I didn't pass any arguments to the border-radius property because it's always gonna be 50% (in this case).

But if I were to make one square and one circle, then I would need to pass an argument to border-radius too:

@mixin circle($width,$height,$color,$radius) {
    width: $width;
    height: $height;
    background: $color;
    // passed argument to border-radius to have control over it 
    border-radius: $radius;
}

.square {
            // ($width,$height,$color,$radius)
    @include circle (350px,350px,red, 10px);
}

.circle {
            // ($width,$height,$color,$radius)
    @include circle (200px,200px,green, 50%);
}

Now we have a big red square and a small green circle:

Image

Let's take a look at another example. This time let's try using a mixin on some text.

This is what I want to make, a green text with black background and red text with a transparent background:

Image

First I created two h2 elements:

<h2 class="text1">Text</h2>
<h2 class="text2">Text</h2>

We need font-size, color, and background properties here. Now I should pass arguments by turning them into variables.

@mixin text($font-size,$color,$bg-color) {

     // we pass the $font-size to font-size property
    font-size: $font-size;

    // we pass the $color to color property
    color: $color;

    // we pass the $bg-color to background property
    background: $bg-color;
}



.text1 {
          // ($font-size,$color,$bg-color)
    @include text(3rem,green , black)
}

.text2 {
          // ($font-size,$color,$bg-color)
    @include text(5em,red , transparent)
}

And there you have it.

Quick tip: Remember that the order of arguments matters.

It matters because the only way to know what value you meant to pass for each parameter is by using the correct order.

For example, if your arguments order is $width, $height, $color, passing them should be in order as well:

@mixin circle($width,$height,$color) {
    width: $width;
    height: $height;
    background: $color;
    border-radius: 50%;

}

.circle-red {
             // ($width,$height,$color)
    @include circle (350px,350px,red);
}

You can't pass color first followed by the width and height:

.circle-red {
    @include circle (red,350px,350px);
}

Regarding this wrong order, we passed $width to width property, therefore the first value needs to be a number. So if you pass $color first, the value won't be recognized. That's why we have to pass arguments in order.

Here's a quick review of what we've talked about in this article

  • Mixins are reusable code blocks.

  • We use them when we know we'll be repeating pieces of code a lot.

  • This is how to we write a mixin:

@mixin name {
    properties;
}

  • An argument is a name of a variable which is separated by a comma.

  • Arguments allow you to define different styles.

  • The order of arguments matters.

  • This is how we pass arguments:

@mixin name($argument,$argument) {
    property: $argument;
    property: $argument;

}

And that's a wrap for this article – I hope you liked it and found it useful. 😊

Image

You can also connect with me on twitter-

]]> <![CDATA[ How to Use Sass with CSS Modules in Next.js ]]> https://www.freecodecamp.org/news/how-to-use-sass-with-css-modules-in-next-js/ 66b8e3790a89d796f29a16f7 Thu, 07 Jan 2021 17:31:14 +0000 Next.js gives us CSS Modules by default, providing benefits like scoped styles and focused development in our app. How can we give our Next.js CSS superpowers with Sass?

What are CSS Modules?

CSS Modules are essentially CSS files that, when imported into JavaScript projects, provide styles that are scoped to that particular part of the project by default.

When importing your module, the classes are represented by an object mapped with each class name, allowing you to apply that class right to your project.

For instance, if I had a CSS module for the title of my page:

.title {
  color: blueviolet;
}

And I import that into my React project:

import styles from './my-styles.css'

I can then apply that title right to an element as if it were a string:

<h1 className={styles.title}>My Title</h1>

By scoping styles, you no longer have to worry about breaking other parts of the application with cascading styles. It’s also easier to manage smaller chunks of code that pertain to a specific piece of the application.

What is Sass?

Sass is an extension of the CSS language that provides powerful features like variables, functions, and other operations that allow you to more easily build complex features into your project.

As an example, if I wanted to store my color above in a variable so I can easily change it later, I can add:

$color-primary: blueviolet;

.title {
  color: $color-primary;
}

If I wanted to change that color but only in one spot, I can use built-in color functions to change the shade:

$color-primary: blueviolet;

.title {
  color: $color-primary;
  border-bottom: solid 2px darken($color-primary, 10);
}

One additional benefit is the ability to nest styles. This allows for easier, more logical organization of your CSS.

For instance, if I wanted to change only a <strong> element nested in a title, I can add:

$color-primary: blueviolet;
$color-secondary: cyan;

.title {

  color: $color-primary;
  border-bottom: solid 2px darken($color-primary, 10);

  strong {
    color: $color-secondary;
  }

}

What are we going to build?

We're going to create a new React app using Next.js.

With our new app, we'll learn how to install and configure Sass so that we can take advantage its features inside of Next.js.

Once set up Sass, we'll walk through how to use Sass variables and mixins to recreate some of the default elements of the Next.js UI.

Want to skip the tutorial and dive into the code? Check out Next.js Sass Starter on GitHub: https://github.com/colbyfayock/next-sass-starter

Step 0: Creating a new Next.js app

To get started with a new Next.js app, we can use Create Next App.

In your terminal, navigate to where you want to create the new project and run:

yarn create next-app my-next-sass-app

Note: you can use npm instead of yarn for any examples with installation and package management.

Once the installation finishes, you can navigate into the directory, and start your development server:

yarn dev

Which should start your new Next.js project at http://localhost:3000!

Image New Next.js app

If this is your first time creating a new Next.js app, have a look around! It comes with a basic homepage as well as two CSS files:

  • /styles/globals.css
  • /styles/Home.module.css

Here we’ll be focusing on the home file. If you look inside pages/index.js, there, you’ll see that we’re importing the home file, making those styles available.

Next.js has CSS Modules built in by default. This means that when we import our home styles file, the CSS classes are added to the styles object, and we apply each of those class names to the React elements from that object, such as:

<h1 className={styles.title}>

That means that our styles are scoped to that single page.

To learn more about CSS Modules or the built-in support in Next.js, you can check out the following resources:

Step 1: Installing Sass in a Next.js app

While Next.js comes with some good built-in CSS support, it doesn’t come with Sass completely built in.

Luckily, to get Sass up and running inside of our Next.js app, all we need to do is install the Sass package from npm, which will let Next.js include those files in its pipeline.

To install Sass, run the following inside of your project:

yarn add sass

And if we start back up our development server and reload the page, we’ll actually notice that nothing has happened yet, which is a good thing!

But next we’ll learn how to take advantage of our CSS superpowers.

Follow along with the commit!

Step 2: Importing Sass files into a Next.js app

Now that Sass is installed, we’re ready to use it.

In order you use any Sass-specific features though, we’ll need to use Sass files with either the .sass or .scss extension. For this walkthrough, we’re going to use the SCSS syntax and the .scss extension.

To get started, inside of pages/index.js, change the import of the styles object at the top of the page to:

import styles from '../styles/Home.module.scss'

And once the page reloads, as we probably expect, the page is actually broken.

Image Next.js failed to compile

To fix this, rename the file:

/styles/Home.module.css

to

/styles/Home.module.scss

The difference is we’re changing the file extension from .css to .scss.

Once the page reloads, we’ll see that our Next.js site is loading and is back ready for action!

Image New.js app loading

_Note: We’re not going to cover the global styles file here – you can do the same thing by renaming the global styles file and updating the import inside of /pages/_app.js_

Next, we’ll learn how to use Sass features for our Next.js app.

Follow along with the commit!

Step 3: Using Sass variables in a Next.js app

Now that we’re using Sass in our project, we can start using some of the basic features like variables.

To show how this works, we’re going to update the blue inside of our app to my favorite color, purple!

At the top of /styles/Home.module.css, add the following:

$color-primary: #0070f3;

The color #0070f3 is what Next.js uses by default in the app.

Next, update each location that uses that color in our home CSS file to our new variables, such as changing:

.title a {
  color: #0070f3;

to

.title a {
  color: $color-primary;

If we refresh the page, nothing should change.

Image Unchanged Next.js app

But now because we’re using a variable to define that color, we can easily change it.

At the top of the page, change the $color-primary variable to purple or whatever your favorite color is:

$color-primary: blueviolet;

And when the page reloads, we can see that our colors are now purple!

Image Next.js app with purple color

Variables are just the start to the superpowers Sass gives our CSS, but we can see that they allow us to easily manage our colors or other values throughout our application.

Follow along with the commit!

Step 4: Using Sass mixins with global imports in Next.js

One of the other many features of Sass is mixins. They give us the ability to create function-like definitions, allowing us to configure rules that we can repeat and use throughout our app.

In our example, we’re going to create a new mixin that allows us to create responsive styles using a media query throughout our app. While we can already do that with a media query alone, using a mixin allows us to use a single definition, keeping that consistent and allowing us to manage that responsive definition from one place.

Because this mixin is something we want to use throughout our entire application, we can also use another feature of Sass, which is the ability to import files.

To get started, create a new file under the /styles directory:

/styles/_mixins.scss

We’re using an underscore in front of our filename to denote that it’s a partial.

Next, inside of our /styles/Home.module.scss file, let’s import that new file:

@import "mixins";

Once the page reloads, we’ll notice nothing changed.

If we lookout the bottom of Home.module.scss, we’ll see that we’re using a media query to make the .grid class responsive. We’re going to use that as a basis for our mixin.

Inside of _mixins.scss, add the following:

@mixin desktop() {
  @media (max-width: 600px) {
    @content;
  }
}

Note: while we probably can come up with a better name for this mixin than desktop, we’ll use that as the basis of our example.

The @content means that any time we use our desktop mixin, it will include the nested content in that location.

To test this out, back in our Home.module.css file, let’s update our .grid snippet:

@include desktop() {
  .grid {
    width: 100%;
    flex-direction: column;
  }
}

If we open our app back up and shrink the browser window, we can see that we still have our responsive styles!

Image Responsive styles in Next.js

We can even take this a step further. Sass allows you to nest styles. For instance, instead of writing:

.footer {
  // Styles
}

.footer img {
  margin-left: 0.5rem;
}

We can include that img definition right inside of the original .footer definition:

.footer {

  // Styles

  img {
    margin-left: 0.5rem;
  }

}

That img definition will compile to .footer img, just the same as if it was written in standard CSS.

So with that in mind, we can use the same concept and move our desktop mixin into our original .grid class:

.grid {

  @include desktop() {
    width: 100%;
    flex-direction: column;
  }

}

And if you notice, because we’re inside of the .grid class already, we can remove that from inside of the mixin, as it will already be applied.

This allows for much easier organization of our responsive styles.

Finally, if we look back at our app, we’ll notice that still, nothing has changed, which means we’re successfully using our Sass mixin.

Image No change in our Next.js app

Follow along with the commit!

What else can we do with Sass and Next.js?

We’re only scratching the surface here with Sass. Because our CSS modules now have the power of Sass, we have a ton of capabilities that don’t come by default with CSS.

Color Functions

Sass has a ton of functions built in that allow us to manipulate colors, mixing and matching shades much more easily.

Two that I use often are darken and lighten, that allow you to take a color and change the shade.

Learn more about all of the available color functions in Sass.

Custom Functions

While mixins seem like functions, we can define true functions in Sass that allow us to perform complex operations and produce values based on an input.

Learn more about custom functions in Sass.

Other Value Types

While most of the time with CSS we’re using strings or numbers, we saw that a simple extension of that is the ability to use variables.

In addition to variables, Sass gives us more value types like Maps, which function sort of like an object, and Lists, which are kind of like arrays.

Learn more about the value types in Sass.

More

There are a ton of features available in Sass and lots of articles that cover the most used features. Take some time to explore the documentation and find what’s out there!

]]> <![CDATA[ How to Create a Next.js Starter to Easily Bootstrap a New React App ]]> https://www.freecodecamp.org/news/how-to-create-a-nextjs-starter-to-easily-bootstrap-a-new-react-app/ 66b8e35389963e292346f67d Tue, 18 Aug 2020 15:33:48 +0000 Getting started with a new React app is easier than ever with frameworks like Next.js. But those frameworks don’t always include all of the tools you want to use.

How can we use Starters to become super productive when starting a new project with our favorite tools?

What is Next.js?

Next.js is an application framework from Vercel that allows you to very quickly bootstrap a new React application.

Some basic features include creating pages and data fetching, and they allow you to generate a static site or use server side rendering to dynamically load your app.

On top of that, you can take advantage of its advanced features like Routing or creating an API right next to your UI.

What is a Starter?

Starters are basically a git repository in the form of a template that allows you to easily create a preconfigured app.

There’s nothing necessarily special about a Starter. At it’s core, it’s a Next.js app that’s already been set up a specific way and typically generalized so that anyone can use it.

For example, if you tend to build lots of apps the same way each time, you might have to repeat those same configuration steps every time you create a new app.

Instead, you can create a Starter from where you'll start your projects – and it'll eliminate the need to repeat those first steps each time.

What are we going to build?

We’re going to build a basic Next.js Starter that will let you or anyone else quickly and easily create a new project with that Starter as a starting point.

While we won’t go too heavy into features, as the goal here is to learn about Starters, we’ll test this out by adding Sass to Next.js so someone can easily get started with CSS superpowers.

You can check out the Starter on GitHub: github.com/colbyfayock/next-sass-starter.

Creating a new Next.js Starter

To get started with creating a Starter, we need to start with a Next.js app.

We can do this by running the following command in whatever directory you want to create this in:

yarn create next-app
# or
npx create-next-app

Once you run that, Next.js will ask you for a project name. While you can use whatever you like, Next.js Starters typically have a name pattern of next-[name]-starter.

So because we’re creating a Sass Starter, I might call it next-sass-starter.

Image New Next.js app in the terminal

Once Next.js has installed all of our dependencies, you’ll be ready to navigate to that folder and run the command to start your development server.

yarn dev
# or
npm run dev

And once the development server starts up, we should be ready to go!

Image New Next.js app in the browser

At this point, we pretty much have a basic Starter. As mentioned before, there really isn’t much that’s actually special with a Next.js Starter. So if we pushed this up to Github, we could immediately start using it “as is”.

You can test this out by running the following:

yarn create next-app [project-name] -e [GitHub URL]
# or
npx create-next-app [project-name] -e [GitHub URL]

After running that, you should be set up with a new directory that has a project created from your Starter with all of the dependencies installed.

But we want to do more than that. Our goal is to add features that help get an app started with more than the default, so let’s add Sass.

Follow along with the commit!

Adding Sass to a Next.js Starter

Note: For our example, we’re going to create a Sass starter as the name above might have implied. Feel free to add any features you want at this point, whether it includes Sass or not.

Remember – the goal here will be to provide something that we’ll be able to use when creating a new project with this Starter.

Next, we want to actually add Sass to our project. To get started, we want to install sass as a dependency:

yarn add sass
# or
npm install sass

Next, because Next.js already looks for .scss as a file extension, we can simply update out two CSS files under the styles directory to .scss.

So change the following files:

styles/globals.css => styles/globals.scss
styles/Home.module.css => styles/Home.module.scss

Next, we need to set up our import statements to recognize our new file extensions.

In pages/_app.js, update the styles import at the top to:

import '../styles/globals.scss'

And in pages/index.js, update the styles import to:

import styles from '../styles/Home.module.scss'

At this point, you can start your development server and we should still see the default Next.js page.

Image Next.js app should look the same

To see our Sass in action, we can update some of our classes to use nested styles instead of individual selectors.

Update all of the .footer selectors inside of styles/Home.module.scss to the following:

.footer {

  width: 100%;
  height: 100px;
  border-top: 1px solid #eaeaea;
  display: flex;
  justify-content: center;
  align-items: center;

  img {
    margin-left: 0.5rem;
  }

  a {
    display: flex;
    justify-content: center;
    align-items: center;
  }

}

You can use the same nesting structure to update .title and .card.

We can also add the following to the top of our styles/Home.module.css file:

$color-primary: #0070f3;

And update all instances of the color in that file from #0070f3 to $color-primary:

.title {
  ...
  a {
    color: $color-primary;

If you reload the page, nothing will change. But update that variable to your favorite color like:

$color-primary: blueviolet;

And now all of the colors change.

Image Updated colors in the Next.js app

Finally, since we now have a Sass starter, let’s update the title of the page. Replace “Welcome to Next.js!” In pages/index.js to:

<h1 className={styles.title}>
  <a href="https://nextjs.org">Next.js</a> Sass Starter
</h1>

And now we have a Sass starting point!

Image Updated title in the Next.js app

Similar to before, you can test this out by creating a new project with your starter once all of the changes are on GitHub.

yarn create next-app [project-name] -e [GitHub URL]
# or
npx create-next-app [project-name] -e [GitHub URL]

Follow along with the commit!

Setting up Next.js Starter documentation for easy setup

Arguably one of the most important things about a Starter is documentation.

It might not be as important if you’re only using this yourself. But if you want other people to use it, you want them to know how to use it or else they’ll get stuck and become frustrated.

The most important part is getting the Starter set up. Setting up your Starter in a GitHub repo is a great first step. But if someone wants to use that Starter, they would have to clone or download that repo and then remove the git history.

Instead, you can add the command we used above in your README.me file to give people instructions on how to quickly get started, such as:

## Getting Started

Run the following command to create a new project with this Starter:

yarn create next-app [project-name] -e https://github.com...

or

npx create-next-app [project-name] -e https://github.com...

This will prevent people who might not understand how to do some of those things manually from getting stuck.

It’s also important to add any documentation of configuration options you’ve added.

If you’re adding some variables that allow you to change some site-wide features, make sure to add notes about those.

You ultimately want people to understand how to use the features you added to make their lives easier. If they don’t understand it, they may just rip that code out and do it manually.

Ultimately, creating and publishing a Starter is about making people’s lives easier. Whether it’s you coming back to your Starter a few months later or a swarm of new people looking to get productive, you’re giving them a better developer experience by adding good documentation.

Some other things to consider

Generalizing features and adding configuration for a Next.js Starter

Adding features is a great way to make a Starter more likely to be used. If I used a Starter to create a new blog, I would love if that Starter included my name as an author and maybe even an About Me page.

But what I wouldn’t want is to have to replace someone else’s name 100 times throughout the code to update my own project. Not to mention, seeing that name on the Starter might make me feel more like it’s their blog rather than a template I can use for my project.

Consider starting off by using a generalized name throughout the project. Instead of using Colby Fayock’s Blog throughout the Starter, make it My Blog, which will make it feel less personal to the creator for the person using the Starter.

Also add some configuration options. It’s much easier to be able to update a single variable that would make my project include Colby Fayock instead of My Blog than it is to search all files to make that change manually.

Choose carefully where to be opinionated

When using a tool like Sass, there is more than one way to use that tool. If you set up an incredibly specific and opinionated project structure, you’re alienating people using your Starter.

It'll either force them to rework the entire project or make them want to delete a bunch of code which might make them avoid wanting to use it in the future.

You can create opinionated Starters, but choose wisely where you inject those opinions. This will make your work usable by a larger group of people who want to be productive.

If you want to create something very opinionated, consider naming it something different and using the tool as part of the name. For example, I could create an opinionated Sass Starter called Colby’s Sassy Next.js Starter.

Did you create a new Starter?

Share with me on Twitter!

]]> <![CDATA[ CSS Preprocessors Explained ]]> https://www.freecodecamp.org/news/css-preprocessors/ 66c3485bd48c8b932b406b3e Fri, 17 Jan 2020 20:55:00 +0000 CSS Preprocessors are increasingly becoming a mainstay in the workflow of front end web developers. CSS is an incredibly complicated and nuanced language, and in an effort to make it’s usage easier, developers often turn to using preprocessors such as SASS or LESS.

CSS Preprocessors compile the code which is written using a special compiler. They then use that to create a CSS file, which can then be referenced by the main HTML document.

When using any CSS Preprocessor, you will be able to program in normal CSS just as you would if the preprocessor were not in place. The good thing is you also have more options available to you. Some, such as SASS, has specific style standards which are meant make the writing of the document even easier, such as the freedom to omit braces if you want.

Of course, CSS Preprocessors also offer other features as well. Many of the features offered are incredibly similar across preprocessors, with only slight variances in syntax. Thus, you can choose pretty much any one you wish, and you will be able to achieve the same things. Some of the more useful features are:

Variables

One of the most commonly used item in any programming language is the variable, something which CSS notably lacks. By having variables at your disposal, you may define a value once, and reuse if throughout the entire program. An example of this in SASS would be:

$yourcolor: #000056
.yourDiv {
  color: $yourcolor;
 }

By declaring the SASS yourcolor variable once, it is now possible to reuse this same exact color throughout the entire document without ever having to retype the definition.

Loops

Another common item in languages are loops, something else CSS lacks. Loops can be used to repeat the same instructions multiple times without having to be reentered multiple times. An example with SASS would be:

@for $vfoo 35px to 85px {
  .margin-#{vfoo} {
    margin: $vfoo 10px;
   }
 }

This loop saves us from having the to write the same code multiple times to change the margin size.

If/Else Statements

Yet another feature which CSS lacks are If/Else statements. These will run a set of instructions only if a given condition is true. An example of this in SASS would be:

@if width(body) > 500px {
  background color: blue;
 } else {
  background color: white;
 }

Here, the background color will change color depending on the width of the page’s body.

These are but a few of the major functions of CSS Preprocessors. As you can see, CSS Preprocessors are incredibly useful and versitile tools. Many web developers use them, and it is highly recommended to learn at least one of them.

More Information:

]]> <![CDATA[ Give your CSS superpowers by learning Sass ]]> https://www.freecodecamp.org/news/give-your-css-superpowers-by-learning-sass/ 66b202a0297cd6de0bd5463d Mon, 09 Sep 2019 14:08:01 +0000 Learn the basics of Sass in this free 2-hour video course from codeSTACKr.

The course starts with a brief overview of what Sass is along with what is required to incorporate Sass into your environment.

Then it covers how to set up a Sass compiler in Visual Studio Code.

You will learn all about:

  • Sass variables
  • maps
  • nesting
  • functions
  • mixins
  • extending
  • and operations.

After learning the basics, you'll see how to build a real-world project using Sass.

The course goes step-by-step through each part, including deploying the site.

You can watch the full video on the freeCodeCamp.org YouTube channel (2 hour watch).

]]> <![CDATA[ You Don't Need CSS-in-JS: Why (and When) I Use Stylesheets Instead ]]> https://www.freecodecamp.org/news/you-dont-need-css-in-js-why-i-use-stylesheets/ 66b8e3a668c5b9f37d1d1af3 Tue, 13 Aug 2019 14:30:00 +0000 CSS-in-JS is all the rage. But is it really the best option?

Solving problems you don’t need to solve

Don’t get me wrong, CSS-in-JS is a great solution, but it’s for a problem most people don’t have. Maintaining your components in a very siloed approach absolutely helps things like:

  • Unintentional side effects of cascading styles
  • Helping teams organize their rules
  • Avoiding stepping on each other’s toes while developing

But those really only become problems with large teams with many developers and a vast library of components.

So what do you want me to use?

To start from a slightly higher point of view, you can get in the habit of a few basic ideas:

  • Set and follow some basic rules for writing
  • Use tooling or set standards for organization
  • Developing with methodologies like BEM

This will eliminate any of those concerns on a smaller project (or large) and can actually make life easier.

What CSS-in-JS is good at…

Helping large teams preserve sanity

Part of why this solution exists is because very large teams have a hard time avoiding conflicts when they have a huge library to deal with. Being able to have your component and anything that impacts it in one compartmentalized area helps people avoid stepping on each other’s feet and potentially rolling out tweaks that unintentionally cascade throughout the app. This is great but more likely than not, you’re 1 of a few (or alone) working on a small app. If you and your team aren’t communicating about some basic rules and standards, I’d argue you have bigger problems.

Kind of eliminates the need to learn CSS (kind of)

Some developers mock CSS saying it’s not real code, others are scared about it’s magic (don’t be, embrace it). Only having to worry about a few rules in one component helps put people’s mind at ease knowing it’s just a little more JS that changes how it looks a bit.

What can both do?

Image CSS pointing at CSS

Hot Module Reloading (HMR)

Though some say an advantage to CSS-in-JS is HMR, you’ll find this works fine with stylesheets. Sometimes it actually works a little nicer if you’re working on a component that requires a rerender such as those with a network request as a dependency, where the CSS changes won’t force that rerender.

Variables, Global Settings

If someone is making an argument that CSS can’t do that, it’s because they haven’t been paying attention for a while. Not only does Sass provide this, it's native to modern browsers.

Encapsulation

Yes, you don’t need JS to do this. Add a class name to the top-level element of the component or page, nest all styles inside, and you have your encapsulation.

.page-about {
  .header {
    background-color: red;
  }
}

.navigation {
  .button {
    background-color: blue;
  }
}

Linting

https://stylelint.io/

A lot more

Honestly, there’s probably a lot more that both do similarly that you just don’t realize.

What stylesheets and SASS do better…

Rule sharing and configuration

SASS allows you to configure variables, custom functions, and mixins that take your CSS development to the next level.

Ignoring the bad selector names:

// settings.scss

$color-ultraviolet: #5F4B8B;

// colbys-styles.scss

@import "settings";

.colbys-text-color {
  color: $color-ultraviolet
}

.colbys-background-color {
  background-color: $color-ultraviolet
}

While the syntax and configuration of this are arguably easier than setting up a bunch of object configurations in JS, this greatly allows you to provide consistent visual experiences and DRY up your code.

Responsive design

One of the many things that add to the role of a good front end engineer is paying attention to how the project will look across multiple devices and sizes. Overall, UX is everyone’s job. Developing with a responsive-first mindset not only makes that process easier, it helps build a better product.

Trying to make your components responsive in JS means more Javascript and more event listeners. Not only does this add complexity, it hits performance. We can do this much easier with media queries baked right into CSS.

.colbys-sidebar {
  width: 100%;
}

// NO EVENT LISTENERS

@media (min-width: 1024px) {
  .colbys-sidebar {
    width: 25%;
  }
}

Instead of having to throttle the event listeners, making sure your event listeners unregister on unmount, and just dealing with organizing that all in “the react way”, media queries trigger on-demand and will flip your styles as needed in a more consistent manner.

Less complexity of your components

Being able to focus on the functionality and the rendered output allows you to avoid pulling in libraries or complex methods to essentially patch CSS into your JS, not to mention the JS hack or two or three that you’re using to get it working in the first place.

// This is an exaggeration

const styles = {
  color: blue;
}

if ( whos_favorite === 'Colby' || whos_favorite === 'Lord Commander' ) {
  styles.color = 'ultraviolet';
} else if ( whos_favorite === 'The Gary' ) {
  styles.color = 'red';
} else if ( whos_favorite === 'Mooncake' ) {
  styles.color = 'green';
} else if ( whos_favorite === 'HUE' ) {
  styles.color = 'blue';
} else if ( whos_favorite === 'KVN' ) {
  styles.color = 'yellow';
}

<MyCompnent styles={styles} />

Performance

Less Javascript is always a win. It’s less your browser has to load, less your browser has to compile, which will ultimately translate to quicker page speed. When the browser loads a page, it tries to optimize the HTML and CSS as much as possible. Yes, you probably are loading more CSS upfront, but more JS is very costly and also is more likely to force a full rerender;

A lot of the little magic bits you do with Javascript can be done with some pretty powerful CSS animation methods, just browse Codepen a bit or check out something like Animista.

I don’t actually have any numbers on this aside from a few good notes and some CSS-in-JS benchmarks. Has anyone done the legwork on this?

At the end of the day, do what’s effective

Image

Everyone has a personal preference, everyone is productive in a different way. Do what’s best for you, do what’s best for your team, and avoid treating what other developers say as dogmatic rights and wrongs.

If you’re a lone developer on a project and want to practice CSS-in-JS to get used to it for when you’re on a big team, go for it! If you’re on a huge, huge team at Facebook and want to use stylesheets, well you might run into issues if everyone’s not following the same guidelines, but do what’s best for you and your team.

The only way you can figure that out is with experience and experimentation. Play with both solutions and figure out why YOU think one is better than the other. You never know where you’ll end up after landing that gig at Google or your new startup in your garage.

Originally published at https://www.colbyfayock.com/2019/07/you-dont-need-css-in-js-why-i-use-stylesheets.

]]> <![CDATA[ Up & Going with Nuxt.js, Bulma and Sass ]]> https://www.freecodecamp.org/news/up-goind-with-nuxt-js-bulma-and-sass/ 66d45f0b3a8352b6c5a2aa5b Sat, 15 Jun 2019 11:09:27 +0000 By Eduardo Vedes

TL;DR: Overcome Nuxt.js, Bulma and Sass shenanigans with this quick article to help you start developing your next App in less than 10 minutes.

Hi everyone ❤️! Few days ago I found myself struggling a bit to put Nuxt.js, Bulma and Sass to work correctly and the info I found on google didn't help too much.

Most of the configurations I found were not working, because they were outdated or didn't explain quite well how to do it. So I deep dived a little bit on this subject and decided to write an article to help you do the same in less than 10 minutes.

Let's have some fun and get our hands dirty while grokking a few concepts needed to do this.

1. Scaffolding Nuxt.js

Nowadays, to get started quickly with Nuxt.js we use a scaffolding tool called create-nuxt-app. Please make sure you have npx installed on your machine.

Let's open a terminal and do: npx create-nuxt-app nuxt-bulma-sass, where nuxt-bulma-sass is the name of the project we're scaffolding for the purpose of this article.

create-nuxt-app will ask you some questions before creating the scaffold. For the purpose of this article I've chosen the following setup:

Image create-nuxt-app init questions

So, the next step will be to change directory into our project folder:

cd nuxt-bulma-sass

and launch the project with: yarn run dev. (you can also use npm if you like it)

At this point we have our project running:

Image

And if we open our browser on localhost:3000 we'll be getting this screen:

Image localhost:3000 pages/index.vue

So at this point we have the pages/index.vue on the screen, which is the first page to be rendered in your project by default.

Let's replace the content of this file by the following one:

Image

If we inspect our page in the browser we see we got bulma installed because section is formatted according to it.

Image

Easy peasy lemon squeezy.

Let's add a class and choose some colors:

Image

Image

What if we want to nest .hello-nuxt inside .edo-theme? We're going to need SASS to be able to do it.

2. Adding Sass

So, to add Sass to our project we'll need to stop our running app (Ctrl+c) and do the following:

yarn add node-sass sass-loader --dev

These are the two packages needed as dev-dependencies to be able to have Sass in our boilerplate.

Note that we're adding it as a dev dependency because we only need it while developing and at build time. After that Sass is transformed into CSS and we don't need it anymore.

Let's sneak peek my package.json for you to check it:

Image package.json with sass added to the project

Okay everyone ❤️, at this point we're able to nest the classes we wanted to.

Let's run our boilerplate again: yarn run dev and do the tweaks needed ?

Image

Image

Noice! We already did a lot today! Go grab a coffee ☕, I'll wait for you here ?

Okay, let's abstract things a bit and create this file ~/assets/scss/main.scss and put there some classes and variables:

Image new ~/assets/scss/main.scss

Image

Nice! It's working!

Now we have two problems:

  1. We need to import main.scss into each one of our pages/components, which is not nice. We want to import it only once and have it available in all our
]]> <![CDATA[ Ember QuickTips: How to breakup and import SASS/CSS files separately ]]> https://www.freecodecamp.org/news/ember-quicktips-how-to-breakup-and-import-sass-css-files-separately-b0759459027d/ 66d46042f855545810e934a5 Fri, 11 Jan 2019 17:50:43 +0000 By Michael Xavier

There are times when it’s desirable to break up your stylesheets into multiple files and import them into your project separately. This came up in a side project I started recently, and I thought y’all might benefit from what I came up with as a solution. It’s a quick and easy method, so let’s get started ?

When you begin a new EmberJS app you’ll notice that the index.html file imports the main stylesheet into the app like so:

<head>
 ...
 <link
  integrity=""
  rel="stylesheet"
  href="{{rootURL}}assets/test-app.css"
 >
 ...
</head>

test-app.css is compiled directly from your project. When we write our custom styles in app/styles/app.css they get put into this file.

Now, what if we don’t want to import all of our styles into the app as a single stylesheet? How can we breakup our styles and import multiple stylesheets into the app? Something like this:

<head>
 ...
 <link
  integrity=""
  rel="stylesheet"
  href="{{rootURL}}assets/test-app.css"
 >
 <link
  integrity=""
  rel="stylesheet"
  href="{{rootURL}}assets/second-stylesheet.css"
 >
...
</head>

It may be easier than you think ?

Step One: Write styles in SCSS/SASS and compile to CSS

First, install a SASS preprocessor to compile SCSS/SASS stylesheets into CSS stylesheets. For this example I’ll use ember-cli-sass:

ember install ember-cli-sass

Now rename app/styles/app.css to app/styles/app.scss. The preprocessor will take care of processing and compiling your stylesheet automatically.

If you run the app the Ember welcome page should display as usual:

Image Nothing has changed. That’s good.

Comment out {{welcome-page}} in app/templates/application.hbs before you continue. We now have a blank DOM to work with.

Step Two: Create a new stylesheet

Let’s create a new stylesheet called app/styles/second-stylesheet.scss and add the following styles:

body {
 width: 100vw;
 height: 100vh;
 background-color: red;
}

A glaring red background would be very obvious, yet when you run the server you see nothing but a sea of white. Why is this?

If your instinct was to import it into the project as specified above, you would be correct:

<head>
 ...
 <link
  integrity=""
  rel="stylesheet"
  href="{{rootURL}}assets/second-stylesheet.css"
 >
...
</head>

Yet, it still doesn’t show up. Why? ? That’s because the build pipeline hasn’t been configured to build this file in the correct folder just yet.

Step Three: Configure Ember-CLI-Build

The final step is to tell the Ember app that you have a css file to include in its build pipeline.

In ember-cli-build.js add the following:

...
module.exports = function(defaults) {
  let app = new EmberApp(defaults, {
    // Add options here
    outputPaths: {
      app: {
        css: {
          'second-stylesheet': '/assets/second-stylesheet.css'
        }
      }
    }

  });
  ...
};

That’s it! ? This tells Ember where to output your new stylesheet so that it can be properly accessed in your index.html ?

Image A Sea of Red. Remember to restart the server when you make configuration changes or you may not see the changes.

]]> <![CDATA[ A Learning Path for Newbies in WordPress Development ]]> https://www.freecodecamp.org/news/learning-path-for-newbies-in-wordpress-development-a283981adf53/ 66d45f32b6b7f664236cbdcc Wed, 12 Sep 2018 18:46:58 +0000 By Ihtisham Zahoor

In this information age, one obstacle in learning something new is not where to find the resources. It’s from where to start and make sense of all the resources available online these days. This holds especially true in web development when new tools are popping up overnight.

Back in 2015, since I first decided to learn web development, I have faced challenges of self-doubt and lack of motivation. But the one challenge which drained my energies was not knowing what path to follow.

Considering the initial challenges in this path I have written this piece for technology enthusiasts who want to get their hands dirty in web development. Especially WordPress development. All in the hope you are going to spend your time building something cool than getting into this never-ending vicious cycle of learning one tool to another.

Caution! A lot of learning in this path

I am a WordPress developer (although my impostor syndrome tells me otherwise). I can share my experience only related to WordPress. But before diving into details, let’s examine a Q/A session first.

Image

Now, is the answer mean? Maybe. Is it true? Absolutely! WordPress and Web Development, in general, are as serious and demanding as any profession. So be ready for…

  • Lifetime of Learning
  • Pulling all-nighters occasionally

All right, have you read and understood the above points? Great. Now relax as it is not to discourage you or anything. It’s just how the life of a developer is as the ever-changing nature of this field requires.

The good news is there are not many web technologies you have to learn to master the craft of WordPress Development. That being said, give your time to this amazing piece of software, and WordPress will adore you in return.

WordPress will change your life if you let it — Chris Lema

It’s all inspiring and cute, right? It is one of the reasons Topher DeRosia (huge props) has provided the HeroPress platform for WordPressers (yes, this is what we proudly call ourselves). Here WordPressers share regularly their WordPress origin stories with the community. Rest assured while reading through the stories you are going to feel adrenaline rush through your body as many of you are going to find yourself related to those stories.

WordPress for Everyone!

WordPress is super easy to use. In fact, anyone without any technical knowledge, can set up and start using WordPress in no time. However, WordPress has a vast ecosystem. I, for one, would categorize WordPress development being carried out in two different domains. I’ll first list those domains below and then I will discuss each one separately.

  • WordPress Site Customization
  • WordPress Themes/Plugins Development

WordPress Site Customization

WordPress Site Customization is where all the buzz is about, as it amounts for most of the work done with respect to WordPress usage. Site Customization is that domain where no prior coding knowledge is required.

That is to say, a WordPress power user can easily perform tasks like Theme/Plugin setup and customization using page builders, site debugging, and site maintenance, etc. Moreover, Theme customization is all about customizing or modifying a pre-made theme as per the requirements of your client.

Considering that, and to give you a perspective about the process, you can watch the following short tutorial by Tyler Moore. In his tutorial, he builds a new website by customizing a pre-made theme using the Elementor page builder.

WordPress Themes/Plugins Development

It is where all the fun is for WordPress geeks. We can call it the actual WordPress development, as this domain is all about knowing and getting into the nitty-gritty technical details of programming. It can be as simple as using a few WordPress hooks to modify responses or as complex as building a full-fledge product on WordPress.

So, in case you want to start into this domain, you have to invest more time learning about web technologies involved in WordPress development. Considering that, the rest of this article will discuss all the technologies and a few tips and tricks to get you started in actual WordPress development.

Learning Path

To get started in your WordPress Development journey, these tools and technologies are what you are going to be working with.

  1. Say hello and embrace g̵o̵o̵d̵ ̵o̵̵̵l̵̵̵’ HTML5 modules with Semantics and Accessibility concepts. HTML is what gives structure to the site contents.

  2. This quote says it all:

You are the CSS to my HTML — Some Genius

CSS is how HTML is presented in the web browser. Make sure to learn SASS preprocessor as your savior in writing modular CSS once you get a grasp of the basics.

  1. The organization behind WordPress has big plans for making JavaScript part of the WordPress Front-end. This officially came from the original author of WordPress.

Learn JavaScript, Deeply — Matt Mullenweg

Yes, I know that might be far-fetched for a newbie who is starting out to follow this advice, but keep an eye out for development in this area. Now, this doesn’t mean you have to master JavaScript to work with WordPress. Start with the basics including its hugely popular library jQuery.

  1. Wouldn’t it be nice if you could get a 1000-step head-start with these three technologies to speed up your development process? Well, that is where front-end frameworks like Twitter Bootstrap come into play. Explore it and get amazed. Don’t confuse front-end frameworks with JavaScript frameworks. Front-end is used interchangeably with JavaScript libraries and frameworks, which is a whole different path.

  2. PHP is the scripting language that powers WordPress. If you want to dive deep in WordPress, learn PHP head-first with its OOP concepts including MySQL as its back-end database.

  3. In general, when people talk about WordPress Development, it usually means only two segments of WordPress.

  4. WordPress Theme Development, which is developing a presentation (layout) of sites (hence the name “Theme”).

  5. WordPress Plugin Development, which is to add functionality to WordPress sites

For a developer, it is of utmost importance to understand and be comfortable working with both these segments. And to add a tad bit more in your learning journey, get familiar with Internationalization and Localization. You also need to know WordPress Hooks and APIs to name a few.

While developing sites, most of your time is going to be spent in a local development environment and in a code editor. For the sake of complete information in this article, let me point you to an easy-to-setup yet powerful local development environment (Local by Flywheel) and lightning-fast code editor (Visual Studio Code by Microsoft). Yes, they are both free of cost like WordPress.

Workflow

As your workflow becomes more advanced and complex, it’s important for you to stay sane and keep enjoying life. In that case, you are going to need to streamline your workflow. Try task automation tools like Grunt/Gulp and use a version control system like git to keep you from making blunders.

Illustration of Learning Path Guide Published on GitHub

To make things more clear for you, I have published an illustration of the Learning Path as a step-by-step guide on GitHub which I have provided below.

Image

Learn from it, give feedback, improve it to make it better for newbies, and by that means feel free to send PR requests.

Resources

In case you are still worried that you are going to need more than a bunch of motivational words to actually start doing meaningful work, maybe you need like a step by step guide — well, worry no more. Follow the WordPress WordPress Developer Handbook and WordPress Developer Codex like religion and consider yourself in safe hands.

Moreover, you can receive great help from the WordPress Support forum as well as digging your answers from the Q&A site Stack Overflow, which is immensely popular among the developer community.

Apart, from the official WordPress resources, support forum, and developer-centric Q&A sites. There are a plethora of sites like WPBeginner, made possible by the awesome WordPress community, offering WordPress centric free tutorials and guides.

CodexSpot is one such attempt by a bunch of WordPress geeks including yours truly to give back to the community. CodexSpot is an online platform, focused solely on providing web solutions. Our aim is to provide quality tutorials, DIY guides, and keep you up-to-date with web industry news and trend reports.

We are a huge supporter of free and open-source software initiative and don’t miss any opportunity to evangelize FOSS practices to promote this movement. Besides that, we also offer free web development generators and tools to speed up your development time.

Now, there is one other type of learning resource, which is premium courses. By comparison with free resources, the main benefit of premium ones is the timely support offered by the course instructors for their students. That is to say, the ability to get your queries answered by the very instructors from whom you are learning, hugely benefits you during your learning journey. Furthermore, they stay on top of the latest industry trends.

I have personally learned a great deal from the Lynda.com (now LinkedIn Learning) courses, highly recommended. I have also found Learn WordPress course by Chris Castiglione, a nice beginner-friendly course to start with. So, if you are looking for a premium course on WordPress, you will find any of these courses worth your buck.

At this point, you have the dedication and tons of resources readily available for you to learn everything about WordPress. However, it is equally important that you understand the job market and what the companies seek in candidates applying for the WordPress developer position.

Toptal, an exclusive network of the top freelancers in the world, has published a guide for hiring a “Great WordPress Developer” which you can read to better align yourself with the most in-demand WordPress skills.

Conclusion

Don’t try to learn everything at once. Start with the basics. Implement what you’ve learned and then build from there. Take note of these following two not hard-and-fast rules for guidance, as these rules will come in handy in your journey.

  • Just in Time (JIT) learning is you learn the tool when you need it.
  • 80/20 rule of learning is you give 20% of your time to learning and 80% of your time implementing what you have learned already.

Now repeat after me:

I learn.
I code!
I code again!!
I code some more!!!
I keep coding!!!!!

…and that is how you start in WordPress. Good Luck WordPresser and welcome to the WordPress family!

]]> <![CDATA[ How to compile Sass files in Visual Studio and Webpack ]]> https://www.freecodecamp.org/news/how-to-compile-sass-files-in-visual-studio-and-webpack-6e45cdc1c14c/ 66d45e3c9208fb118cc6cf8f Fri, 07 Sep 2018 16:38:25 +0000 By Esau Silva

Sass is a very popular CSS pre-processor. The intent of this tutorial is to show you how to compile Sass files within Visual Studio using Webpack. Our discussion will include minification and autoprefixing for production.

Image Visual Studio meets Sass

Sure, there are some plug-ins in the Visual Studio Marketplace, and it can be nice to just install a plug-in and forget about configuration. But what happens if the plug-in is not supported anymore and stops working with newer Visual Studio versions? Well, too bad. This is the case with one of the most popular compiler plug-ins on the market.

By configuring the compilation yourself, you will have total control over the output. Also, vendor prefixes will be added automatically to your CSS rules. How cool is that?

Prerequisites

You will need to have Node installed, and you can grab it here. That’s it really. You’ll also need npm, but it will also be installed with Node.

Creating the Project

Note: We will be creating a .NET Core MVC app, but the same principles apply to any ASP.NET MVC app. You would just need to modify the Webpack configuration a little bit to output the CSS file to the Content directory.

Open Visual Studio and create a new ASP.NET Core Web Application, then select Web Application (Model-View-Controller). I’m naming my project netcore-sass-webpack.

Image Creating the project

Create a Styles folder within the root of the project. Inside it, create a Sass file and name it site.scss. Open this new Sass file and copy the following:

/* Please see documentation at https://docs.microsoft.com/aspnet/core/client-side/bundling-and-minification\ 
for details on configuring this project to bundle and minify static web assets. */
body {
    padding-top: 50px;
    padding-bottom: 20px;
    background: #D69655 url('../wwwroot/images/pattern.png') repeat;
}

/* Wrapping element */
/* Set some basic padding to keep content from hitting the edges */
.body-content {
    padding-left: 15px;
    padding-right: 15px;
}

/* Carousel */
.carousel-caption p {
    font-size: 20px;
    line-height: 1.4;
}

/* Make .svg files in the carousel display properly in older browsers */
.carousel-inner .item img[src$=".svg"] {
    width: 100%;
}

/* QR code generator */
#qrCode {
    margin: 15px;
}

/* Hide/rearrange for smaller screens */
@media screen and (max-width: 767px) {
    /* Hide captions */
    .carousel-caption {
        display: none;
    }
}

You will notice that this is the same CSS provided by Visual Studio when we created the project, with the exception of the background rule in the body tag. Now delete the provided CSS located under wwwroot/css (both files: site.css and site.min.css). Don’t worry, we will auto-generate these with Webpack.

Now, download pattern.png and place it under wwwroot/images.

Create an empty JavaScript file under the root of the application and name it webpack.config.js. We will take care of this later. You should end up with the following project structure:

Image Project Structure

Note: You don’t need to do the following two steps for every project, just once (unless you un-install and re-install Visual Studio).

You will need to provide Visual Studio with the Node installation path. Go back to your project and select Tools -> Options on the left pane Projects and Solutions -> Web Package Management and add the path to Node installation at the top of the list ( C:\Program Files\nodejs or C:\Program Files (x86)\nodejs, depending if you installed the x64 or x86 version).

Image Node path

Finally download NPM Task Runner and install it — but you will need to close Visual Studio first.

Webpack and NPM Dependencies

Open Command Prompt and navigate to the root of the project and install the needed dependencies:

cd netcore-sass-webpack\netcore-sass-webpack
npm init -y
npm i -D webpack webpack-cli node-sass postcss-loader postcss-preset-env sass-loader css-loader cssnano mini-css-extract-plugin cross-env file-loader

The first npm command initializes your package.json and the second installs your dependencies.

  • webpack, webpack-cli — Module bundler
  • node-sass — Bindings for Node to LibSass; provides support for Sass
  • postcss-loader, postcss-preset-env — PostCSS loader for Webpack to process autoprefixing and minification
  • sass-loader, css-loader — Webpack needs specific loaders to support Sass and CSS
  • cssnano — CSS minifier
  • mini-css-extract-plugin — Extracts the CSS to a separate file
  • cross-env — Provides support to Windows users for environment variables. We will use NODE_ENVenvironment variable
  • file-loader — Provides support for files (images) in our CSS rules

At this point you can re-open the project in Visual Studio. After the project finishes loading, open package.json and add the following scripts:

"scripts": {
    "dev": "webpack --watch",
    "build": "cross-env NODE_ENV=production webpack"
  },
  • dev — We will bind this script whenever the project opens, and Webpack will continually watch for changes to the source Sass files, compile them, and output the separate CSS file
  • build — We will bind this script before each project build and will produce the production CSS file, including minification and autoprefixing

Note: The NPM scripts will run automatically using the Task Runner window. More on that later.

It is time to work on our Webpack configuration. Open webpack.config.js and copy the following:

const path = require("path");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const postcssPresetEnv = require("postcss-preset-env");
// We are getting 'process.env.NODE_ENV' from the NPM scripts
// Remember the 'dev' script?
const devMode = process.env.NODE_ENV !== "production";
module.exports = {
  // Tells Webpack which built-in optimizations to use
  // If you leave this out, Webpack will default to 'production'
  mode: devMode ? "development" : "production",
// Webpack needs to know where to start the bundling process,
  // so we define the Sass file under './Styles' directory
  entry: ["./Styles/site.scss"],
// This is where we define the path where Webpack will place
  // a bundled JS file. Webpack needs to produce this file,
  // but for our purposes you can ignore it
  output: {
    path: path.resolve(__dirname, "wwwroot"),
// Specify the base path for all the styles within your
    // application. This is relative to the output path, so in
    // our case it will be './wwwroot/css'
    publicPath: "/css",
// The name of the output bundle. Path is also relative
    // to the output path, so './wwwroot/js'
    filename: "js/sass.js"
  },
  module: {
    // Array of rules that tells Webpack how the modules (output)
    // will be created
    rules: [
      {
        // Look for Sass files and process them according to the
        // rules specified in the different loaders
        test: /\.(sa|sc)ss$/,
// Use the following loaders from right-to-left, so it will
        // use sass-loader first and ending with MiniCssExtractPlugin
        use: [
          {
            // Extracts the CSS into a separate file and uses the
            // defined configurations in the 'plugins' section
            loader: MiniCssExtractPlugin.loader
          },
          {
            // Interprets CSS
            loader: "css-loader",
            options: {
              importLoaders: 2
            }
          },
          {
            // Use PostCSS to minify and autoprefix with vendor rules
            // for older browser compatibility
            loader: "postcss-loader",
            options: {
              ident: "postcss",
// We instruct PostCSS to autoprefix and minimize our
              // CSS when in production mode, otherwise don't do
              // anything.
              plugins: devMode
                ? () => []
                : () => [
                    postcssPresetEnv({
                      // Compile our CSS code to support browsers
                      // that are used in more than 1% of the
                      // global market browser share. You can modify
                      // the target browsers according to your needs
                      // by using supported queries.
                      // https://github.com/browserslist/browserslist#queries
                      browsers: [">1%"]
                    }),
                    require("cssnano")()
                  ]
            }
          },
          {
            // Adds support for Sass files, if using Less, then
            // use the less-loader
            loader: "sass-loader"
          }
        ]
      },
      {
        // Adds support to load images in your CSS rules. It looks for
        // .png, .jpg, .jpeg and .gif
        test: /\.(png|jpe?g|gif)$/,
        use: [
          {
            loader: "file-loader",
            options: {
              // The image will be named with the original name and
              // extension
              name: "[name].[ext]",
// Indicates where the images are stored and will use
              // this path when generating the CSS files.
              // Example, in site.scss I have
              // url('../wwwroot/images/pattern.png') and when generating
              // the CSS file, file-loader will output as
              // url(../images/pattern.png), which is relative
              // to '/css/site.css'
              publicPath: "../images",
// When this option is 'true', the loader will emit the
              // image to output.path
              emitFile: false
            }
          }
        ]
      }
    ]
  },
  plugins: [
    // Configuration options for MiniCssExtractPlugin. Here I'm only
    // indicating what the CSS output file name should be and
    // the location
    new MiniCssExtractPlugin({
      filename: devMode ? "css/site.css" : "css/site.min.css"
    })
  ]
};

Refer to the comments in the code to understand the configuration. (More readable file here.)

Now we need to create some bindings in Task Runner Explorer. Navigate to View -> Other Windows -> Task Runner Explorer. The window will show at the bottom and you will see the scripts you created in package.json listed there under Custom. You will also see some tasks under Defaults, but you can just ignore them.

We need two bindings:

  • Right click build -> Bindings -> Before Build — Visual Studio will run this task before each build. Remember this npm script runs Webpack for production and will optimize the CSS file.
  • Right click dev -> Bindings -> Project Open — Visual Studio will run this task when you open the project. Remember this npm script runs Webpack in watch mode and will watch for any changes in your Sass files and output the processed CSS file.

Task Runner Explorer should look like this:

Image Task Runner Explorer

Note: For some reason, Visual Studio sometimes will fail to start the dev task upon opening the project. If that happens, just open the Task Explorer and run the task manually.

You can get the full code from the GitHub repository.

Final Thoughts

And that’s all there is too it. Since you already have Visual Studio open, none of the tasks are running. Go ahead and right click the dev task and select run. You will see the task loading and when it finishes you will see that a site.css file was created under wwwroot/css directory. Open site.scss, make a change and save it. Now open site.css, you will see your change reflected there. Cool!!

Run your project by pressing Ctrl + F5, you will see a site.min.css file created under wwwroot/css directory. This file was created when Task Runner ran the build script before it built the project.

The final site should look like this:

Image Final site

I know, I know, the background is very cheesey…but I needed an image to show the Webpack file-loader in action.

With this configuration, you can even add support to transpile modern JavaScript (ES6+) to ES5. Look into these: @babel/core, babel-loader, @babel/preset-env.

Thank you for reading, and I hope you enjoyed it. If you have any questions, suggestions, or corrections let me know in the comments below. Don’t forget to give this article a share, and you can follow me on Twitter, GitHub, Medium, LinkedIn.

You can also visit my personal blogging site.

Update 8/25/19: I have been building a prayer web app called "My Quiet Time - A Prayer Journal". If you would like to stay in the loop please sign up through the following link: http://b.link/mqt

The app will be released before the end of the year, I have big plans for this app. To see some mockup screenshots follow the following link: http://pc.cd/Lpy7

My DMs on Twitter are open if you have any questions regarding the app ?

]]> <![CDATA[ Sass — a preprocessor for your web garnishes ]]> https://www.freecodecamp.org/news/give-more-oompf-to-your-web-garnishes-with-preprocessors-in-sass-bd379226a114/ 66d45dd5182810487e0ce0f3 Wed, 27 Jun 2018 23:31:24 +0000 By Chandrabhan Singh

Importance of aesthetics, its impact, and tool to achieve it.

I remember as a child, every time I’d walk up to a bakery, I’d choose the pastries with the most beautiful toppings. Only after having the first bite would I know if it was the one I was longing for.

A well-plated dish can trump taste at times. The tendency to pick on appearance has a significant impact on our choices. This inclination towards plating is not only confined to food. Trendy clothes, a decorated apartment, and a well-designed car are a few examples.

A master chef understands the importance of presentation for a successful restaurant. The art of garnishing can differentiate a culinary masterpiece from a novice’s plate. Moreover, a creative plating would add pleasure and taste, encouraging customers to pay frequent visits. The web is no different from any gourmet meal in this sense. Visual impact has had a crucial role in all successful web applications, too.

You need to make significant efforts to make web applications look pleasant. This is where Cascade Style Sheets (CSS) come in.

As the web evolves, applications grow bigger and bigger. To match our needs, we need more from CSS out of the box. But CSS has some limitations.

Since you’re reading this article, you’ve already finished the toppings, and now is the time to taste the rest of the cake. Let’s see what limitations CSS has and how we can overcome them. The goal is to take your plating technique to the next level.

Prerequisites

You need to have a fair understanding of CSS and CSS selectors. You’ll also need Node.js and npm installed.

CSS Limitations

Identifying limitations is subjective, though I would like to mention a few.

  1. Programming mechanism: Features like variables, functions, classes, and operators are missing in CSS3 itself.
  2. Lengthy CSS file: In rich user interface applications, style sheets may grow overnight. Large files can be a nightmare for maintenance.
  3. Absent math operators: Math operators like +, -, *, / can be very handy at times.

To overcome such limitations, we have preprocessor scripting languages.

The preprocessor

A Preprocessor is a piece of software which takes an input file written in some programming language and processes it to produce a file following syntax of another language. It is used to extend the syntax of an existing programming language by adding new functionality to it.

Image illustration: Sass preprocessor

A CSS preprocessor extends the CSS syntax by adding a programming mechanism to it. SassScript is a superset of CSS. When compiled, it creates valid CSS blocks for your web applications.

There are a few CSS preprocessors available like Less, Stylus, and Sass. Our focus will be on Sass ( Syntactically-awesome style sheets). But the concept is more or less the same for other preprocessors.

We will go through the installation of a Node.js Sass compiler, and later we’ll see various Sass features in action. So, get ready to garnish your delicious web recipes ?.

Preparing Sass

Sass was first written in Ruby and then in other languages. You can choose from many available implementations. For this article, we will stick to a Node.js package — node-sass. This package uses high-performance Sass implementation in C called libSassSass.

First things first: Let’s install node-sass. Then we will set up a sample application to see various Sass features in action. Open a terminal on your machine and execute the below command.

npm install node-sass -g

Here we are asking node package manager to install node-sass for us. With flag -g, we installed the package globally. Great! Once it finishes, make sure everything is in place.

node-sass -v

Image command to check node-sass version.

Okay! We have all the ingredients we may need. Let’s see what flavors Sass comes with, and afterward we will start our journey to explore Sass.

Various flavors of Sass

There are two ways of creating a Sass file. You can use either of these two syntaxes.

  1. Sass style: This syntax uses indentation to separate code blocks and new lines.
  2. SCSS style: This syntax uses blocks like a programming language. We’ll use SCSS syntax in this article.

Note: It’s possible to convert from one syntax to another by a simple Sass convert command. Feel free to adopt the one you like.

Preparing the main dish

As we are Sass-ready on our machine, we can start playing around to see what great features it can bring to us. Follow along with me to set up a sample application.

Here I am using Visual Studio Code. You can use any code editor of your choice. I have been using it for a long time and I would recommend it. It has some cool productivity plugins that can be of great help.

Image

So far, we have created a folder and two files.

  1. index.html: an HTML file.
  2. style.scss: root (or main) Sass script file.

To start, let’s create a div, an h1, and two buttons in the HTML file.

Image

Let’s iterate through the most used Sass features. On the way, we will also see the compiled CSS blocks.

Variables

Variables help you centralize CSS properties. You can assign them once at the top of a file and use them throughout the file. These variables are like placeholders for a CSS property’s value. In Sass, a variable name must start with a $ sign.

We are going to create two variables: $h1-color and $h1-height. Then we will use these variables to assign color and height properties to an h1 element. Below is the Sass snippet.

$h1-color     : blue;
$h1-height    : 50px;
h1{
   color  : $h1-color;
   height : $h1-height;
}

All right! We have an HTML file and a Sass file so far. What about the CSS file? It hasn’t appeared yet.

Well, we are almost there. Open your terminal to go to the folder we created and execute the command below:

node-sass style.scss style.css

The parameters for the node-sass compiler are input and output file path. Now if you open the HTML we created during project setup in a browser, you should see the following.

Image HTML with CSS applied

Notice that the CSS file is already included in the HTML’s headsection.

Operators

Mathematical operators were always missed in CSS. Sass provides basic math operators like addition +, subtraction -, multiplication * and division/.

You can use variables and operators together to manipulate CSS properties. Let’s take an example. We can use operators to calculate padding for an h1 element depending upon the width of its parent div. We will use the divide operator / for this example.

$h1-color   : blue;
$h1-font    : 50px;
$div-width  : 500px;
div{
   width: $div-width;
}
h1{
   color       :  $h1-color;
   height      :  $h1-font;
   padding     :  $div-width / 10;
}

Mixins

Mixins are like abstract base classes. Mixins are handy to group related properties. Once created, these mixins can be reused in the rest of the style blocks. Moreover, you can even pass variables. Confusing? Let’s take an example.

You must have noticed that creating a style for border-radius is always quite messy. For cross-browser support, we must use vendor-specific properties. However, with mixins, it can be super easy. Let’s see it happen.

@mixin border-radius($radius){
   -webkit-border-radius   : $radius;
   -moz-border-radius      : $radius;
   -ms-border-radius       : $radius;
   border-radius           : $radius;
}
div{
   width    : $div-width;
   border   : 2px solid grey;
   @include border-radius(20px);
}

Here we used the @mixin directive to define a mixin named border-radius. This mixin contains all the possible properties to set the radius of a border. We also passed a parameter to this mixin. Whenever you need to set the radius of an element, include this mixin with the @include keyword.

Compile the script once again to generate the CSS. How does it look now?

//Processed CSS output
div {
   width: 500px;
   border: 2px solid grey;
   -webkit-border-radius: 20px;
   -moz-border-radius: 20px;
   -ms-border-radius: 20px;
   border-radius: 20px; 
}

Nesting

HTML elements have a logical tree-like structure with nested elements. To write structured CSS selectors, CSS should also follow some logical nesting. Yet, CSS does not support nesting.

Since you have Sass on your machine, writing nested CSS selectors is a piece of cake.

div{
   >h1{
      color: blue;
      &:hover{
         color: greenyellow;
      }
   }
}

Here we used two combinators, &gt; and &. The purpose of a combinator is to explain the relationship between the elements. Our example will apply blue color to all h1 children of a div element. Another selector is the parent selector &. Use this selector for pseudo-classes like hover, focus, and active.

Compile once again to see the generated CSS blocks.

//Processed CSS output
div h1 {
   color: blue;
}
div h1:hover {
   color: greenyellow;
}

Inheritance:

Yes — you can use the most popular OOP feature in Sass as well. Accruing the properties of one’s parent is Inheritance. But does it make any sense in CSS? And can we use them? We can! Believe me, and, I am sure you will adore this feature.

Consider an application where you have various types of buttons. Save, Cancel, and Discard to name a few. You realize they share most of their characteristics. For example padding, font-size, margin. The only difference is the background color.

Does it smell like inheritance? Yeah— You guessed it right! We can create a parent style for all these common properties and use them in child blocks.

%common-button{
   padding: 16px 8px;
   border: none;
   font-size: 18px;
}
.save{
   @extend %common-button;
   background-color: blue;
   color: white;
}
.cancel{
   @extend %common-button;
   background-color: goldenrod;
   color: white;
}

Here, the save and cancel buttons inherited their common properties from the common-button class. To declare a parent style, use the % sign. Use the @extend directive to inherit a child block.

Import

We have seen many amazing features that Sass provides. We were able to make styles more readable and structured. Still, it can grow and become hard to maintain.

Sass has a solution to this problem as well: a partial file. A partial file is a way to create small modular Sass files. The root Sass file can then import these modular files altogether. The naming convention for partial files is to prefix the file name with an underscore _.

Image

@import '_buttonpartial';
h1{
   color:blue;
}

Use the @import directive to include a partial file in the root Sass script.

Loop

Iteration is one of the most frequently used programming mechanisms. Sass script allows you to iterate over variables. You can use various directives like @for, @each and @while.

$totalButton: 2;
@for $i from 1 through $totalButton{
   .button-#{$i} {
      width: 50px * $i;
      height: 120px / $i;
   }
}

The generated CSS block will have two classes with different styles.

//Processed CSS output
.button-1 {
  width: 50px;
  height: 120px; }
.button-2 {
  width: 100px;
  height: 60px; }

Avoid repeating — use a food processor

A food processor is a kitchen appliance used to facilitate repetitive tasks in the preparation of food.

We have used a Node.js package for compiling Sass files. It can be very annoying if you have to compile every time you make a change in the Sass script.

There is a fancy way to avoid repetitive compiling: a task runner. Visual Studio Code has a built-in task runner, but you can use any task runner of your choice. Gulp is another popular task runner. For compiling Sass script with Gulp, you would need gulp sass compiler instead.

Warning! Sass is only a development tool. Avoid shipping any library or file associated with Sass. You would never need them on a production server.

What’s next

We’ve learned how to use preprocessors to create efficient and maintainable CSS blocks. We have seen various Sass features with examples. For more in-depth knowledge, jump to the official website.

I have also created a sample project. Go ahead, clone the project and start playing.

]]> <![CDATA[ In Defense of Utility-First CSS ]]> https://www.freecodecamp.org/news/in-defense-of-utility-first-css-4f406acee6fb/ 66c357f1e9895571912a0cbe Sat, 27 Jan 2018 01:13:30 +0000 By Sarah Dayan

“Favor composition over inheritance”.

This piece of wisdom from Design Patterns, one of the most influential software engineering books, is the foundation of utility-first CSS. It also shares many principles with functional programming: immutability, composability, predictability, and avoidance of side-effects. The goal behind all those fancy terms is to write code that’s easier to maintain and to scale.

Despite its growing popularity, utility-first CSS still hasn’t convinced everyone. While some praise it, others have been vividly critical about such a practice. I used to be in the latter group. I was a BEM fan, sold to an approach I adopted for its advantages and ended up rooting for it like we do for a sports team. I rejected utility-first because it implied that my beloved and familiar approach wasn’t good anymore.

Since then, I’ve dived a lot deeper into the topic. I studied design patterns and functional programming. This allowed me to radically revise my judgment.

CSS Tricks and Adam Wathan have done a brilliant job at taking us on a journey from “regular” CSS to utility-first, and explaining the “why” behind it. Rather than paraphrasing, I’ll focus on the recurring criticism of utility-first and debunk common misconceptions.

“Might as well use inline styles”

People often compare utility-first CSS to applying CSS rules to HTML nodes through the style attribute. This way of styling is unanimously considered a bad practice, and we have since moved on to separate stylesheets and class abstractions.

Utility-first CSS is no different. All styles are defined and maintained separately. This allows code reuse, usage of pseudo-classes, pseudo-elements, pre-processors, and browser caching.

Yet, atomic CSS detractors hurriedly associate it to inline styles. Atomic classes are small, they often have only one rule, and they’re named in a functional way instead of being semantic.

All that being said, just because it looks the same doesn’t mean it is the same. Understanding how both practices differ is key to grasping the benefits of utility-first.

Inline styles allow you to do anything you want. You don’t have to follow any pre-existing definition. You’re re-writing everything from the ground-up every time you style a new HTML node. Similar elements end up with duplicate code, which makes the page unnecessarily heavier. If you’re not careful, it’s easy to ignore pre-existing solutions and reinvent the wheel every time.

<h2 style="font-size: 16px; font-weight: bold; color: purple">Stranger Things<;/h2&gt;<p style="font-size: 13px; font-style: italic">Stranger Things is an American science fiction-horror web television...</p><h2 style="font-size: 16px; font-weight: bold; color: purple">;Game of Thrones</h2><p style="font-size: 13px; font-style: italic">Game of Thrones is an American fantasy drama television...</p>

Unnecessarily verbose, heavier file size, multiple sources of truth for a single design concept.

<button style="padding: 5px 8px; font-size: 13px">Button</button><button style="padding: 0 8px; font-size: 13px; line-height: 23px">Button</button><button style="display: flex; padding: 0 8px; font-size: 13px; height: 23px; align-items: center">Button</button>

Three attempts at solving the same problem. This is easily induced by the absence of a single source of truth, and likely to cause visual inconsistencies.

Utility classes expose a well-defined API that you can use to compose more complex components. You’re not re-writing styles; instead, you’re relying on classes that define styles and behaviors once and for all.

// HTML

<h2 class="font-16 font-bold font-purple">Stranger Things</h2><p class="font-13 font-italic">Stranger Things is an American science fiction-horror web television...</p><h2 class="font-16 font-bold font-purple">Game of Thrones</h2><p class="font-13 font-italic">Game of Thrones is an American fantasy drama television...</p>

// CSS

/* Font sizes */

.font-13 { font-size: 13px } .font-16 { font-size: 16px }...

/* Font styles */

.font-bold { font-weight: bold }.font-italic { font-style: italic }...

/* Font colors */

.font-purple { color: purple }...

Using a defined set of existing CSS rules, no matter how atomic, forces you to pick styles from a limited list. You’re not granted total freedom like you are with inline styles. You’re maintaining a consistent catalog of allowed styles, and using them to compose larger components.

This approach enforces consistency by limiting the ways you can style elements. Instead of having access to 16+ million colors, you only have access the number of colors defined in your theme.

It also provides a single source of truth. Instead of re-declaring the same color for each element that uses it, you define it once in a class and use that class wherever you need it. In addition, using separate styling (with atomic classes or not) gives you access to pseudo-classes and pseudo-elements, pre-processors, caching… a whole load of benefits that aren’t available with inline styles.

You may argue that it doesn’t matter if atomic styles are limited: carelessly mixing them may result in inconsistent layouts like with inline styles. But that’s a human issue, not a technical one. You get the exact same problem with any approach, and any language for that matter, whether you’re able to scope or not. If you don’t follow the rules, style guides, and best practices that your team put in place, you’re the one to blame. Not the program, not the language, and not the architecture.

“It violates separation of concerns”

One of the biggest arguments against functional CSS is that it goes against separation of concerns. That CSS should strictly be in charge of the styling, and HTML should semantically structure the page. That by using atomic classes and composing components in the HTML, you’re somewhat delegating styling to the HTML instead of doing it in CSS.

This is an extreme, and ultimately warped, vision of what “separation of concerns” means.

A few years ago, I was on a job interview with a front-end developer who told me about his sheer disdain for Bootstrap. According to him, using extra markup to create a grid was a heresy: that’s a job for CSS, and CSS only. HTML should be 100% oblivious to how it’s rendered.

The problem with that kind of thinking is that it’s deeply impractical. It raises design principles to a dogmatic level, ignoring concrete use-cases and context. It pushes you to be more concerned about checking all the “good practice” checkboxes than solving actual problems.

Adam Wathan explains it well (see: “Separation of concerns” is a straw man): when it comes to HTML and CSS, you can’t look at it from a strict “separation of concerns” perspective. It’s a “which depends on which” relationship.

Make no mistake: just because style composition is performed in the HTML document doesn’t mean it’s done in HTML. We’re not using style or align attributes on HTML nodes. We’re assembling pieces that we defined in a proper stylesheet, in CSS. Our HTML becomes a consumer of our CSS “API.” As Vue.js explains it in their documentation, separation of concerns doesn’t equal separation of file types. Your styles can be composed on HTML nodes, it’s still a CSS job.

“It bloats the HTML”

When people mention code bloat, they usually mean one of two things (or both): code that’s hard to read, and a heavier codebase.

The complexity of your layout has to exist somewhere. A component-first approach doesn’t remove “bloat,” it only deports it to the stylesheet. Even so, because your larger components reuse the same atomic styles as others, you inevitably end up with duplicate code.

$green: #74b759;

.component {  &-title {    color: $green;    font-weight: bold;  }}

.widget {  &-title {    color: $green;    font-style: italic;  }}

.footer {  &-links {   color: $green;   text-decoration: underline;  }}

Even with Sass, you get duplicate rules in the source code. @mixin can help, but you still get duplicates in the compiled CSS.

Now I know what you’re thinking. We got @extend. That’s an ideal use case for it, right?

Not so fast.

@extend may avoid ruleset duplication in the compiled CSS, but the mega comma-separated selector it will generate could end up being a lot heavier than if you had duplicated the rule. So much for avoiding bloat.

You’re also concatenating unrelated classes and moving them all to the top, where the first @extend takes place. This can quickly result in specificity issues and odd overrides. Not to mention that you can’t @extend an outer class or placeholder from within a media query. So yeah, definitely not a silver bullet.

From a file size standpoint, you shouldn’t worry about repeated class names in the HTML. That’s what Gzip is for. The deflate algorithm was specifically made to handle duplicate strings, so there’s no point in trimming away characters in your HTML. The resulting file size will make little to no difference whether you use a few or a lot of classes.

On the other hand, the more a selector is repeated in a stylesheet, the more work your browser has to do to resolve all styles. If you have a single .title-green class for a given style, it simply matches all .title-green in the page. But if you have many classes doing the same thing (using @mixin) or similar selectors doing different things (using @extend), the more expensive it will be for the browser to match.

HTML “bloat” doesn’t matter, but CSS does. The network and engine don’t care how many classes you have in your HTML, but the way you write your CSS counts. If your decision-making process revolves around performances, make sure you focus your attention on the right things.

“BEM is enough”

OOCSS and all derived methods (SMACSS, BEM, etc.) drastically improved how we handle CSS. Utility-first CSS is an heir of this approach: it, too, defines reusable objects.

The problem with BEM is that it focuses on building components first. Instead of looking for the smallest, unsplittable patterns, you’re building blocks and their child elements. BEM does an excellent job at namespacing and preventing style leaks, but its component-first nature inevitably leads to premature abstraction. You make a component for a certain use-case and end up never reusing it (a navbar component, for example).

BEM encourages you to use modifiers to handle component variations. This may seem smart at first, but unfortunately leads up to other problems. You end up creating tons of modifiers you only use once for a specific use-case. Worse: from one component to another, you might end up with similar modifiers, further breaking the DRY principle.

.card {  background: white;  border: 1px solid grey;  text-align: justify;}

.card--left {  text-align: left;}

.card--right {  text-align: right;}

.tooltip {  background: black;  color: white;  text-align: center;}

/* Oops, looks like duplicate rules down there! */

.tooltip--left {  text-align: left;}

.tooltip--right {  text-align: right;}

At scale, components can become hard to change without breaking instances throughout a project. Premature abstraction keeps components from evolving and splitting into independent entities if they need to. Modifiers multiply as an attempt to fix it, resulting in non-reusable variations for unicorn use-cases, and undo band-aids when we realize our component does too much.

BEM is a great attempt at fixing inherent CSS problems, but making it the core CSS approach of your project brings all the problems you meet when favoring inheritance over composition.

“It’s a whole other language to learn on top of CSS”

This statement can be said of any naming system for any specific project, whatever methodology you pick. Your CSS class names ecosystem is a layer of abstraction on top of pure CSS. Whether you’re using semantic names like .card or functional ones like .bg, new contributors will need to familiarize themselves with what does what and when to use it.

You can’t escape having to use a naming interface between your HTML and CSS, unless you’re willing to describe your exact markup in CSS or write inline styles. Ultimately, functional class names are easier to understand because they describe the style. You know what they do without having to lookup the actual styles, while semantic names force you to either look at the rendering or browse code.

“It’s unmaintainable”

When people say utility-first CSS is unmaintainable, they often mention that when something changes in the design, you have to change it everywhere. You have buttons with regular corners and you decide to make them rounded, so you need to add the .rounded-corners utility class on every button in the code. Yet, the whole point of utility-first is that you start composing with utility classes, and then create components when you start identifying repetitive patterns.

A button is an ideal and most obvious candidate for being abstracted into its own component. You might not even need to go through the “utility-first, then component” phase for this case. When it comes to larger components, favoring composition first is the best choice for maintainability. Why? Because it’s safer to add or remove classes on a specific HTML node than to add or remove styles in a class that applies on many elements.

Too many times have I been subjected to changing designs, and had to duplicate existing components to make them behave differently because I had no other choice. Even when a designer supplies all designs at the beginning of a project, and even if you do a great job at identifying components before you code, you can’t predict the future.

Let’s say initial designs have white cards with an inset box shadow and a little ribbon in the corner.

// CSS

.card {  position: relative;  background: white;  padding: 22px;  border: 1px solid lightgrey;  text-align: justify;  border-radius: 5px;  box-shadow: 0 0 5px 0 rgba(0, 0, 0, .2);  overflow: hidden;}

.card::after {  position: absolute;  top: -11px;  right: 9px;  display: block;  width: 10px;  height: 50px;  background: red;  transform: rotateZ(-45deg);  content: '';}

// HTML

<div class="card">...</div>

This solution is simple, semantic, and reusable. You handle everything in CSS and have minimal HTML to write. But suddenly you get new designs for new pages, and they use the card without the ribbon. Now you have to find a way to remove the ribbon for these new cards.

.card-no-ribbon::after {  display: none;}

Problem is, this class is undoing something that was previously designed. Having to add a class to remove a feature is an anti-pattern: it’s counter-intuitive and hard to maintain. When you decide to change how the base class behaves, you need to keep an eye on the undo modifier to make sure it still works.

We now need to add another ribbon to the bottom left.

.card::before,.card::after {  /* shared code */}

.card::before {  top: -11px;  right: 9px;}

.card::after {  bottom: -11px;  left: 9px;}

But now we need to update .card-no-ribbon!

.card-no-ribbon::before,.card-no-ribbon::after {  display: none;}

This, right here, is the fragile base class anti-pattern in action. Because your base class was abstracted too soon, is doing too much, and now needs to evolve, you can’t edit it without worrying about possible side-effects. If new people start contributing to the project, those risks multiply by ten.

The only option you have left this stage is to do a refactor: have a nude .card as the base class, and add the ribbons with .card--top-ribbon and .card--bottom-ribbon modifiers. But now you have to edit all the existing .cards in your code that do need to have a ribbon.

Early refactors are a pretty good indicator of unmaintainability.

You could argue that a smart developer could have seen it coming. That they should have made a naked .card base class and a .card--ribbon modifier, right from the start.

That’s actually making a case in favor of utility-first and composition.

You’re taking the decision to break down a given design element that you deemed too monolithic, so it’s easier to scale. That’s a good call. The more you go, the more you’ll realize this leads to utility-first.

You might think it doesn’t, and that your job is to foresee what is the bare minimum for a given component. But unless you own a crystal bowl, this is a risky assessment. This is also short-sighted. What if parts of your component need to be extended to other components? For example, what if you now need buttons with ribbons? If you duplicate the .card--ribbon class, your code isn’t DRY anymore, which makes it even more unmaintainable. So? Make a mixin and import it into both modifiers? Again, that’s extra work and “wet” code.

The best solution for this use-case is to write a single utility class for the ribbon, and modifiers for sizes and colors if necessary. This allows you to have a single source of truth and use the ribbon anywhere you want to. If you need to put ribbons on avatars, panels, unordered lists, modals, you can do it without having to write a single extra line of CSS.

This is the definition of scalability and maintainability. All you have to do is reuse the available code you wrote proactively, instead of having to tweak existing code reactively.

.ribbon {  position: relative;  overflow: hidden;}

.ribbon::after {  position: absolute;  display: block;  top: -11px;  right: 9px;  width: 10px;  height: 50px;  background: red;  transform: rotateZ(-45deg);  content: '';}

By breaking down designs into small elements, we write much more reusable code.

Calling utility-first CSS “unmaintainable” is absolutely inaccurate. In fact, it may be the most maintainable and scalable CSS methodology to this day.

You can’t predict the future. This is why you should always favor composition over inheritance. A good sign of a healthy and scalable codebase is how things go when you need to change it.

If a new change makes you anxious because you might break something, it’s a sign of poor design. But I would go a step further and say that if you need to write new CSS to make an existing component do something that another component already does, your code isn’t as scalable as you think it is.

If you need to reuse behavior that exists somewhere, you shouldn’t have to write new code. You should be able to trust and use what you already wrote and go from there. You have one source of truth on which you can rely, instead of two or more slight variations that you must not forget to keep up to date. This is the definition of maintainability.

“It’s ugly and hard to read”

Do you remember the uproar when BEM started to become popular? I do. I remember many people who rejected the whole thing because of its syntax. Praising the model, but disgusted with the idea of chaining two underscores or two hyphens.

As humans, it’s in our nature to be easily put off by what we’re not familiar with. Yet, letting subjective cosmetic considerations come in the way of a potentially useful technique is where developers should draw the line. Our job is to solve problems. Our main concern should be the end user.

Look at the source code of many big projects: most of them have ended up adopting BEM. Chances are not all their front-end developers were sold at the beginning.

Overcoming initial feelings, especially if driven by personal preference, isn’t that hard when you’re putting the success of a project first.

Now on the topic of legibility, I get that long strings of classes can be “scary” when you open a file for the first time. This is not an insurmountable task though. More verbose code is a trade-off of composition, but it’s a much lesser inconvenience than unscalability.

I don’t use shorthands like .pt-8 or .bb-lemon in my own code. I favor full-length class names like .padding-top-8 and .border-bottom-lemon, which are much easier to read. Autocomplete solves the problem of having to type long class names, and there are tools you can use to re-hash class names into smaller ones for production. I doubt this will make any significant change to your performances but hey, if it makes you feel good to shave bytes away, knock yourself out ?

Ultimately, the nature of functional class names might actually be more expressive. It’s easy for your brain to make a connection between such a class and what’s happening on screen. Even if you don’t get to see how it renders, you can get a pretty good idea of what .hidden or .opacity-6 are supposed to do.

<blockquote class="border-thick-left-red padding-left-medium font-navy">  <p>You know how they call a Quarter Pounder with Cheese in Paris?</p></blockquote>

Stylistically speaking, it’s pretty easy to know what’s going on here.

Semantic class names don’t convey the same thing. It works for small components like buttons or alerts, which are common enough to be easily recognized. Yet, the bigger and the more complex a component gets, the less obvious it is to know what class name maps to what element on the screen, or what it looks like.

<div class="entry">  <h2 class="entry-title">The Shining</h2>  <div class="widget widget-lead">    <div class="widget-content">      <p>His breath stopped in a gasp. An almost drowsy terror stole through his veins...</p>    </div>    <div class="author">      <img class="author-avatar" src="...">      <h3 class="author-name">Stephen King</h3>      <p>Stephen Edwin King (born September 21, 1947) is an American author of horror, supernatural fiction, suspense, science fiction, and fantasy...</p>      <div class="btn-group">        <a class="btn" href="#">;Website</a>        <a class="btn" href="#">Twitter</a>      </div>    </div>  </div></div>

Harder to know what class does what without going through the stylesheet.

In that way, functional classes are a lot easier to understand than semantic class names. They demand less catching up time and less file-switching. Ultimately, they give you the very bit of information you’re looking for anyways.

“It’s not how you write CSS”

CSS specificity is a feature, not a bug. Use it correctly, and it will give you amazing control.

That’s what CSS veterans say when yet another article about the dangers of specificity pops up. And technically they’re right: the CSS priority system isn’t an accident. It usually bothers people who don’t master CSS because of the lack of scope. But a language isn’t broken because it doesn’t behave like what you’re used to. Nested CSS rules are like !important: they’re handy, but have been so poorly used for years that we now see it as something to avoid.

Specificity should be used proactively, not reactively. They should be design decisions, not a quick fix when your styles don’t apply. Harry Roberts explains it well in CSS Guidelines:

“The problem with specificity isn’t necessarily that it’s high or low; it’s the fact it is so variant and that it cannot be opted out of: the only way to deal with it is to get progressively more specific”.

Specificity is a powerful tool, but it needs to be used with uppermost caution and a good long-term vision of the project. Use them wrong, and you’ll feel the pain of having to go back. Keeping specificity low avoids problems altogether: it relies solely on source order, which is a lot easier to manage. With atomic CSS, if a style doesn’t apply, fixing it is as simple as adding or removing a class on an HTML node. You don’t have to call your stylesheet’s structure into question, which is a lot easier and safer to manage.

// CSS

.color-navy {  color: navy;}

.color-red {  color: red;}

// HTML

<div class="color-red color-navy">  <p>- Whose motorcycle is this?</p>  <p>- It's a chopper baby.</p>  <p>- Whose chopper is this?</p>  <p>- It's Zed's.</p>  <p>- Who's Zed?</p>  <p>- Zed's dead baby, Zed's dead.</p></div>

Want the text to be navy? No need to touch the CSS. Simply remove the .color-red class from the encompassing <div>. If you need one of the children to be red, then move the .color-red on it.

“If a feature is sometimes dangerous, and there is a better option, then always use the better option.” — Douglas Crockford

Using specificity or not isn’t about showing how well you master CSS and how you, unlike others, can keep it under control. It’s about understanding the advantages and flaws of the features at your disposal, and making choices in the best interest of the project.

“You end up with plenty of unused CSS”

Let’s say you’re using Sass maps to generate your utility classes. Colors, font sizes, backgrounds, everything is automatically compiled into proper, ready-to-use CSS. Problem is, if you don’t use everything, you’re left with useless extra bytes in production. This can easily be fixed with UnCSS.

UnCSS is great at dusting off your stylesheets, but it comes with two caveats: it only works on HTML files (so, no PHP and no template files) and it only takes into account the JavaScript that’s executed on page load (not classes added on user interactions, for example). If you’re using a language like PHP to render your pages, you can add a job in your deployment workflow that compiles pages into temporary HTML and runs UnCSS on them. For the second issue, you can use the ignore option to list out that are classes added on user interaction.

Now it’s also important to ponder this issue. The cost of unused classes is heavier stylesheets (longer to download) and longer parse time. If you have a lot, and by that I mean a large percentage of your total styles, of unused classes, this can hurt performances. If you only have a few here and there, the impact will be negligible.

Maintaining your CSS codebase is your job as a developer. No matter what methodology you choose, you have to keep an eye on the project and make sure to remove dead code when things change.

Being careless with that is how you end up with plenty of unused classes, not because you’re generating some of them.

Need a text color class only for the main color? Make a class for this one only. Need backgrounds for most colors in the theme, yet unsure you’ll use them all right away? Generate the damn classes. They’ll be ready when you need them, you won’t have to maintain them when you add new colors, and the extra code will cost nothing. This is not where your app’s bottlenecks are. If you’re having performances issues, there are a million other things to consider before even looking into your CSS.

“It makes it hard to know what’s available to use”

When your CSS codebase is a large collection of small utility classes, reading the source code won’t help you get a good overview of the available styles. But is it the role of the source code anyway?

It certainly isn’t. That’s what style guides are for.

Exploring source code is far from being enough to get a good understanding of how a full API is designed. This isn’t limited to atomic CSS: OOCSS or BEM projects, even small ones, can reach a level of sophistication which requires at least a README.

Can you imagine having to crawl back in an unminifed version of the master Bootstrap stylesheet every time you don’t remember if this is .col-md-offset-6 or .col-offset-md-6? Would anyone new to Bootstrap understand what such a class means without a little literature on how the grid works? Documentation, style guides, and API references are designed to help us make sense of complex systems. Sure, it doesn’t mean documentation should justify poor design and unclear naming conventions, but thinking you should be able to understand an entire project only by reading the source code is pure fantasy.

There are plenty of tools out there to help you generate documentation right from your code. I use KSS for most of my projects, but CSS-Tricks shares a list of alternatives. Give it a try!

“Utility classes should be used along with components”

Yes. Absolutely. That’s precisely why it’s called utility-first and not utility-only.

Utility-first isn’t about ditching components altogether. It means you should start off with utility classes, make the most of them, and only abstract when you see repeating patterns. You’re allowing your project to grow while remaining flexible, and identifying actual components over time, when patterns start to emerge.

It is crucial to understand that a component isn’t just a similar-looking “block” that you can reuse. It’s a pattern that is strongly tied to your specific project. Sure, you’re probably going to use tons of .btn and .modal, so it makes sense to abstract them early on. But are you positive you’re going to ever reuse .testimonial? Or at least reuse it enough to make it worth being a new component? Will it always look like this in every context, or is it specific to the homepage? Keep your options open. It’s a lot easier to later abstract a composite style into a component than to try and undo one.

“It makes redesigning/theming a nightmare”

Because atomic CSS is strongly tied to your design, this can make things more difficult when you have to do a redesign or develop an alternate theme. It’s far from impossible though, and there are a few things you can do to make your utility-first CSS more suited to these kinds of needs.

You can start by keeping class names not too specific. Instead of .margin-bottom-8, you can use a more abstract name like .margin-bottom-xxs. This way you can change the value without making the names invalid.

Another approach would be to create aliases. Imagine you’re building an app that has light and dark mode: some colors would change, some others wouldn’t. We don’t want to make all our color utilities contextual: .background-primary and .background-secondary don’t tell us what color is behind the class. You don’t want an entire color system like that. Yet, you could still have color utilities with proper color names (.background-lime or .background-red), and generate aliases for those which might need to change for theming purposes.

// CSS

/* Backgrounds */

.background-lime {  background: #cdf2b0;}

.background-off-white, .background-light {  background: #ebefe8;}

.background-dark-grey, .background-dark {  background: #494a4f;}

/* Colors */

.color-lime {  color: #cdf2b0;}

.color-off-white, .color-light {  color: #ebefe8;}

.color-dark-grey, .color-dark {  color: #494a4f;}

// HTML

<div class="background-light">  <h2 class="color-lime">Ezekiel 25:17</h2>  <p class="color-dark">The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men...</p></div>

From here, all you have to do is write a JavaScript function that toggles all .*-light and .*-dark classes. And for elements that don’t need to change, you can use the original color classes.

This method works well, but if you have a lot of classes to switch it may end up hurting performances. DOM manipulations are expensive. You want to reduce them as much as possible if you can. Luckily, there’s a nifty technique involving CSS variables (thanks to Adam Wathan for coming up with it) which makes everything simpler.

// CSS

:root {  --green: #42f49b;  --off-white: #ebefe8;  --dark-grey: #494a4f;}

.theme-dark {  --background: var(--dark-grey);  --text: var(--off-white);}

.theme-light {  --background: var(--off-white);  --text: var(--dark-grey);}

.color-lime {  color: var(--green);}

.color-theme {  color: var(--text);}

.background-theme {  background: var(--background);}

// HTML

<div class="theme-light">  <div class="background-theme">  <h2 class="color-lime">Ezekiel 25:17</h2>  <p class="color-theme">The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men...</p>  </div></div>

We defined colors with CSS variables and assigned different values for each context. Depending on the encompassing class, all colors will change thanks to ancestor inheritance. If you were to allow theme switching, all you’d have to do is change .theme-light into .theme-dark on the parent <div>, and all colors would adapt.

This technique only works if you don’t have to support Internet Explorer and Edge below version 15. Otherwise, go for the first technique and use CSS ancestor inheritance system to avoid having to toggle too many variables. If you have to assign a text color to an entire block, set it on the parent instead of the children.

/* Nope */<div class="background-light">  <h2 class="color-lime">Ezekiel 25:17</h2>  <p class="color-dark">The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men.</p>  <p class="color-dark">Blessed is he, who in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children.</p>  <p class="color-dark">And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy my brothers.</p>  <p class="color-dark">And you will know my name is the Lord when I lay my vengeance upon thee.</p></div>

/* Yes */<div class="background-light color-dark">  <h2 class="color-lime">Ezekiel 25:17</h2>  <p>The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men.</p>  <p>Blessed is he, who in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children.</p>  <p>And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy my brothers.</p>  <p>And you will know my name is the Lord when I lay my vengeance upon thee.</p></div>

Embracing change, within reason

Having strong opinions is great. Not everything has to be settled by finding a middle ground. But there’s a clear line to draw between being opinionated and being reluctant to change.

We, as developers, must be the first to embrace change. Looking back at my first reaction towards utility-first CSS, I realize how important it is we keep an open mind instead of rushing to pick a side. It doesn’t matter how experienced we think we are. Experience is great, but it can also make us believe we already have all we need to make judgment calls and don’t need to dive deeper to understand new concepts.

Software development changes every day. Our industry is still young, and we’re figuring things out as we go. It doesn’t mean we should throw away the past, and continuously refactor all our projects to keep up with the latest trends. Past knowledge is the foundation of today’s discoveries. But just because something is tried and true, doesn’t mean it’s set in stone. It’s important we approach novelty with critical thinking.

We’ll probably move on from utility-first CSS at some point, like how we got past many things we used to consider the pinnacle of front-end development. In the meantime, let’s try to stay as open-minded as possible, and do what’s best for the industry, the projects, and the users.

Want to learn more about utility-first CSS and how to use it in your projects? Go read On the Growing Popularity of Atomic CSS on CSS Tricks and CSS Utility Classes and “Separation of Concerns” on Adam Wathan’s blog. You can also check out utility-first libraries on this curated list by CSS Tricks.

Originally published at frontstuff.io.

]]>