As someone who builds websites with WordPress and then hands them off to others, it’s easy at times to slip into thinking that the site administration is already taken care of. That’s why we use WordPress after all, and WordPress has a well-earned reputation as being easy to use [at least for a content management system (CMS)].
But there are also plenty of places where the WordPress admin isn’t as good as it could be. So when I build a site for someone else, my goal is to do so in a way that encourages making good decisions and discourages making bad ones.
One of the most basic and important features for a WordPress user is the text editor. In fact, I imagine it’s the most-used feature in the admin. The primary purpose of WordPress is to publish content, yet the WordPress text editor has too many buttons, gives prominence to the wrong ones, and, in doing so, encourages bad editing practices by users who don’t know better.
That’s why I built and recently released ((For the past few years, I’ve installed a version of this plugin on all client sites. I released the new public version to share a tool I’ve found essential to building good WordPress sites.)) MRW Web Design Simple TinyMCE. In this post, I want to explain the thinking behind the decisions I made for the plugin.
Text Formatting Principles
Let’s get to it then! I believe that the best possible text formatting and styling in a CMS is:
- Portable: Text formatting should be context-agnostic, working in multiple systems.
- Semantic: Text formatting should be meaningful to humans and computers.
- Accessible: Text formatting should not exclude formatted content from some people.
- Easy: Text formatting should be quick to learn and apply.
Each of these principles ((Remember all four principles with the fantastic acronym: P.S.E.A. The “P” is silent but still equally important. :P)) lead to decisions I made about what buttons the ideal text editor includes.
Portable
“Portability,” as a technical term, refers to how easy software, or in this case content, is to move from one place to another—either at the same time or in the future. There are many different contexts in which a post can appear when it’s published with WordPress:
- In an RSS feed reader like Feedly.
- In a “read it later” app like Pocket or Readability.
- In an email sent by a MailChimp RSS-to-email campaign or Jetpack Subscriptions.
- In a new theme, should your website design ever change.
- In a new content management system, should you migrate some or all of you content.
Take a look at these screenshots of a recent blog post that included an image, headings, and blockquote in multiple different contexts and notice how the meaning of the formatting stays while the specifics change. This is what portable content looks like:
(RSS and email readers may need to visit site to view gallery.)
Making content portable requires formatting it in a way that can be interpreted by multiple systems so that it always looks good. With a multitude of devices, screen sizes, and programs, we have less control than we used to over where content appears, so we must format text under the assumption it people will read it in places we haven’t anticipated.
What does this mean in practice? It means we must encourage the use of headings and blockquotes and lists appropriately and not rely on “inline” ((In this context, “inline” means that the styles are attached directly to the piece of text rather than universally applied to a certain format. It’s the difference between “This sentence should be 20px, bold, Arial, and orange” and “This sentence is a blockquote and all blockquotes are 20px, bold, Arial, and orange.”)) font colors or sizes that could be overridden or not look good outside of the specific site a post published on. In the plugin, this means removing the font color and underline buttons.
I also add the ability for developers to create custom styles such as “warning,” “notice,” or “disclaimer.” These styles apply an appropriate HTML element (like a heading or blockquote) if one exists and ensure that text is styled in a way that can be quickly redefined in future themes.
While not part of the “Simple TinyMCE” plugin, to make sure that web-appropriate styles are applied and extraneous styles are removed, I always install Paste as Plain Text to automatically strip “bad” styles from text and encourage people to use the WordPress text editor for all formatting.
Semantic
Why does using headings and blockquotes and lists make content portable? Because those types of formatting have strictly-defined and universally agreed upon meanings. That is to say, they are “semantic.” By formatting in this way, each new context can have different pre-assigned visual styles for each format that looks good in that specific setting. It’s more important that text be identifiable as a blockquote than a specific color or size.
To encourage semantic formatting, I remove the font color option (again), Heading 1 (since the page title is the only H1), and move the headings to the top row where they are available by default. I also move the blockquote alongside the heading options since they are similar in application. And those, custom styles like “warning” that can be added by developers? Those are also semantic.
All of these decisions focus the editor on formatting text for what it is (e.g. “blockquote”) not how it looks (e.g. big, bold, and indented).
Accessible
An accessible website requires cooperation from the designer, developer, and content editors as all three determine whether a site is fully accessible. A designer must create an accessible color palette with a large-enough font size. A developer must ensure the WordPress theme and other code is usable by screen readers and keyboard navigators. And content editors must enter appropriate alternative text and correctly format text.
By default, many of the WordPress text editor buttons can negatively impact accessibility and usability:
- Underline should only be applied to links and that should be done automatically.
- Allowing editors to select text color enabled the creation of low-contrast text.
- Centered, right-aligned, and full-justified text are all much less readable and too open to abuse.
And because the default WordPress editor hides the Headings drop down in the second row, surely thousands of site editors miss it. Again, the new editor has the drop down with headings as the first item since headings are one of the keys to creating accessible content.
Easy
An editor with lots of buttons is powerful. That includes the power to do bad things. ((That does not include The Power of Love.)) A smaller editor is easy.
After removing many buttons and options, it’s possible to condense all formatting buttons to a single row with the most important options first. In addition, I moved the blockquote to the Formats drop down since blockquote is a format more like a heading than a style like bold or italic. Headings 5 and 6 are removed since pages rarely get that deep and, at least anecdotally, it seems that having more headings encourages people to using headings incorrectly.
I also chose to remove the “More Tag” button which I find most people struggle to understand and properly use. When it’s needed, I make sure it’s easy to add back.
The Results
The original editor includes buttons that are bad for portability, semantics, accessibility, and ease-of-use.

