Kent Wynn Kent Wynn
  • Frontend Lang
    • HTML +
    • CSS SCSS LESS +
    • JavaScript ES6 TS
    • RxJS Library
    • Angular Framework
    • Ionic Framework
    • JavaFX Framework
    • Java Spring Framework
  • Frontend Dev
  • WordPress
  • UI/UX Designs
  • SEO
  • Tech Follows
Kent Wynn's Promotion Card
  • Kent Wynn’s Shop$10
  • My Account
  • Cart
  • Checkout
544
393
844
20K
0
Kent Wynn Kent Wynn

Software Engineer | UI/UX & Frontend Architect

Become Frontend Master
Kent Wynn Kent Wynn
  • Frontend Lang
    • HTML +
    • CSS SCSS LESS +
    • JavaScript ES6 TS
    • RxJS Library
    • Angular Framework
    • Ionic Framework
    • JavaFX Framework
    • Java Spring Framework
  • Frontend Dev
  • WordPress
  • UI/UX Designs
  • SEO
  • Tech Follows
  • CSS
  • Frontend Lang

CSS Writing Techniques At Large Scale in Frontend Architect

  • June 27, 2021
  • 2.7K views
  • 6 minute read
css-writing-techniques-at-large-scale-in-frontend-architect
Total
0
Shares
0
0
0
0
0
0
0
0
Table of Contents Hide
  1. Single Responsibility Principle
  2. Single Source of Truth
  3. Component Modifiers
  4. Conclusion

This article covered just a small sample of the different CSS techniques that you might use to create a maintainable codebase.

Single Responsibility Principle

The single responsibility principle states that everything you create should be created for a single, focused reason. The styles you apply to a given selector should be created for a single purpose and should do that single purpose extremely well.

This doesn’t mean you should have individual classes for padding-10, font-size-20, and color-green. The single purpose we’re talking about is not the styles that they apply, but rather where the styles are applied. Let’s look at the following example:

<div class="calendar">
  <h2 class="primary-header">This Is a Calendar Header</h2>
</div>
<div class="blog">
  <h2 class="primary-header">This Is a Blog Header</h2>
</div>

<style>
  .primary-header {
    color: red;
    font-size: 2em;
  }
</style>

While the preceding example appears to be quite efficient, it has clearly broken our single responsibility principle. The class of .primary-header is being applied to more than one, unrelated element on the page.

The “responsibility” of the primary header is now to style both the calendar header and the blog header. This means that any change to the blog header will also affect the calendar header unless you do the following:

<div class="calendar">
  <h2 class="primary-header">This Is a Calendar Header</h2>
</div>
<div class="blog">
  <h2 class="primary-header">This Is a Blog Header</h2>
</div>

<style>
  .primary-header {
    color: red;
    font-size: 2em;
  }
  .blog .primary-header {
    font-size: 2.4em;
  }
</style>

This approach in our CSS techniques, while effective in the short term, brings us back to several of the problems we had at the beginning of the chapter. This new header style is now location-dependent, has multiple inheritances, and introduces a game of “winning specificity.”

A much more sustainable approach to this problem is to allow each class to have a single, focused responsibility:

<div class="calendar">
  <h2 class="calendar-header">This Is a Calendar Header</h2>
</div>
<div class="blog">
  <h2 class="blog-header">This Is a Blog Header</h2>
</div>

<style>
  .calendar-header {
    color: red;
    font-size: 2em;
  }
  .blog-header {
    color: red;
  }
</style>

While it’s true that this approach can cause some duplication (declaring the color red twice), the gains in sustainability greatly outweigh any duplicated code. Not only will this additional code be a trivial increase in page weight (gzip loves repeated content), but there is no guarantee that the blog header will remain red, and enforcing the single responsibility principle throughout your project will ensure that further changes to the blog header are done with little work or possible regressions.

Single Source of Truth

The single source of truth approach takes the single responsibility theory to the next level in that not only is a class created for a single purpose, but also the styles applied to that class come from one single source. In a modular design, the design of any component must be determined by the component itself, and never imposed on it by a parent class.

Let’s take a look at this in action:

<div class="calendar">
  <h2 class="calendar-header">This Is a Calendar Header</h2>
</div>
<div class="blog">
  <h2 class="blog-header">This Is a Blog Header</h2>
</div>

<style>
  .calendar-header {
    color: red;
    font-size: 2em;
  }
  /* blog.css */
  .blog-header {
    color: red;
    font-size: 2.4em;
  }
  .blog .calendar-header {
    font-size: 1.6em;
  }
</style>

The intention of these styles is to decrease the size of the calendar header when it is inside a blog article.

From a design standpoint, that might make perfect sense, and what you end up with is a calendar component that changes appearance depending on where it is placed.

This conditional styling is what I like to call a “context,” and is something I use quite extensively throughout my design systems.

The main problem with this approach is that the decreased font size originates from the blog component, and not from within the calendar’s single source of truth, the calendar component file.

In this case, the truth is scattered across multiple component files. The problem with having multiple sources of truth is that it makes it very difficult to anticipate how a component is going to look placed on the page. To mitigate this problem, I suggest moving the contextual style into the calendar module code:

<div class="calendar">
  <h2 class="calendar-header">This Is a Calendar Header</h2>
</div>
<div class="blog">
  <h2 class="blog-header">This Is a Blog Header</h2>
</div>

<style>
  .calendar-header {
    color: red;
    font-size: 2em;
  }
  .blog .calendar-header {
    font-size: 1.6em;
  }
  /* blog.css */
  .blog-header {
    color: red;
    font-size: 2.4em;
  }
</style>

With this approach, we are still able to decrease the size of the calendar header when it is inside of a blog article, but by placing all of the calendar-header contextual styles into the calendar file, we can see all of the possible variations of the calendar header in a single location.

This makes updating the calendar module easier (as we know all of the conditions in which it might change) and allows us to create proper test coverage for each of the variations.

Component Modifiers

While the single source of truth approach does improve clarity by placing the context inside of the component file, it can become difficult to keep track of several different contexts. If you find that the calendar header is smaller inside of dozens of different contexts, it might be time to switch from contextual modifiers to modifier classes.

Component modifiers (also called skins or subcomponents, depending on the methodology you subscribe to) allow you to create multiple variations of a component to be used in various circumstances. They work in a very similar way to contexts, but the qualifying class is part of the component rather than a parent of the component:

<div class="blog">
  <h2 class="blog-header">This Is a Blog Header</h2>
  ...
  <div class="calendar calendar--nested">
    <h2 class="calendar-header">This Is a Calendar Header</h2>
  </div>
</div>

<style>
  /* calendar.css */
  .calendar-header {
    color: red;
    font-size: 2em;
  }
  .calendar--nested .calendar-header {
    font-size: 1.6em;
  }
  /* blog.css */
  .blog-header {
    color: red;
    font-size: 2.4em;
  }
</style>

In the preceding example, we have created a calendar--nested modifier using the traditional BEM syntax. This class by itself does nothing, but when it is applied to the calendar component, the elements inside of the component can use it as a local context and change their appearance.

With this approach, we can use this modified calendar skin whenever we want, and we will get that smaller header (along with other changes if we want). This keeps all of your component variations in a single file and allows you to use them (or not use them) whenever you need them, not making them dependent on some random parent class.

Conclusion

This article covered just a small sample of the different CSS techniques that you might use to create a maintainable codebase, including the following:

  • Separating container from content
  • Defining roles and responsibilities of layouts versus components
  • Using single, flat selectors on all of your markup
  • Using other principles, such as the single responsibility principle, single source of truth, and content modifiers

The suggestions outlined here benefit projects of any shape or size, but it is ultimately up to you and your team to decide how you are going to write your CSS techniques.

CSS Writing Techniques

The only requirement I have is that you have these conversations, that you set expectations, and that you hold one another accountable during code review. If you do this, you will have cemented the core pillar of your frontend architecture and set your team up for success.

Total
0
Shares
0
0
0
0
0
0
0
Kent Wynn

I'm Kent Wynn, from Vietnam, currently working as a Software Engineer, UI/UX Designs & Frontend Architect. With years of working and project experiences, I decided to develop KentWynn.Com, a technical article-based website for sharing and learning.

Related Topics
  • css
  • frontend architect
  • html
Previous Article
css-writing-challenging-in-frontend-architect
  • CSS
  • Frontend Lang

CSS Writing Challenging In Frontend Architect

  • June 27, 2021
View Post
Next Article
Upper Lever Of Writing JavaScript In Frontend Architect
  • Frontend Lang
  • JavaScript

Upper Lever Of Writing JavaScript In Frontend Architect

  • June 28, 2021
View Post

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • What is HTML6? HTML6’s New Structural Patterns
  • How to safely upload SVG files to WordPress
  • How to Create a Blog | A Guide to Complete Blogging Success
  • Top 20 Best Free Website Speed Test Tools
  • How To Debug WordPress: A Complete Beginner’s Guide
Subscribe To Us

Get New Posts Delivered To Your Inbox

Stay Updated!

Subscribe now to our newsletter to receive latest articles, frontend trends and more!

Connect Me

I’m truly myself.

For me, success means the people we know and together what we are working on. I believe in teamwork and hard work, not magic!
About Me
Quick Navigation
  • Frontend Lang
    • HTML +
    • CSS SCSS LESS +
    • JavaScript ES6 TS
    • RxJS Library
    • Angular Framework
    • Ionic Framework
    • JavaFX Framework
    • Java Spring Framework
  • Frontend Dev
  • WordPress
  • UI/UX Designs
  • SEO
  • Tech Follows
Our Services
  • Become Frontend Master Courses
  • Marketing Services$150
  • Website Services$200
Shop Connect
  • Kent Wynn’s Shop$10
    • Wordpress Themes/Plugins
    • UI/UX Software
    • macOS Software
    • eBooks
    • Others
  • My Account
  • Cart
  • Checkout
Kent Wynn Kent Wynn
  • Contact Me
  • Hire Me
  • Donate Me
© 2021 Kent Wynn - Software Engineer | UI/UX & Frontend Architect | All Rights Reserved.

Input your search keywords and press Enter.