WordPress: To componentize or not? Your content is in question

When considering a component-based approach within the confines of a CMS, one of the biggest challenges presented is the question of when you should componentize content and when should you create/use a discrete field. Every CMS has its own field-based defaults, but when should something be made to be reusable as a fully realized piece and when should it simply be a field? In this post I’ll share my experience in the land of componentization and describe my endless quest to answer that very question.

Along the way we’ll explore where all of this talk leaves themers. Aiming to answer the question how can themers effectively solve for component context?

Defining a component

A component can refer to lots of things. At its most basic level, a component is a piece of content that can be picked up from one place/page and put down in another, and is guaranteed to still fit in. It’s a self contained thing. It knows where it ends and where it begins. In a perfect world a component might have its own folder, called component-name and contain appropriate files like component-name.css and component-name.js. All one magnificent and clearly defined thing.

A component is HTML, text, CSS, and maybe some JS. It is a defined piece that can be themed once and pulled into any content situation or context. It is a designed and structured mold to funnel your content through.

We want it all

We, as a web industry, have been championing and striving for the holy grail of all web experiences: componentized purposeful content. The context dictates and defines the form. Should a <blockquote> render differentially inside a particular section paragraph? If so, why? and how can we accomplish it? If an H1 and and H2 appear directly under one another how should spacing change? Is this an editorial content strategy (implementation) patte\r\n \to set or a theming one?

This post will explore component based design and outline my experiences along the way.

When To Componentize Content

You should componentize content when it helps content authors, designers, and developers do their jobs better. Also, and most importantly, when it does the above AND provides a more beneficial experience to readers of said content.

You shouldn’t componentize content if it’s a one-off solution to a content strategy exception. For example, if only one piece of content of all pieces of content in the “article” content type needs to have a “special thing” field. Perhaps, instead of creating a reusable field for that one instance, we we instead use a regular body field.

The importance here is to question componentization and have a strategy in place. This very much boils down to organization and upholding a maintainable standard moving forward. That standard can change, of course, but it has to start somewhere.

How To Componentize Content

The struggle of finding what is enough HTML markup to facilitate effective theming is real, and it’s a doozy of a problem. Some CMSs make it difficult to implement your own ideal structure—forcing you to contend with what’s provided. Others offer varying levels of technical solutions to overriding markup.

WordPress allows us to set our own markup, globally, with relative ease. This can be tremendously powerful and rewarding, but it can also be a disaster if implemented poorly or without future thought. The talk of theming conventions is a lengthy one too—the pros and cons of BEM, SMACSS, or the opinionated component approach of Pattern Lab, for example, versus your own subjective methodology. The goal is all the same: provide your future self and any dev coming into the project with less historic project knowledge the most intuitive structure to facilitate rapid ramp up and able to start contributing meaningful code. Let’s focus on theming unknown component stacking and configurations.

Set a baseline rule

This is the setup to answer the question of how to theme for context. To set the stage, perhaps you have a common CSS class that wraps your component contents. Say we use .component as that defined class. I like to think of component baseline styling in the same way I think about typography baseline styling—apply some common spacing rules that can be broadly applicable. From there add exceptions when necessary. The complication here is in not having a predictable content strategy and rhythm. What if we don’t know how components are going to layout on the page? Or if we do know and have planned for variation and content flexibility?

To make sure all .component items are properly centered, I’ll typically nest a helper class div .container that applies a rule of margin:0 auto; to center all component contents and a max-width:700px to limit content width. This way the component type class could have a full-width background-color applied to it and be free from any width limitations. In a Sass setting, we would assign a variable to max-width:700px as $max-width:700px; Then we have the freedom to change this width as needed. Typically this value is governed by readability through typographic measure.

I’ve found that starting simply and generally is the best approach (the same could be said for setting any CSS rule). There are so many ways to approach CSS and any one-approach-fits-all-scenarios is a difficult problem to solve. The following examples might seem simple, but in a situation where you’re given free reign to control the markup it’s an important consideration and mental reset, so-to-speak.

In the following CodePen examples, I’m structuring the HTML as discussed above—with each .component structured in a class-driven div. These are intentionally simple as our focus is effective spacing strategy between components.

Margin-bottom: setting broad spacing rules

