User Generated Content in a Classy World

Chris Coyier recently wrote of his issues with using classes in content and I agree with his main point entirely:

Content, like this very article you’re reading, might sit in a database and thus be spat out into a template. The content is unlikely to change but the template can go through many revisions. Knowing how many classes you have and where they are used throughout your content can be difficult.

In some cases, like for us web developers who maintain our own sites through a content management system (CMS) like WordPress, adding classes is an easy way to maintain and establish special styling throughout our sites. But you have to remember what those classes are and how to use them.

The way I visualize content is like it is part of a module.

Here’s how the template looks:

<div class="article">
  <h1>Page Title</h1>
  <div class="article-content">
  {{content}}
  </div>
</div>

Kinda BEM, All SMACSS

The module then includes everything that might appear in {{content}}. That means that our CSS might look something like this:

.article-content h2 { … }
.article-content p { … }
.article-content ul { … }
.article-content li { … }

For those who’ve gone all-in on the BEM naming convention and approach, this might feel uncomfortable. We’re using descendent selectors instead of applying classes to the content.

In SMACSS, I never dictate that everything must have a class. If the HTML is predictable, using child selectors in this way can save you from having to add classes to everything. (Not that I ever use that as a reason to do something. The “Don’t Repeat Yourself” (DRY) movement can sometimes take things to the extreme with very little gain.)

In this way, including the article content as part of the article module makes sense and using descendent selectors sits right at home, if you’re using SMACSS.

Element styles

The alternative approach I often see is where people will style their content as the default element style and override for the rest of the page.

h2 { … }
p { … }
ul { … }
li { … }

.sidebar > h2 { … }
.modal > h2 { … }

There’s nothing inherently wrong with this approach, either. Just recognize that by over styling elements, you run the risk of needing to unstyle for everywhere else. Thereby, creating more CSS than you might normally need to.

Embedded Objects

In an ideal world, a CMS would allow you to define and embed “objects” inside the content. An object has some complexity to it. For example, a pull quote might have a byline. A photo might have a caption and a credit. Or maybe it’s even more complex than that.

The problem is that rarely have I seen a CMS that handles this well. Having a large text box isn’t conducive to embedding complex objects in it. Art directing—as many people try to do with a big WYSIWYG text box—with a collection of objects isn’t straightforward. Nor is it easy to design an interface to enable powerful art direction.

The other problem is that giving the power of art direction at the content level often results in many scenarios, like various screen sizes and layouts, being ignored. They’re ignored because it’s difficult to raise awareness for these scenarios inside of a content creation tool. It slows people down.

This is a really hard problem. It’s why we try to separate content from presentation: it alleviates the user from having to think through all the ways in which their content might be used.

Forcing users to use interfaces to create structured content allows more freedom to change the styling underneath that structured content, knowing that the content doesn’t need to be revisited.

No one right way

As I like to say, in web design, the answer is usually “it depends”.

If your content is simple, embedding classes inside your content may introduce technical debt that’s difficult to clean up as your site evolves.

If your content is complex, trying to style everything embedded in the content as one behemoth piece will be difficult as there just aren’t enough HTML elements to differentiate all the possible objects. (Hey, maybe Web Components could save the day here; I haven’t done any tests to see how feasible this might be.)