Formatting WordPress Post Content: The Good, The Bad, and The Ugly

good bad ugly | formatting wordpress post content

Today we’re talking about one of the more awkward pieces of WordPress: How to format your post content so that it looks exactly the way you want. This can get quite tricky as your requirements get more specific, but it is possible, and there are better and worse ways to go about it.

WYSINWYG (“What You See is Not What You Get,” or: Acronyms You Make by Mashing a Keyboard With Your Fist)

WordPress currently has no truly WYSIWYG solution.

It turns out there are a lot of things that WordPress’s default post editor (both the Visual and Text editors) can’t do. For example:

  • Line up images horizontally
  • Put a section of the post content against a different colored background
  • Create specific, repeated text styling rules, like a series of sentences that should appear in a nonstandard font
  • Manually specify design attributes like box-shadows, border-radii, and opacity values, for in-post-content elements like divs, blockquotes, and images.
You can’t do this in the WordPress text editor
without manually coding HTML/CSS styling rules

As another example, “pullquotes” (the large called-out text above, “WordPress currently has…”) also require special formatting not available in the “buttons” the default text editors give you.

So the truth—slightly awkward relative to our fantasy of a perfect CMS—is that WordPress currently has no truly what-you-see-is-what-you-get (WYSIWYG) solution. Leaving aside “responsive page builder” plugins like Visual Composer—which I’d endorse lukewarmly, if you like that sort of thing—WordPress offers only rather basic styling options for your post contents.

Instead, you make any of the above changes in WordPress exactly how you do it anywhere else: with HTML markup and CSS styling rules. So our job is to crack open our HTML and CSS knowledge and make stuff look the way we want. Let’s look at the good, bad, and ugly of HTML/CSS inside WordPress post contents.

The Good: What to Do

Flexible, Repeatable, Class-Based Declarations

(Nothing to see here, I’m a pullquote example.)

Let’s again take the pull quotes we use across the site. They come out looking like this:

Pretty cool, right? Eye-catching and they break up the text. Here’s how we make them:

<blockquote class="pullquote alignright">(Nothing to see here, I'm a pullquote example.)</blockquote>

See how simple the HTML is? You’ll see the gunked-up alternative in “The Bad,” below. But the important thing is that all the heavy lifting is done in the following CSS styles:

blockquote {
font-size: 0.75rem;
line-height: 1rem;
padding: 0.875rem 0;
margin-bottom: 0.875rem;
border-top: 1px #fcb51e solid;
border-bottom: 1px #fcb51e solid;
}

.pullquote {
width: 250px;
max-width: 50%;
margin-top: 0;
}

.pullquote.alignright {
margin-right: 0;
}

.alignright {
float: right;
}

That may seem like a lot, but only the pullquote class styles are really new stuff we had to write specifically to have pullquotes. All the other styles deal with how to style blockquotes and things (like images) that are supposed to align right or left. We’ve just hooked into those existing rules and extended them a bit.

Definining your styles in centralized CSS rules saves tremendous headaches.

Moreover, the code above only needs to be written once, and changed once. If I wanted to get rid of the pullquotes’ borders, I simply change the CSS rules and the borders disappear in all of the hundreds of pullquotes across the site, all at once. Definining your styles in centralized CSS rules, rather than inline every single time, saves tremendous headaches.

Theme-Agnostic Styling

If you got rid of your current theme, nothing of the old theme should remain in your post content styling.

Here’s a simple rule: If you got rid of your current theme, nothing of the old theme should remain in your post content styling.

In other words, you should be able to change your theme right out from under your site, browse the post contents, and not be bombarded with suddenly ugly reminders of how the site used to look. Doing this correctly means you avoid the problem of tight coupling: making two things (post content and your theme) depend on each other in ways they shouldn’t.

The biggest step you can take in this direction is simply to use CSS-based rather than inline styles, as discussed above (and below). However, there are other, more subtle ways to tightly couple yourself, so you’ll want to look out for those as well. For example, let’s say you love how your theme’s <h4>s are styled. They’re a pretty blue and very eye-catching, and you use them all the time when you simply want to get someone’s attention (not necessarily when you need a more “deeply nested” heading than an <h3>).

In this example, you’re not using any inline styles, but you’re still incorrectly depending on your current theme: the <h4>s just happen to look the way you expect in the current theme. If your theme changes and <h4>s are now rather gray and dull, you’ll have to go back everywhere and do cleanup work.

Instead, why not create a class, called-out, that you style exactly the way you want? When you switch themes, you can make .called-out look the way you want in the new stylesheet and you won’t lose a thing—nor will you have to worry about overwriting or otherwise wrestling with the new theme’s default <h4> styles.

The Bad: What Not to Do

Repeated Inline Styles.

Don’t do this:

<h2 style="font-size; 12px; font-family: Tahoma, Arial, Helvetica, sans-serif; color: #003300; font-weight: bold;">Heading</h2>
<h2 style="font-size; 12px; font-family: Tahoma, Arial, Helvetica, sans-serif; color: #003300; font-weight: bold;">Another heading that looks just like the previous one</h2>
<h2 style="font-size; 12px; font-family: Tahoma, Arial, Helvetica, sans-serif; color: #003300; font-weight: bold;">Look at that! A third heading that looks just like the previous two</h2>

One of the most important tenets of any kind of programming is: Don’t Repeat Yourself (DRY).

This code is really bad because it violates one of the most important tenets of any kind of programming: Don’t Repeat Yourself (DRY). Because so much is repeated in the styling rules above, you now have the following problems:

  • If you want to change anything, you have to change it multiple times.
  • Your code is much bulkier and harder to read than it should be.

If the extremely un-DRY markup above looks familiar, it’s because it’s the kind of thing that most WYSIWYG editors output. The reason—which is also the fatal flaw of WYSIWYG editors in general—is that they must obey rather than interpret. They can’t read your mind: they don’t know when you’re trying to say, “I want a third small blue thing, just like those other two except over here”; rather, they can only obey when you say, “I want this thing to be small and blue, and I want this other thing to be small and blue, and I also want this third thing to be small and blue.”

But that’s because WYSIWYG editors are mindless machines. Don’t be a mindless machine: write CSS class-based rules that capture repeated styles, as described above.

Only leave inline styles in place under very rare circumstances. If you write 200 blog posts and then switch your WordPress theme—as we did a few months ago—you’ll be really glad that every single post doesn’t have its very own miniature inline stylesheet for you to correct by hand.

Deprecated HTML Elements.

There’s no need for this:

<small><center>Hello from the year 1998</center></small>

Use CSS styles like text-align: center and font-size: .8em instead.

The Ugly: What to Watch Out For

Dealing with Paragraphs

If you’ve got multiple elements that should line up next to each other, write them without linebreaks.

One major difference between TinyMCE’s Text window and a real HTML document is that the TinyMCE window automatically adds paragraphs. This means that spacing can get off unexpectedly, since elements are suddenly wrapped in <p> tags you didn’t expect.

There’s an also unrelated issue with the display: inline-block CSS style: if you allow linebreaks between two inline-block elements, your browser will put a single space between them—which is just enough to prevent, say, two 50% wide elements from fitting side-by-side. (For details, see this post, section titled “The Enormous Drawback.”)

So those are the general challenges. You actually don’t need to understand them that well, if you keep the following superstition in mind:

If you’ve got multiple elements that should line up next to each other, write them without linebreaks, as follows:

<div class="half-width">Content</div><div class="half-width">Content</div>

See? No linebreaks. Same with shortcodes:

[column][/column][column][/column]

So do not do this:

<div class="half-width">Content</div>

<div class="half-width">Content</div>

That works worse in WordPress-land than it does in straight HTML/CSS-land, and even then it can get you in trouble if you’re using display: inline-block.

WordPress’s Auto-Refactoring

WordPress will delete some things when it gets the chance, making heavily marked-up posts feel very fragile and vulnerable.

WordPress will delete some things when it gets the chance. The most noteworthy are:

  1. <br> tags
  2. Empty <p> tags

WordPress has its justifications for doing this, but <br> tags and empty <p> tags certainly have their place as well. (<br> tags are semantic in ways that paragraphs filled with a single &nbsp; aren’t. And what about <p class="jquery-target"></p> which you’re trying to fill with jQuery contents on page load?)

Much of this cleanup happens when you switch from WordPress’s “Text” to “Visual” window. WordPress is just trying to be helpful, but a lot of the time you can click over to the Visual window—and lose your elaborate Text changes. This makes heavily marked-up posts feel very fragile and vulnerable, particularly if there’s another ghost in the machine (say, a client) who likes to look at things in Visual mode.

There are plugins to stop this behavior; I’ve never tried them myself, since I prefer Text mode anyway and other people rarely edit my posts.

Get Formatting!

I hope this article has given you some tools for intelligently formatting your WordPress post content. If you’ve got confusions or questions, I’d like to (belatedly) suggest two pieces of related reading: this article on the WordPress text editor itself, and this one on using the Text editor to format images.

Thanks for reading!

Image credit: Vectorportal


6 Comments
Most Voted
Newest Oldest
Inline Feedbacks
View all comments
Pav
November 18, 2015 1:29 pm

Thank you. WordPress visual keeps lying to me. These chain of wordpress formatting posts are inspiring me to learn html and css or just to buy a better theme.

Mark Underwood
June 25, 2015 6:25 pm

Worth the read for the pullquote example. I’ll give it a try.

Tweet Parade (no.08 Feb 2015) - Best Articles of Last Week | gonzoblog
February 21, 2015 9:03 am

[…] Formatting WordPress Post Content: The Good, The Bad, and The Ugly – So our job is to crack open our HTML and CSS knowledge and make stuff look the way we want. Let’s look at the good, bad, and ugly of HTML/CSS inside WordPress post contents. […]

Jason Robie
February 18, 2015 12:02 pm

great tips. I have to admit I read the whole thing solely hoping for a solution to the dreaded “wordpress keeps removing my line breaks” problem. Is there a “best practice” solution to this???

fredclaymeyer
February 18, 2015 10:04 pm
Reply to  Jason Robie

Hey Jason,

You may want to try TinyMCE Advanced? I’ve never tried it myself, but do see it mentioned in this .org support thread.

Let me know how it goes! 🙂

Jason Robie
February 19, 2015 10:23 am
Reply to  fredclaymeyer

agreed. those plugins are great. I’m more looking for an “organic” solution. I’ve found that () works really well and consistently. Hoping someday WP addresses this issue and stops stripping out the standard “br” tags we all love. 🙂 Thanks for the tip. Have a great one!