One of the most challenging aspects of effectively theming modular components lies in setting spacing rules. You want to balance the explicit rules with the exceptions. I would say for 90% of all use cases, applying a generous margin-bottom does the trick for effective spacing between reusable parallel components. But how can themers go beyond and set rules for the unknown combinations? Maybe we shouldn’t? Maybe this is a non-issue and should really be a content strategy problem? Or rather, the solution is planned for as part of the content strategy. In this “solved by content strategy” scenario, writers and content authors are aware of any space rules specific to their componentized content. They understand the rules that have been defined through conversation between developers and them. Those rules come from both a need for consistency and efforts to uphold brand content strategy. This established content strategy would dictate how content should be authored and how that content turns into (or gets a direct mapping to) components. This approach is not as modular, because it has rules to its modularity. I mean, everything has rules, but these would be more specific and limited in scope. But if it makes sense for your content strategy, then it may be the best approach. In defining and setting these rules, the struggle lies within effectively straddling and accommodating the line between imposed structure through predictability/templating and flexibility to vary content appearance to tell unique stories. The difference is as simple as being proactive versus reactive in strategic approach. Planning out all use case scenarios is helpful, too. Let’s take a look at setting broad spacing rules.

See the Pen WP Component Post Snippet 1 by Joe Tower (@joetower) on CodePen.

Let’s consider the above approach and how it can break down. The 10%, if you will. Say you add two heading components on top of one another. Now you have too much margin between visually-groupable but hierarchical components. It feels wrong. The vertical rhythm is all wrong.

See the Pen WP Component Post Snippet 2 by Joe Tower (@joetower) on CodePen.

Adjacent sibling selectors: getting more specific

We could introduce some nifty adjacent sibling selector magic and set a rule for

.heading-component + .heading-component {
margin-top: 0px;
} 

and change our baseline rule to margin-top: 30px; and call it a day. Sure, this could be a successful option. It aims to solve one possible spacing issue. So what if we want to get out of this conditional logic and rethink a more simple and broadly applicable option?

See the Pen WP Component Post Snippet 3 by Joe Tower (@joetower) on CodePen.

Back to basics: Add an exception/helper class

We could add an exception/helper class that is author selectable. Something like .no-margin-bottom assigned to any component that selects it as an option. It would keep our CSS free from complicated and seemingly difficult to maintain rules. It can be a slippery slope of exceptions when you start down the path of selector combination rules.

See the Pen WP Component Post Snippet 4 by Joe Tower (@joetower) on CodePen.

This option gets my vote. It offers the perfect combination of selector shallowness, maintainability, and being applicable only when called.

Within WordPress it’s easy to implement using a custom select option field for each component, then passing those field values onto each component div as a class. Sure, there is a bit more template management, but it again, allows for shallow selector rules—for which, I’m guilty of losing sight of from time to time.

Bonus option: Add a spacer.gif / horizontal rule component

To accommodate additional component separation and spacing needs, a spacer.gif component or hr rule might be a perfect solution, standard best practice of when to use the hr element withstanding.

See the Pen WP Component Post Snippet 5 by Joe Tower (@joetower) on CodePen.

Real World Examples On fourkitchens.com

Looking at our services page, here are frontend and backend screenshots of components in action.

Here we have the page title plus six components. Each component has general spacing rules applied.

Here we have the fields as arranged on the backend. All but one are collapsed.

Advantages to this approach:

• Your editors will be happy to tell stories more effectively.
• Content no longer exists in a seas of WYSIWYG body fields.
• Themers will be happy to implement components once in a template setting and reference them everywhere.
• Keeps CSS selector pool shallow (DRY code).
• If other best practices are also adhered to, developers will have a more maintainable code.

Disadvantages to this approach:

• Chunking and abstracting content can be more challenging to maintain, as it’s fragmented into fields opposed to one stream of content. This can also take a change of mental model/approach to writing content.
• More template files might be produced than you desire—this can be an advantage if you label and organize components effectively.
• It’s not as flexible as a content API based approach would accommodate. Services like Contenful or GatherContent truly allow for content from HTML structure separation.

What’s The Point?

Sometimes it’s easy to lose sight of the basics. In the land of CMS theming, it’s easy to choose the reactive path and theme what the CMS gives you. CSS should be as simple as possible, except when it truly can not.

I do not often see a lot of discussion online regarding effective approaches to providing spacing rules for component-based design strategy. This post simply outlines my own thought process of what worked well given the tight timeline our redesign was under (~month turnaround) and the tools available and right now and my experience using/extending WordPress. We have a long list of future phase improvements that I can’t wait to tackle.

Do you have component-based design strategies that have worked well for you? Please holler with your thoughts in the comments.