Implications for Architecture

The way in which code is organized and architected can be very different when using preprocessors than when using pure CSS because of added functionality, such as mixins and the ability to extend classes. The ability to compute values in ways simply not available outside of preprocessors today brings the ability to write DRY semantic code. It can be defined in just one place and then reused throughout the style sheet not much differently than some of the object-oriented principles used in other programming languages.

The downside of using preprocessors is that they add a layer of complexity to the application that does not exist when using pure CSS. Even though some preprocessors, such as Less,² can be run in the browser directly, it is not recommended for production use because it is less performant and reliable than plain CSS. When using preprocessors, we therefore need some sort of build step in order to compile the code into CSS.

Debugging can also be a challenge, especially when using some of the more complex or advanced features of the code. This stems from the CSS being generated not matching one-to-one with the code being written. For example, the properties and attributes being added to a class could come from a mixin (more about mixins later in this chapter) rather than part of the ruleset. The CSS being applied is the output, not the mixin itself, so tracking back to which mixin created the output can be difficult. Sourcemaps can help with this. A sourcemap is a file that can be generated with the CSS which links the output back to the code that generated it. But again, this needs to be set up specifically as part of the build process.

So first, before even choosing the processor to be used, the question of whether the added complexity is necessary should be asked.

Color Functions and Variables

Variables, although available today in CSS as discussed in Chapter 2, were first made available through the use of preprocessors. The CSS version (custom properties), although influenced by preprocessor variables, does have some advantages over the preprocessor variables. Custom properties can be accessed and changed via JavaScript, while preprocessor variables cannot. In creating the CSS output, preprocessor variables do not remain variables; they are replaced by their assigned value. CSS custom properties, however, stay variables and can be manipulated at any time, including during runtime.

Although variables can be used for any value, such as default padding amount, they are extremely powerful when used in conjunction with color functions to define the theme of an application. The brand colors for an application include those given in Table 7-1.

Table 7-1

Color Values and Usage

The colors can be set to semantic names based upon what their usage will be and then manipulated using color functions when the color value or saturation needs to be altered (Listing 7-1).

By using color transformation functions and variables, not only don’t we have to remember the exact values for each of the colors and any variations we may have in use, but we also increase our ability to keep our theme consistent. Furthermore, if the colors were to change, this could be done in one place. The eventuality of a color changing is why color names should be based upon their usage rather than their actual color. If the variable name was $pink, for example, and the accent color was changed to purple, we would now have to either find the variable name everywhere and update it, or we would have a variable name that does not represent the color that is assigned to it. Situations like this make maintainability very difficult and code confusing. Selecting semantic variable names is incredibly important to the maintainability of the code.

Mixins

Mixins allow developers to create sets of properties and values that can easily be reused throughout the application.

Arguments

Logic can also be added within the mixin. In Listing 7-8, styles are applied differently based upon a non-zero $elevation.

@mixin card($elevation) {

  background: white;

  box-sizing: border-box;

  margin-bottom: 1rem;

  padding: 1rem;

  @if $elevation == 0 {

    border: solid 1px silver;

  } @else {

    $offset: $elevation * 1;

    $blur: $elevation * 2;

    box-shadow: #{$offset}px #{$offset}px #{$blur}px silver;

  }

}

body {

  padding: 2rem;

}

h1 {

  margin: 0;

}

header {

  @include card(0)

}

div {

  @include card(2);

}

Listing 7-8

Mixin with Arguments and Logic

The advantage of using mixins, especially with arguments, is that it allows for DRY code. The code is written once and managed in one place but applied to multiple classes. The preceding code (Listing 7-8) would compile to what is shown in Listing 7-9 and display Figure 7-1.

body {

  padding: 2rem;

}

h1 {

  margin: 0;

}

header {

  background: white;

  box-sizing: border-box;

  margin-bottom: 1rem;

  padding: 1rem;

  border: solid 1px silver;

}

div {

  background: white;

  box-sizing: border-box;

  margin-bottom: 1rem;

  padding: 1rem;

  box-shadow: 2px 2px 4px silver;

}

Listing 7-9

CSS Output

