Every large frontend application needs a robust, scalable CSS architecture. A CSS preprocessor is indispensable--it helps to write cleaner, modular code with reusable pieces and maintain large and complex style sheets. A CSS preprocessor is basically a scripting language that extends CSS and compiles it into regular CSS. There are three primary CSS preprocessors today: Sass, LESS, and Stylus. As per Google Trends, Sass is the most used preprocessor today. Sass mimics the HTML structure and lets you nest CSS selectors that follow the same visual HTML hierarchy. With CSS, you would need to write this:

.container {
  padding: 5px;
}

.container p {
  margin: 5px;
}

With Sass, you can simply write this:

.container {
  padding: 5px;
  p {
    margin: 5px;
  }
}

While nesting CSS selectors, you can use the handy & symbol. The & symbol concatenates CSS rules. For example, consider the following Sass snippet:

.some-class {
  &.another-class {
    color: red;
  }
}

This will be compiled to the following:

.some-class.another-class {
  color: red;
}

The & symbol is also useful for sandboxed UI components when every component only uses class names prefixed with a unique namespace. For example, the following imaginary header module is sandboxed with the .mod-header namespace:

.mod-header {
  &-link {
    color: blue;
  }

  &-menu {
    border: 1px solid gray;
  }
}

The output results in two classes: .mod-header-link and .mod-header-menu. As you see, Sass helps to avoid CSS collisions. It is recommended to write separate Sass files for each UI component and then combine them together by means of @import directive. With this directive, one Sass file can be imported into another one. The preprocessor will take the file that you want to import and combine it with the file you are importing into. This is a little bit different to the native CSS @import. The CSS @import always creates an HTTP request to fetch the imported file. The Sass @import combines the files so that one single CSS file will be sent to the browser.

Another power Sass concept is partial files. It is possible to create partial Sass files that contain small snippets for inclusion into other Sass files. Two typical examples of partial files are variables and mixins. Variables facilitate storing information that you want to reuse throughout your style sheets. Variables begin with dollar signs. For example:

$brand-color-background: white;
$brand-color-content: black;

Usage:

body {
  background-color: $brand-color-background;
  color: $brand-color-content;
}

A mixin lets you make groups of CSS declarations that you want to reuse throughout your style sheets. They behave like parameterized functions. A mixin begins with the @mixin directive followed by a name. Let's create a mixin to center any HTML content:

@mixin center($axis: "both") {
  position: absolute;
  @if $axis == "y" {
    top: 50%;
    transform: translateY(-50%);
  }
  @if $axis == "x" {
    left: 50%;
    transform: translateX(-50%);
  }
  @if $axis == "both" {
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
  }
}

The mixin name is center and the parameter $axis has a default value "both" if you don't pass the parameter value explicitly. The usage is simple--the mixin has to be included with the @include directive:

.centered-box {
  @include center();
}

This leads to the following:

.centered-box {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

A partial file is named with a leading underscore, for example, _variables.scss, _mixins.scss. The underscore lets Sass know that the file should not be compiled to a CSS file. The underscore and file extension in the @import directive can be omitted:

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

Sass has more powerful features such as inheritance, operators, built-in functions, and handling media queries. Refer to the official Sass site for more details (http://sass-lang.com). You can play with Sass online on http://www.sassmeister.com:

Or you can use it at http://sass.js.org:

It is high time to provide a guideline for organizing your Sass files. What is a good CSS architecture and project structure with a lot of Sass files? When planning your CSS architecture, you should modularize directories and files into categories. There are several proposals and recommendations. At the end, it depends on conventions in your team. One of the popular proposals is The 7-1 Pattern (https://sass-guidelin.es/#the-7-1-pattern). This architecture provides seven folders and one main file to import all files and compile them into a single file. These are as follows:

• base/: This folder contains global styles, such as CSS resets, typography, colors, and so on. For example:
  • _reset.scss
  • _typography.scss
• helpers/: This folder contains Sass tools and helpers, such as variables, mixins, functions, and so on. This folder should not output a single line of CSS when compiled on its own:
  • _variables.scss
  • _mixins.scss
• components/: This folder holds styles for self-contained components. These are normally widgets--small building blocks other components can be composed of. For example:
  • _button.scss
  • _carousel.scss
• layout/: This folder holds macro layout styles for larger components, such as CSS grid, header, footer, sidebar, and so on:
  • _header.scss
  • _footer.scss
• pages/: This is an optional folder, which contains page-specific styles:
  • _home.scss
  • _about.scss
• themes/: This is an optional folder, which contains styling for different themes. It makes sense for large sites with multiple themes:
  • _omega.scss
  • _ultima.scss
• vendors/: This folder contains files from external libraries and frameworks, such as Bootstrap, jQueryUI, Select2, and so on:
  • bootstrap.scss
  • jquery-ui.scss

Some folders are project specific and might not exist in many projects. Folder names are arbitrary. For instance, the components/ folder might also be called modules/, depending on what you prefer. In Angular projects, each Sass file for component styling resides in the same folder as the corresponding component. There is no dedicated folder for them.

For this book, a demo project was born--an imaginary graphic editor that demonstrates styling concepts. The web application is built on top of Angular 4 and Bootstrap 3 (http://getbootstrap.com). It has various panels on the left and right sides as well as a toolbar. The layout is responsive--panels get stacked on small screens. All styling files are gathered in the main.scss file:

// 1. Vendor files
@import "~font-awesome/css/font-awesome.min.css";
@import "vendor/bootstrap-custom";

// 2. Helpers (variables, mixins, functions, ...)
@import "helpers/variables";
@import "helpers/mixins";

// 3. Base stuff (common settings for all components and pages)
@import "common/viewport-workaround";
@import "common/global";
@import "common/components";

// 4. Styles for components
@import "../../app/app.component";
@import "../../app/main/main.component";
@import "../../app/layout/layout.component";
@import "../../app/panel/panel.component";
@import "../../app/panel/toolbar/toolbar.component";

Once main.scss file is imported into the file where you bootstrap the Angular application, Webpack creates a link to the main.css in index.html automatically (thanks to HtmlWebpackPlugin):

// Webpack creates a link to the main.css and put it into the 
// index.html
import './assets/css/main.scss';

import {platformBrowserDynamic} from '@angular/platform-browser-dynamic';
import {AppModule} from './app/app.module';

platformBrowserDynamic().bootstrapModule(AppModule)
                        .catch(err => console.error(err));

More flexible and modern responsive layout with Bootstrap 4 will be illustrated in the Bootstrap flexbox layout meets PrimeNG section. The graphic editor serves as a basis for a new demo application.