Thinking Modular CSS

Learn the how behind modular CSS by analyzing the process.

The name of this talk is "Thinking Modular CSS." Before we get started, I’d like to take a moment and talk about Dan Denney.

I’m fortunate enough that I get to work with Dan Denney. He is one of my favorite people on this planet.

The story I like to always tell that illustrates this is his encounter with HTML emails. I’m sure all of us here know how painful they are. You have to code in tables, use inline styles, and it’s just generally not fun. All of our front-end developers just get in, do them, and get out. However, not for Dan Denney. Instead of pushing through and moving on, what did he do? He made our HTML emails awesome, pushed the technology, talked about it in the community, and now wears the crown of “HTML Email King.” (in my eyes)

He’s truly a saint, and everyone needs to know that.

In all seriousness, though, I love this conference. I've only missed it once, and I look forward to it every year. The Denney family does a tremendous job, and I’m super pumped to be here, and to be speaking to all of you.

I know this is the last year, but I'm absolutely certain Dan Denney will continue to build the front-end community in a thousand other ways.

And as proof that I’ve been here before, here is a picture of me from last year. Funny story: in our company chatroom, if you use the word "unimpressed", this picture shows up because, apparently, I look unimpressed.

However, I think I was more just in awe while looking at all the bacon-themed snacks.

If you've been here before, you know what I'm talking about.

So what am I here to talk about? This talk is called, "Thinking Modular CSS". What does that mean?

I really want to explore the thought process behind writing modular CSS. We’ve talked a lot about the “how” of things like object-oriented CSS (and other CSS methodologies), but we haven’t really talked about the process that we take to get there.

It’s something that we see with new front-end developers that we teach our system to. They understand how we structure things, what we call certain elements, how we organize our CSS, but how we get there, the thought process, is the tough part to teach.

So how are we going to go about this?

  • First, we’ll define “modular CSS.”
  • Next, we"ll talk about the process of writing modular CSS
  • Then we"ll go through a set of popular sites to actually apply this process and knowledge we’ve all gained.

Before we get into that, I want to give you some information about me. I'm Drew Barontini. You can find me on Twitter, or most places on the Internet, @drewbarontini.

I do say "most places on the internet" because I use that handle everywhere. If I'm on the service, that's my username.

I'm a front-end developer at Code School.

What is Code School?

What is Code School?

If you're not familiar with Code School, it is an online platform for learning web technologies.

We have interactive courses teaching technologies like Ruby on Rails, Sass, Git, Angular, iOS, and a lot of other languages and frameworks.

What are my responsibilities?

What are my responsibilities?

  • Our .com, codeschool.com, holds all of our courses, our users, our teams, and it allows them to track their progress and pick and choose which courses to take.

  • I’m also responsible for our course engine, which is a separate entity from the .com, and it’s what runs each course.

  • In addition to that, I also oversee the buildout of individual courses, as well as keeping courses up-to-date.

"Front-end Development" is what I do.

"Front-end Development" truly is a specialization; it's a craft, and it's not easy to do. It's not just for designers who code or developers who write HTML & CSS.

It's an area of focus for unique individuals with particular skills.

"Particular skills."

Developers used to trample over the HTML and CSS, largely qualifying their actions as "HTML and CSS are so easy, any of us can write it."

Although HTML and CSS are easy to write, they aren't easy to write well.

We're building complex systems. Our styles are built out on large-scale applications that need to be performant and easily understood by a large team.

Our styles need to be flexible so that we can add new features and pages, as well as have a solid foundation for each new site or application that we build.

Modular CSS

Modular CSS

In order to create flexible and modular systems, we have to adhere to the ideas of "Modular CSS," so let's talk about those ideas.

I will use the words module, pattern, and component interchangeably; they all refer to a set of self-contained styles.

From Pages to Components

From Pages to Components

We've made a shift from thinking of our styling in terms of pages to styling in terms of components (patterns, modules).

Instead of looking at a page and defining it as its whole, we now need to look at all the various modules that make up the page.