Mixins are very powerful in preventing the need to duplicate code or nonsemantic class names. Without mixins, the earlier code would require a potentially infinite number of classes, or have to rewrite the border and shadow multiple times and then maintain it in multiple locations. Another great application is when a specific parameter might apply to many aspects of an element, but differs depending on context, while the rest of the element needs to stay consistent regardless of the situation. Informational boxes to the user might be an example, where there is a need for information, successes, warnings, and errors. The boxes need to look the same except for color (Listings 7-10 and 7-11 and Figure 7-2).

<body>

  <p class="message info">Information</p>

  <p class="message success">Success</p>

  <p class="message warning">Warning</p>

  <p class="message error">Error</p>

</body>

Listing 7-10

Informational Boxes HTML

@mixin message($color) {

  background: lighten($color, 40%);

  border: solid 1px $color;

}

body {

  padding: 2rem;

}

.message {

  padding: 1rem;

}

.info {

  @include message(blue);

}

.success {

  @include message(green);

}

.warning {

  @include message(orange);

}

.error {

  @include message(red);

}

Listing 7-11

Informational Boxes SCSS

Even though the padding could have been included in the mixin, it is separated out into its own class because when a mixin is added, it does its computation and outputs all the code each time; therefore, mixins are not a good use case for static information. Static styles are simply programmatically being copied over into each class increasing the size of the CSS and therefore upload time. Classes, defaults on elements, or the use of the @extend at-rule are much better options for static styles.

@extend

Extend, unlike mixins, prevents the duplication of code in the resulting CSS. While a mixin copies the declaration block for each selector it is included within, extend creates a single declaration block and consolidates the selectors.

The advantage of this methodology is in creating base classes for basic styles toward which semantically named classes will be pointed. The code is neither duplicated nor copied and prevents the use of numerous nonsemantic classes on an HTML element. For code maintainability it also means that the style of the elements is controlled in the CSS. If the style coming from extending another rule is no longer wanted, we need only to remove the @extend. By simply adding the class name to the HTML instead of using @extend , we would have had to edit the HTML in order to change look and feel. By using @extend instead of adding the same class name to a multitude of elements, we continue to maintain a separation of concerns. Our elements can have class names that match their purpose, rather than how they display, and we handle the styling via the CSS.

Revisiting the example found in the “Mixins” section rather than adding both message and the type to each class, we can create one class that determines the type and has the defaults set by .message (see Listings 7-12 and 7-13 and Figure 7-3).

<body>

  <p class="info-message">Information</p>

  <p class="success-message">Success</p>

  <p class="warning-message">Warning</p>

  <p class="error-message">Error</p>

</body>

Listing 7-12

Informational Boxes HTML – Revisited

@mixin message($color) {

  background: lighten($color, 40%);

  border: solid 1px $color;

}

body {

  padding: 2rem;

}

.message {

  padding: 1rem;

}

.info-message {

  @include message(blue);

  @extend .message;

}

.success-message {

  @include message(green);

  @extend .message

}

.warning-message {

  @include message(orange);

  @extend .message

}

.error-message {

  @include message(red);

  @extend .message

}

Listing 7-13

Informational Boxes SCSS – Revisited

Notice the message class now has multiple other selectors as well, but was not duplicated in the output.

@Import

Imports allow the user to create partial files in which variables, mixins, and reusable code can be placed. Sass imports work similarly to CSS imports in that it copies the SCSS they contain to the style sheet they are being imported by. They must therefore be used with caution. It is very easy to bloat code by repeatedly importing an entire theme, for example, into each component. Sharing mixins and variables, since they are not copied, but produce an output within a style, is a perfect application of the use of @import, because unlike classes, they do not get copied.

Creating import files to have information accessible from anywhere in the application becomes very interesting when dealing with components because more often than not, such as when using Angular out of the box or creating component in JavaScript and Shadow DOM, the CSS is scoped and therefore in a separate file or area of the application than the rest of the CSS. Adding variables and mixins to a partial – a file to be imported into other files that do not have a use on its own – helps keep the code DRY.

Summary

In this chapter we looked at a very small subset of functionality brought to use via the use of preprocessors. We looked at mixins, imports, extends, color function, and variable and how they impact how we might organize and structure our application’s CSS. In the next chapter, we will look at how JavaScript can interact with our CSS especially in the context of modern frameworks.