The days of building fixed-width web pages from pixel-perfect Photoshop files are gone. In order to produce flexible layouts that smartly adapt to any screen size, our workflows have undergone changes to be more iterative and agile. We’ve come to understand the importance of modularity and how it facilitates the flexibility we need to stay nimble in the browser. As a designer and front-end developer, this flexibility is integral to how I approach web projects. I find myself making design decisions in the browser more often than design files, and to support this workflow I need the ability to build user interface modules that can be easily extended.

Extendable Modules

What I’ve come to value highly is extensibility, a systems design principle where the implementation takes future growth into consideration. The central theme of extensibility is to provide for change while minimizing impact to the existing system. For front-end development, this means building module variations that can easily be extended to fit the needs of the user interface while preserving the underlying foundation of the module. The end result is less code bloat, less fragmentation of the code base due to one-off solutions, and code that is easier to maintain.

Building for Extensibility

To ensure consistency in the structure of our components and patterns, it’s necessary to build them in a fashion that is repeatable and predictable. The following are the basic steps I take:

Step 1: Identify the Module Type

The first step is to identify the type of module we are working with, which can be classified into one of two categories: component or pattern. A component is an independent, modular object that has no children elements, but can have modifier states that change their appearance (example: buttons, messages, thumbnails). A pattern on the other hand is an object that has children (which can be stand-alone components as well), all of which is affected by the parent object (example: header, header logo, header nav). Both components and patterns can have modifier states that change their appearance or structure.

Step 2: Define the Module Foundation

The next step is to find the component or pattern’s foundational rules that all variations of the component will inherit. These rules should be relatively minimal and reserved for properties that will rarely change. More often than not, I find these rules are properties like margin, padding, position, and display.

All code examples in this article are using BEM (block, element, modifier) naming methodology. BEM offers a number of advantages, but perhaps my favorite is that I can simply look at a piece of markup is doing from its name alone. If you want to know more about this naming methodology, I’d recommend checking out this article for a good introduction.

HTML Foundation

<div class="block"></div>

CSS Foundation

.block {
  position: relative;
  margin: 0 0 1em;
}

Step 3: Define Common Elements

If you’re building a component, then you can skip this step and go straight to the next step; but if you’re building a pattern that will contain child elements, then the next step is to define common elements. These elements are thematically-related to the parent block (but can exists outside of the pattern as stand-alone components).

HTML Common Elements

<div class="block">
  <div class="block__element">…</div>
  <div class="block__another-element">…</div>
</div>

CSS

.block__element {
  padding: 1em;
  background: white;
  border: 1px solid black;
}

.block__another-element {
  position: absolute;
  top: 0;
  right: 0;
}

Step 4: Extend with Modifiers

The final step is to extend your component/pattern with modifiers. Modifiers are essentially variations that extend the foundational block and children, and can be created as you need them.

Example of HTML modifier class

<div class="block block—modifier">
  <div class="block__element">…</div>
  <div class="block__another-element">…</div>
</div>

Example of CSS Modification

.block—modifier {
  border-top: 3px solid red;
}

.block—modifier .block__element {
  background: grey;
}

Examples

Now that we’ve taken a look at the basic steps involved with building extendable components and patterns, it’s time to explore some examples. We’ll begin with a relatively simple component and how it can be extended to cover a variety of scenarios, and then we’ll look a slightly more complex pattern.

About Components

The following is a demo of several common components along with variations. Each component consists of a parent block and modifiers that extend the style of the block. This allows for variations to be rapidly created, giving you the flexibility to quickly iterate and adapt components to any circumstance in your user interface.

Common Components Example

See the Pen Common Extendable Components by Jon Yablonski (@jonyablonski) on CodePen.

Components by their nature should be relatively simple, as they do not contain child elements. Now, let’s take a look at a something that is slightly more complex.

About Patterns

A media pattern is an object that consists of a media element (this can be an image or video), and related content (usually in the form of text). You might be familiar with a variation of the media pattern known as a ‘media object’ or ‘flag object’, which we’ll touch on in a bit. This pattern is a great example of how building with extensibility in mind provides endless flexibility.

Media Default Pattern

We’ll start with our default pattern, or how it will be displayed with no modifiers. I’ve made some assumptions here by leveraging an <article> tag to provide more semantic information, but this can be changed to be any tag you want. The core styles of our media pattern are:

1. A flex container in which its children do not wrap
2. A bit of margin

These are styles that all media pattern’s will inherit. In addition, each media pattern will contain the media item (in this case an image), and the media body which consists of a title and a definition list.

See the Pen Default Media Pattern by Jon Yablonski (@jonyablonski) on CodePen.

Media Card Pattern

While this default variation of our media pattern might be sufficient in some circumstances, there will be plenty others in which you’ll want to drastically alter its appearance. The next step is to begin identifying variations which will allow our pattern to adapt to a variety of situations. Let’s begin with a variation that is not a huge departure from the default appearance — a card variation. The premise is that very little will need to change to our markup, and we can change the appearance of our pattern by simply adding a modifier class to the parent block:

See the Pen Media Card Pattern by Jon Yablonski (@jonyablonski) on CodePen.

Media Object Pattern

Let’s say, later on, I’ve discovered I need a pattern which the image and text are displayed side-by-side when there is enough space available. This is a pattern commonly known as a ‘media object’. To create it, we can simply extend the media pattern we already have in order keep redundant code minimal.

See the Pen Media Object Pattern by Jon Yablonski (@jonyablonski) on CodePen.

Media Slat Pattern

Let’s push things a bit further with a variation that will really put it to the test. The variations we defined thus far are accommodating pretty much all my design needs, but I need one more with a little more of an impact. Let’s create a variation that is spans the full-width of the window with the body filling half, and the image filling the other. In addition to this, I want to make sure the body content aligns with the other content on the page. We’ll call this variation a ‘media slat’:

See the Pen Media Slat Pattern by Jon Yablonski (@jonyablonski) on CodePen.

Now we have several variations of our media pattern: we have the default variation, the card variation, the object variation, and finally the slat variation. These variations of our pattern are all useful in different circumstances, and they all make sure of the same underlying foundation of code! What’s great about this is that any change that happens to our pattern will affect all patterns, so each instance of this pattern will remain in sync and consistent.

Conclusion

We have covered why extendable components and patterns are better when building interfaces, which center around flexibility and maintainability. And to illustrate this, we covered the steps involved in creating some extendable components. The advantages of building interfaces in this way will become apparent right away because you will spend less time refactoring due to an unexpected design change or addition, and your styling that makes up these components will be easier to maintain.

Developing Extensible HTML and CSS Components originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.