Developing Extensible HTML and CSS Components

Share this:

The following is a guest post by Jon Yablonski. Jon is going to show us an example of how we might approach markup such that one component is particularly versatile. It works as-is, and has a standardized way of making variations (adding a single class) that allow the design to be altered to fit the situation.

Media patterns

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).

Example of CSS Modification

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

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:

A flex container in which its children do not wrap

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.

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:

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.

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’:

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.

Thanks for your article Jon! I also believe the web is all about components. In my opinion, you have misused the BEM. You have classes like media__body-list and media__body-list-title which I think do no belong to media block. Wouldn’t it be better to split the monolith into chunks? I’ll try to demonstrate it using simplified excerpt from your code:

Interesting point Evan, but I don’t think “misuse” would be accurate. It really comes down to what works best for you. Personally, I prefer seeing explicitly how children relate to the parent block. The relationship between block and element is clear (‘block__element’). This is part of the advantages of using a naming methodology such as BEM (or a modification of the syntax). The example you provided makes it seem like ‘media-info’ is a parent element and can exists on its own, which is misleading. I don’t mind ‘monolith’ because the naming makes the relationship of block, elements and modifiers very clear.

I see what you mean, but it should be noted that block elements can contain other block elements. (for example: ‘media__item item’, ‘item’ is also a standalone block).

The purpose of the naming methodology is to show the relationship between parent and children clearly, which is something I find incredibly helpful with BEM. Again, it comes down to what works for you though.

Some principles are very similar to what you’re writing here. Very interesting for anyone interested in that topic. As I’m not a big fan of the BEM notation, I prefer to lay out things the way it’s done in this book (even if similar to BEM; I simply don’t like the double underscore/dash.. It’s personal, once again). Then it’s all down to how strict we are with ourselves I guess.

👋

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress and powered up by Jetpack. It is made possible through sponsorships from products and services we like.