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">


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

Published March 06, 2016
Categorized as HTML and CSS
Short URL:


2 Comments · RSS feed
Christian Heilmann said on March 06, 2016

I really liked Heydon's "effortless CSS" talk on that topic. It makes no sense to turn maintainers of the web into developers.

Justin Avery said on March 07, 2016

The other issue I have with embedding content into that single block is when you want to retrieve the content for use in other ares besides a HTML template.

I've had RSS feeds clog up because of the funky elements used within content areas (different apostrophe's in headings the biggest issue), and while these can usually be sorted by using something like CDATA tags

// Content here

the same issues end up coming back when you look at implementing something like AMP with your database content. All of a sudden it's less of a class issue and now you have issues with the semantics of the content requiring updates.

The best approach from a CMS I've seen has been the implementation of responsive images into wordpress. The image is inserted in the same way it always has in the WYSIWYG, but when it is rendered on the front end you get the benefit of the Responsive Images markup being added for you with no additional work.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.