The modified editor puts important buttons first and moves all remaining buttons to a permanently-visible first row:
I believe that this editor is a significantly better default for almost all WordPress users. While I can write HTML just fine and have experience using markdown and other formatting languages, this editor is how I prefer to write and there isn’t anything I find missing.
As it is said, I have “dogfooded” this editor, and it turns out it’s one of those tasty types of dog food that tastes good to humans…err…Let’s just say it’s really good for writing for the web.
Try out MRW Web Design Simple TinyMCE today.
Let me know in the comments what buttons/formats, if any, you think are missing or should be removed.
This simple TinyMCE plugin looks great. I think that I may need to start using it on all my installs. No more underlined text!
AMEN TO THAT! Except links of course :)
Love this.
Curious about this statement:
“Centered, right-aligned, and full-justified text are all much less readable and too open to abuse.”
While I certainly agree with the “too open to abuse” possibility, I’m not sure how those text alignments alone make text less readable. Is it just visual flow and and a reader’s expectation of where something “should be” that makes it potentially more difficult to read? I’d miss the center alignment mostly in your configuration.
I’d also love to see a special format for <code> – I don’t always want to wrap it in a tag and it’s a pain to switch over to the text editor and manually insert that multiple times in a post.
All in all, can’t wait to give this a try on my site.
Cheers,
Carrie
Thanks for your long and thoughful comment, @cdils!
I actually added the code element in v1.1.0 for what I assume is the same reason you want it. You’ll have to test it out and let me know what you think! I’d also love to add ins and del (rather than strike) to the available “Other Formats” but those apparently don’t “just work” when added to the editor. Hopefully I’ll get that sorted out some day.
As for your question about readability, there’s a whole bunch of interrelated issues with centered, right, and full-justified text that cause minor usability problems. I’m going to go all out in my answer to you so I can reference it again if needed. It’s a great question and I have lots of thoughts. I’d love to hear your reaction as to whether you find these reasons compelling.
Full justification has two issues:
1. The negative effects of full-justification are probably less of an issue with short line-lengths (http://www.textproof.com/chronicle/Readability__Justified_vs__Ragged.html, though it looks worse then: http://www.fonts.com/content/learning/fontology/level-2/making-type-choices/justified-vs-rag-right) but on the web, we don’t run into much, short of reading on phones or with CSS columns. However, those last two exceptions wouldn’t WordPress editor territory (or would be applied with a custom class, not the full justify button).
2. Browser implementation is still pretty nasty still. It’s common to see really awkward gaps and bizarre hyphenation decisions. Here’s a great WordPress example https://twitter.com/mrwweb/status/530143516765061122.
Centered and right-aligned text both have ragged left edged which has been shown to impede reading speed and comprehension. (Here’s the best overview of research I can find: https://kaiweber.wordpress.com/2010/05/31/ragged-right-or-justified-alignment/.) The straight-left / ragged-right combination seems to be best for left-to-right language readers because it helps the eye find the start of the next line when it leaves the right end of the last one. (Another source: http://uxmovement.com/content/why-you-should-never-center-align-paragraph-text)
I don’t have research on this, but I also have seen a lot of times in person where centering or right-aligning headings (where the ragged edge issue is moot…at least one hopes :P) makes them much harder to scan and people miss them completely. And again, if we want to center headings, let’s do that with the heading CSS styles or a custom .centered-heading class that can’t be applied to paragraphs (which is the main reason to remove them). This Western Michigan University article on readability is actually a great example of how wonderful easily-scannable headings are! (http://wmich.edu/writing/readability)
Finally, it must be noted that right alignment is presumably great for Arabic and other right-to-left languages for all the reasons that left-alignment is great for English! I honestly haven’t thought about whether multi-language sites would have problems with this editor. I imagine that again it would be a CSS issue but don’t have the experience to know that for sure.
Ed Note: This comment was adapted into the post “No Justification: Don’t Use Right, Center, and Full Justification on the Web”.
Eh, that was a “code” tag I mentioned in the previous comment and it was… applied as markup. Derp.
Thanks for the comments! I went and edited your comment to get that code element in. Is that right? (I’ll respond to your comment above!)
Hi Mark,
Wow – thank you for the resourceful reply! What you say about justification makes sense, I’d just not thought of that before. BTW – you could take your last reply and make a whole new post just out of that topic. :)
Cheers,
carrie
Glad it was useful! I’ll probably do just that now that you mention it :)
What about tables? I’m not sure if TinyMCE has those table formatting buttons on wordpress, but I think some of my clients would howl if they were gone.
Also, (and again this may not be an issue for WordPress,) but on Plone I have not been able to figure out what the “Remove Formatting” button is supposed to actually do.
Thanks for your questions, @fulv!
To the best my knowledge, WordPress has never shipped with the TinyMCE table buttons and I’m thankful for it! For the few sites I’ve enabled it on, it seems to inevitably be used inappropriately for layout. I’ve moved toward using TablePress which allows for reuse of tables and has a featureset that encourages using tables the way they’re intended: for tabular data.
As for the “remove formatting” button, I had a general feel for what it removed but thought this would be a good moment to put together a test. You can see the results in this gist: https://gist.github.com/mrwweb/9c39da7170a333831c15
It’s a bit of a hodge podge really:
– h2, div, del, a, ul, and ol stay
– strong, em, code, span, and all inline style attributes are stripped
I’m hardest pressed to explain how del survives.
If someone always uses Paste as Plain Text, then the remove formatting buttons loses its purpose, but if you do paste from another site or, god forbid, Word, then it’s useful to strip out the junk inline style rules.
Increase/decrease indent should NOT work for anything but lists (where it’s semantic, i.e. nested lists).
That’s a great point that I didn’t make in the article! Thanks. I wish I could remove those buttons, but since TAB doesn’t indent lists in the editor, I have to leave it. Maybe someday!