Dave Rupert says it best when he says that we should focus on creating front-end modules as reusable solutions for complex pages.

This page isn't the "Home Page" of ted.com.

It's a complex page fit together with front-end modules.

It's a collection of resusable style patterns.

Modular design is the principle that we use to get there.

Modular Design

Modular Design

"Modular design" is defined as an approach that subdivides a system into... blah, blah blah.

Your CSS should be:

  • Broken down into smaller parts, smaller sets of styles.
  • Independently created, so your modules can be properly encapsulated (which we'll get more into in a bit).

  • Have the ability to be ported from system to system with minor modifications, whether it's another site, or simply various containers within the site.

Breaking your CSS down into smaller chunks will ultimately result in more maintainable code. Let's look at an example.

We have a thumb module for handling thumbnails, and, in this instance, circle avatars by setting a border-radius of 50%.

This module applies a small set of extendable styles.

Single Responsibility Principle

Single Responsibility Principle

It also adheres to the "Single Responsibility Principle," which is something that I always try to adhere to.

The single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Let's talk about two separate parts of that definition. Firstly, our CSS modules should only have one responsibility, one job.

It's helpful, when creating your modules, to add a comment block at the top of the file that explains, in one sentence, what that module does; what is its responsibility.

Now we know what our module is responsible for, so we can build it.

Here we have a .cell module that handles the container for content. It makes sure that a section is centered and has its max-width set appropriately.

This module only handles width limiting, and it adheres to the Single Responsibility Principle.

But what about the second part of the definiton: "encapsulated by the class"?

In our newest course interface at Code School, we have this bar at the bottom of the interface.

We call it the omnibar.

In the omnibar, there is a button on the far right.

The button is positioned absolutely to the right side of the omnibar.

And here is the markup for the button.

How would we go about positioning this button correctly?

We could just target the .btn and position it.

Obviously, though, we don't want every button to be absolutely positioned.

We could just target the .btn within the .omnibar, but we're breaking the idea of encapsulation by having our two modules know about, talk to, and directly affect one another. Let's change this.

We add a new class to the button, and now we can target that class.

We add both the omnibar-btn and btn class to the element to handle their own responsibilities.

Now, as we want, the omnibar module only knows about itself, and it handles how its elements are positioned. The button adds the styling, but doesn't need to know about how it's being positioned within the omnibar.

Positioning and layout are constant struggles with modular CSS.

You'll have to abstract a lot of the layout styling to a more global component to keep your modules properly encapsulated.

Classes

Classes

Now let's look at some more practical applications of "Modular CSS."

This one seems to be more commonplace these days, but it's still worth mentioning: It's best to stick with only using classes, avoiding IDs altogether.

IDs are too specific, and they'll cause you unnecessary headaches.

Classes, on the other hand, flatten the specificity of your modules to make sure your styles are applied properly without having to fuss with specificity issues.

This may seem redundant, but we want to call .table, not table.

The table element is on a different specificity level.

The .table class puts it on the same level as our other modules.

Establish Naming Conventions

Establish Naming Conventions

The next practical application of modular CSS is to establish naming conventions.

It doesn't matter as much what your naming conventions are, just that you have them. Decide with your team (or yourself) what those should be, and make sure to stick with the system, but be open to evolving it over time.

Nick Walsh, a front-end developer at Envy Labs, had this great quote that we always reference when we talk about how we write our CSS, and how frequently we change it.

This is how it is now, until we change it.

It's very true. We constantly evaluate and evolve the system as we work on new projects, but that’s what makes the system better: constant evaluation.

MVCSS

MVCSS

At Code School (and Envy Labs), we use MVCSS, which is a Sass-based CSS architecture that I created with Nick. To give you a sample of some naming conventions, I'll talk about how we do things.

This is by no means preaching our method. This is merely an example that can help guide you to establishing your own naming conventions.

We use camelCase for multiple words, and we use a hyphen to separate multiple words with meanings.

Modifiers

Modifiers

The first word with meaning is for Modifiers.

If you're familiar with the BEM Methodology, this is the same idea (the "M" in "BEM").

A modifier is an alternate set of styling on a module.

Say, for example, we have these two buttons. The button on the left is our base button, and the button on the right is an alternate styling of the base button.

Here are our base .btn styles.

We use double-hyphens (--) to denote a modifier.

So here we define our button modifier, which is an alternate styling of the base .btn.

Note: we're using "b" as a hierarchical designation for our alternate button, since it's a "secondary" button.

We call our btn class for the base button, and add both the base btn class and the btn--b modifier class on the modified button.

States

States

Next we have States.

States are generally used for hooks that are added conditionally with JavaScript.

We use the convention is hyphen (-) state name.

So, for example, we have this .dropdown that is hidden by default, and is shown when the is-active state class is added. Simple as that.

Context

Context

Next, we have Context. Oftentimes, in CSS, we'll need a parent container to be adjusted in order for our module to be styled correctly. For this, we use a context class because we don't want the parent container to make a change for another module, thus breaking encapsulation.

We use the convention has hyphen (-) context name.

Let's say that we have a .dropdown module, and when that .dropdown is inside of a parent container, it needs to have position: relative on that parent container to set the positioning context. Rather than adding position: relative to that parent container, we can use a "context" class to handle this for us.

And then we add that context class to our parent container, which keeps our modules independently created.

In this instance, the .container isn't making a change to accomodate our .dropdown. It doesn't even need to know about it, and this handles that.

Submodules

Submodules

The next naming convention covers Submodules.

Submodules are elements that are scoped to a parent module.

For example, earlier we had .omnibar-btn, which was a submodule class. The btn is a submodule of the parent omnibar module.

We use a single hyphen (-) to denote a submodule. So here, for example, a module hyphen submodule.

That's a brief look at the naming conventions and structure that our team uses, and hopefully it's a useful example that you can work off of. We borrowed a lot of ideas from great methodologies created by insanely smart people.

Make sure you look at all these methodologies, as one might fit your way of working the best. They are also great starting points to building your own system.

Abstract Structure

Abstract Structure

The next practical application of "Modular CSS" is to Abstract Structure. Let's look at an example.

So here we have a .nav module that is being floated to the right with a set 50% width. This is all well and good until we have a second .nav block that needs to be positioned to the left, centered, or have a different width.

Ask yourself, why is this navigation block being positioned to the right at 50%?

Is it because it's in another module, like our site-wide header?

Abstract up!

Use something like a grid to handle the structure. The individual module doesn't need to control its layout; it should flex and fit in any container.

A higher-level module now handles the structure.

Avoid Magic Numbers

Avoid Magic Numbers

Next, avoid magic numbers. What am I talking about when I say "magic numbers"?

You know what this is. We all do it. These "magic numbers" are best to avoid whenever possible. You want your styles to be predictable and flexible, and these "magic numbers" break that. However, when you do use them, which is sometimes unavoidable, make sure to document it.

Simply add a comment marking it as a "magic number." Now we have a way to search across the project and find the magic numbers whenever we do a refactor.

Evolution of Modular CSS

Evolution of Modular CSS

We've seen a gradual shift in the way that we think about modular CSS, and how our styles should be written. Let's look at an example.

We'll use the Dribbble shot as an example. How would we have marked this up?

Initially, we would have marked this up with a class of shot, and then all of our HTML elements inside.

We called those elements scoped within the .shot class in order to style them.

This worked, but we quickly ran into issues when we changed the markup. What happens when that h2 turns into an h3?

Well, not only do we have to change it in the HTML, but we also have to change it in the CSS.

Ok ok, we'll scope everything to the .shot!

We add a shot- class to everything within the .shot, and now we have hooks to target each of our elements.

We have another problem. What if we use this same pattern for another element that isn't a "shot"? The name "shot" doesn't really make sense for that element, so we need to make it something more abstract.

Ok ok, we'll abstract the name!

Okay, we call it a card; that's way more abstract, so we're good, right? Well not quite.

We realize now that our .card-list styles are being duplicated on different lists throughout the site. We need to pull that out. I think you see where this is headed.

We change the .card-list to .list, thus creating a new standalone list module.

Now we have our .card styles and our .list styles separate.

But this keeps happening for all of the elements in the .card until we realize that it's not just a shot or a card.

It's several modules working together to build the pattern.

This is the realization that we're having now.

We're creating a collection of independently created modules that can be used together to create multiple style patterns.

How do we find these patterns?

Process

Process

By establishing a process.

Although amusing, this is not the process.

I like to break it down into five steps.

Identify

Identify

Obviously, the first step is to identify the patterns that you'll start with when building your modules.

In order to write the pattern, we need to find the pattern.

Structure & Layout

Structure & Layout

I like to start at the highest level: the structure and layout elements. These tend to be the most reusable elements project to project.

Let's take a look at some example patterns to get an idea of the process we take.

Row

Row

The first pattern is the Row. Freqently on the web, you'll see these full-width bars, generally with a background-color or image.

You can see it here on Twitter's About page. They have a few different row variations, or modifiers.

The first row is in the header, and it's a standard white background with a box-shadow.

The next row is a light grey background with a box-shadow.

Then we have a more complex row with a background-image on it.

There isn't much to the pattern, and it's easily reusable across your projects.

Cell

Cell

Virtually all sites have some container or wrapper that keeps the content contained. We call this a Cell.

She has her content contained within a set width so that things line up nicely.

Well

Well

We call this next pattern the Well, and it handles the vertical spacing, and it generally resides within a row.

Again, on Meagan Fisher's site...

You can see that there is some set spacing at the top and bottom of each row, and alongside each cell that is handling the width limiting.

The .cell and .well are used in conjunction with one another.

And you can specify modifiers to your .well that will handle various vertical margins, like this --l, or large modifier.

Grids

Grids

We're all familiar with Grids. They've existed for a long time on the web, and they are a very common and clear pattern to identify.

On the GitHub Guides page...

We can see that they have each "guide" split into a 50/50 grid.

And on the GitHub user profile page...

We can see that they have a lot of different grids, including grids inside of grids.

Bucket

Bucket

The media object is the cornerstone example of OOCSS, and it's another very common layout pattern that you can use on most projects. If you aren't familiar with the pattern, it's a media element with content next to it. We call it the Bucket.

A comment on Dribbble would be an example of a bucket.

It has a media element with content floated next to it.

Also, on the Dribbble profile pages, there's another bucket.

Again, it has a media element with content floated next to it.

Common Patterns

Common Patterns

Once the Structure & Layout patterns are identified, look for the Common Patterns that you continually encounter and build for each project.

Let's look at some example common patterns.

Card

Card

Cards are stylistic containers for content that generally have the following styles:

  • background-color
  • border-radius
  • box-shadow or border
  • padding

Looking at Dribbble...

Each shot has a stylistic container that I'd call a card.

Lists

Lists

Lists are everywhere on the web, and it's a very common pattern that you'll have to write on each site.

Here, on the Designer News site...

We have a variety of different lists.

Unique Patterns

Unique Patterns

Finally, find the more unique patterns. Do you notice very specific style patterns?

Again on Dribbble, we can see an example of a more unique pattern.

Each shot page has a list of colors contained within a shot. This is a type of list, but it's a more specific pattern to this particular site.

Front-end Audit

Front-end Audit

To help you document these, you can use what I call the "Front-end Audit."

It's simply a document that you can use to outline and explain all of the components of your front-end architecture, among other things.

You can find this on my GitHub.

Define

Define

After you've identified the pattern(s), you need to define them. This is the tedious part, because we want to give it a meaningful name that isn't overly specific.

Responsibility

Responsibility

First, though, determine what the responsibility of the module is. That will help dictate the name of the module.

For example, this module handles the video player.

Now that its responsibility is defined, we can easily name the class.

And any modifiers.

Or submodules.

Build

Build

Now that the pattern is identified and defined, we can build the module.

This is the fun part, because it's where we write out our styling for the module.

Combine

Combine

With your module built, you will want to combine it with other modules that you have created.

The goal of a flexible CSS architecture is to have separate, encapsulated modules that can work together and be mixed and matched to create various styles.

For example, your layout patterns — row, cell, well, and grid, will be used in conjunction with one another to lay out the page.

As you can see here, we're using our card (stylistic container) alongside our video module (video player) to add a nice little style to our video player.

Refine

Refine

With all of your modules now working together, you'll want to refine, or refactor, as necessary.

This is a constant, iterative process.

You're never going to write something perfect the first time (most likely).

Be sure to constantly evaluate and refactor your CSS.

Don't be afraid to write something specifically, and abstract as you build out the site. Frequently, we're building sites in an unpredictable manner, so we'll have to change the structure as we build out the system.

Find weaknesses in your code!

Look for the magic numbers! See if you can remove them and make your styles more predicatable.

Are you setting fixed widths on non-layout modules? You want your modules to flex to fit any container, and this is an easy way to spot places you need to refactor.

If you find yourself unsetting a lot of styles, you might want to consider a refactor. Your base module is doing too much.

Are you repeating styles?

If so, use a comma-delimited list of selectors for the shared styling.

Use tools like csscss, csslint, and Style Stats to help you spot repetition of your code, as well as other useful information. You can also use things like @extend in Sass, or abstract out shared styles to another module.

Examples

Examples

Now that we've defined "Modular CSS" and talked about the process of discovering, writing, and refining patterns, let's take that knowledge and walk through some real sites to determine how we'd structure our CSS.

Dribbble

Dribbble

We've seen a lot of examples from it, so now we're going to go through the process we just talked about, using Dribbble as an example.

We're going to focus on the front page when you're signed in.

We have our header, a list of shots, a bottom content section, and the site-wide footer.

Structure & Layout

Structure & Layout

As we talked about before, we'll start at the highest level, the structure and layout.

Looking at the main page...

We can see there is a full-width bar of color in our header.

There's also a row of content for our list of shots.

And, in the footer...

A row of content for the bottom section of the main content area.

And a full-width, white background row of content for the site-wide footer.

You'll remember that we called this pattern a Row.

So with the pattern identified, we define the responsibility and name, and then build our base module, as well as our modifier classes for the alternate background colors.

The --a and --b modifier classes are used to indicate hierarchy, since I want the dark grey row to be the primary row, and the white background to be the secondary row. It's important to note that this can change as you build out the site.

Alright, now let's look for the next Structure & Layout pattern.

We can see that the content is nicely confined within a set width.

That same width extends all the way down the site.

Cell

Cell

We use the Cell pattern for this, which will handle the width limiting.

With the pattern identified, we define the responsibility and name, and then build the module.

In this case, we just need a single .cell class to handle the single width of the site.

Let's look for the next Structure & Layout pattern.

We can see that there is spacing in between each "row" of content.

And looking at the bottom of the site...

We can see this pattern carry through.

We use the Well pattern to manage the vertical spacing on the "rows" of content.

We define the responsibility and name, and then build the module.

Here, we're setting the base .well module, as well as a large (--l) modifier class to add increased spacing, where necessary.

Let's look for the next Structure & Layout pattern.

We can see that we need to arrange a lot of elements on a grid of some sort.

And looking at the bottom of the site...

We can see that we have various grids to arrange the content.

Grid

Grid

Clearly, we'll use a Grid to manage the grid-based element arrangement.

We define the responsibility and name, and then build the module.

With these four modules built, we have a nice foundation for the layout of this page, as well as all future pages. Also, we can see here that we built our modules independently, so it's easy to combine them, like the .cell and .well, which will each handle their single responsibility without knowing about one another.

Let's look for the next Structure & Layout pattern.

We can see that, under each shot, there is an author image, or media element, with their name, or content, floated next to it.

In the footer...

We can see the same pattern for a few different elements.

  • The 'Equipment Shop' blurb
  • The ad
  • The number of pixels dribbbled infographic

For this, we'll use the Bucket, also known as the media object.

With the pattern identified, we can build it out.

Common Patterns

Common Patterns

Alright, now let's look for those Common Patterns.

Looking at the site...

List

List

We can see there are several Lists throughout the site.

  • The header has two separate lists
  • There is an inline list of navigational links at the top of the main content area
  • There are lists of metadata in each shot

And looking at the bottom of the site...

  • There is a list of job posts
  • Block-level lists of links in the footer
  • A list of social icons in the footer

Obviously, we'll use a List module.

Generally, I like to limit my List module to handling text-only lists. However, I've recently added the "object" list, which does a display: block and float: left, and this is for those non-text items that can still easily be managed by the List module without stretching its responsibility.

With the pattern identified, we can build the module. Here, we're defining our base module, which will be block by default-since it's the most common occurrence-and then inline and object modifiers.

Alright, let's look for the next Common Pattern.

We can see that we have user avatars all over the place, and they are indeed circle avatars.

Thumb

Thumb

Let's build a Thumb module to handle this pattern.

We create our .thumb class, and now have a small, extendable pattern to add to any of our img tags.

Alright, let's look for the next Common Pattern.

We can see that we have a lot of icons used throughout the site.

And in the footer area...

There are some additional icons we'll need to manage.

Icon

Icon

We'll create an Icon module to handle this for us. We could get into a really long discussion on the how of managing icons on a site, but that's not the important part here.

So with the pattern identified, we can then build it.

Let's look for the next Common Pattern.

We can see that we have a search bar in the header and, although we could just manage this as a submodule, we want to plan ahead and build out a more robust module for future forms that we may have on the site.

Form

Form

So with the pattern and responsibility identified, we can build a Form module.

We have our base .form module, and then the .form-input submodule for this search input. Now, since we have the search icon within the input, we'll want to create a .form-input--search modifier to handle those alternate styles.

Alright, let's look for the next Common Pattern.

As we identified earlier, we have these stylistic containers around each shot, which have a white background, a box-shadow, a border-radius, and some padding.

Card

Card

We call this pattern a Card. Its responsibility is to handle the site-wide stylistic containers.

With the pattern identified, we can then build it.

Unique Patterns

Unique Patterns

With the Common Patterns defined, we can now look for the more Unique Patterns. Are there any patterns that are unique to this site?

Although I can't really see any unique, or site-specific, patterns, we might want to build a .header module to handle the site-wide header for things like vertically aligning the navigational elements.

However, we might also just build a module to handle vertically aligning elements, so we wouldn't need the .header module. This is more of an implementation detail.

After completing this process, we can see that our front-end audit for the CSS architecture looks something like this.

This may seem like a large amount of modules for a single page, but remember, they are very small, extendable modules, and they will lay the foundation for the rest of the site.

I really wish I had the time to go through each module's code individually, but that's not the real purpose here, and the CSS is really simple. However, the code is up on GitHub for you to look at.

Digg

Digg

Now, let's look at a completely different site to see how the process compares.

We'll use Digg, which is a site that aggregates popular news stories and videos.

First, we'll get a lay-of-the-land. We can see that we have a header and list of articles.

A section for the most popular videos, as well as a few different story lists.

And, at the bottom, we have a fairly standard site-wide footer.

Structure & Layout

Structure & Layout

Okay, let's start with the Structure & Layout.

Looking at the site, we can identify a similar pattern that we've seen before.

There is a solid white background and box-shadow on our header.

Then there's a section of content for our stories.

In the middle of the page...

We can see a section with a fancier background for the most popular videos.

Next, we have another section for our most popular and upcoming stories.

And in the footer...

We have another solid background color for that section.

Row

Row

For this, we'll use the Row module to manage these sections.

  • We build out our base .row
  • Two modifiers (--a, --b) for hierarchical header/footer rows, so the white background and shadow, and then the medium grey footer background.

  • And then a highlight modifier for that upcoming videos row, since I don't want to classify that as a hierarchical element. However, that might change as we build out the site.

Alright, now let's look for the next Structure & Layout pattern.

We can see that our header area constrains the content to a width.

This also happens for our main content, but it's a smaller width.

In the middle of the page...

That width constraint carries through.

And at the bottom of the page...

We have that same width constraint on our content.

Cell

Cell

For this responsibility, we'll use the Cell.

Our base .cell is the most common occurence of the module, so it will set the standard content width. We'll also create a --l, or large, modifier class to manage the larger width constraint in the header.

Okay, let's look for the next Structure & Layout pattern.

We can see that we have some vertical spacing at the top of our row of content.

In the middle of the page...

We have some vertical spacing within our popular videos row, and the top of the next content section.

And at the bottom of the page...

There is more top and bottom spacing for our content section, and then the footer row.

Well

Well

For this, we'll use the Well.

With the pattern/responsibility identified, we name and build the module.

We have our base well class, as well as a large (--l) modifier class to handle rows that need additional spacing.

Let's look for the next Structure & Layout pattern.

We can see that we have our elements arranged on a grid.

In the middle of the page...

We have more grids.

And in the footer...

We have some nested grids to get things arranged correctly.

Grid

Grid

Clearly, we'll use a Grid module to handle, well, the grid.

Hopefully this is feeling familiar.

With the pattern/responsibility identified, we can then build out our encapsulated grid that can be combined with other similarly created modules.

Let's see if we can identify another Structure & Layout pattern.

We can see that we have a section of stories with a media element (image for the story), with content floated next to it.

Bucket

Bucket

If you recall, that's the media object or, what we call, the Bucket.

With the pattern/responsibility identified, we can then build the module.

Common Patterns

Common Patterns

Alright, with our structure and layout in place, let's look at some of the Common Patterns.

Looking at the site...

We can see that we have some element lists for things like navigation and metadata.

In the middle of the page...

We have lists of stories with metadata.

And in the footer...

We have a block-level list of social links, as well as some standard inline text lists at the very bottom.

List

List

We'll use the List module to handle this responsibility.

Unlike Dribbble, our base .list is, at least so far, usually an inline list, so that will be the default. We'll also create a --block modifier class to handle the block-level lists.

Alright, let's look for the next Common Pattern.

We can see that we have a little magnifying glass icon for search.

In the middle of the page...

We have play icons on our videos.

And in the footer...

We have some social icons.

Icon

Icon

So, we'll build an Icon module to handle our site-wide icons.

With the pattern/responsibility identified, we just need to build out the module.

Okay. Looking at our site, we can see another Common Pattern.

In our footer, we have some clickable buttons.

Button

Button

Obviously, it would be a good idea to create a Button module.

With our pattern identified, we can define and build out the module.

Looking back at our site, we see another Common Pattern.

A Form for 'The Daily Digg' email.

Form

Form

Like with Dribbble, we're going to plan ahead on needing more forms.

We build a simple Form module with a base class, and a submodule class for the form-input.

Unique Patterns

Unique Patterns

Okay, that's it for our Common Patterns, so now we'll see if there are any Unique Patterns in the site.

Similar to Dribbble, we might want to create header and footer modules to manage any typography in those areas, and even a story module to handle the typography of each of our news stories.

Alright, let's look at the front-end audit to see how our CSS architecture is looking. We can see that we've used a lot of the same patterns on Digg as we did on Dribbble. This illustrates that, if you write things modularly, you can easily reuse your modules from project to project.

And, if you want to take a look at the code, here's the URL again.

Always Be Evaluating

Always Be Evaluating

I'd like to briefly sum everything up by saying, "Always Be Evaluating." Make sure that you spend the time assessing your code and your methods for writing your CSS in order to improve you efficiency and thought process. We always hate things we wrote a few weeks ago, and that's what will drive you to write better, more modular CSS.

It's a process.

Thank you!