I would like to share my thought process behind building modular HTML and CSS components. I assume you have a solid grasp of HTML and CSS, and you are looking to get into the more complex details of writing modular, maintainable markup and styles. Let’s get started.
The Right Mindset
When I look at a block of content, or even a portion of a design, I ask myself (usually in my head, as to not sound insane to those around me) a series of questions. Actually, that’s a lie. I often perform the process out loud, much to the dismay of those around me. Anyways, back to those questions:
- What HTML markup best represents the content?
- How should this content be named?
- Should the class names used for this content be content-specific?
- Should the class names used for this content be more generic, as to represent a generic block of content?
- Do I see this pattern being reused site-wide?
- How does this element flow and interact with the content around it?
- Can the element have a standard markup and style that won’t need to be modified contextually?
Now, this might seem over-the-top, but this process occurs quickly, and the markup and styles written for the particular piece of content are refined over time. Generally, the most difficult and time-intensive step is naming. I often spend too much time trying to come up with a name that is both terse, and is well-named to represent a generic block of content that can be reused. Let’s look at an example that I’ve been dealing with recently:
Naming “The Bucket”
Ah, the “bucket.” A container, a media element (image or video), and content floated next to the media element. You see the pattern everywhere, but it’s difficult to name, and it’s very hard to make it reusable across a broad range of content. The most common example is a comment; the user’s avatar on the left, and their name and comment, as well as some post meta-data, floated next to the picture. Here’s an example:
A comment by Jason VanLue on
Dribbble
Build & Refine, Repeat
I found myself repeating this pattern multiple times throughout the application
that I am currently working on. I wrote it as a .comment one place, a
.review another place, and a .user block another place. I wanted to
abstract this pattern into its own module, rather than having separate
.comment, .review, and .user modules. Although there is a variation in
the size of the media object, I can set a default in the module, and then make
contextual tweaks where necessary, which would help to DRY up my code.
Let’s take a look at the markup and styles for the module:
Like I mentioned earlier, the .bucket-media object is more than likely going
to change size. We set the default padding-left (90px, in this case), and
adjust the module contextually, as needed.
Now, I could have taken the modularization further and given specific class
names inside of the .bucket-content, such as h2.bucket-header and
p.bucket-body, but at this stage I want my .bucket-content to be formatted
at a less-granular level. If, at a later stage, I realize that I want all the
headers inside of the .bucket-content, whether they are h2s or h3s, to
have similar styles, then I will amend the module to reflect that. It’s about
building the content, and then refining as you build out the application and
discover the repeating patterns in the application.
As this article is titled, everything is a module. I treat each block of content as something that I can reuse. I write it that way, but I don’t drive myself insane to make something overly-modular. Build the pattern, and then refine it as you go along; Just following the thought-process that everything is a module will go a long way in how you write the markup and styles for your application.