At this point, there are a number of great content management-related features that are built directly into WordPress that are easy for theme developers to employ.

Some of these features include:

  • Enabling post formats
  • Automatic feed links
  • Setting the default content width
  • Opting to enable (or disable) featured images
  • …and so on.

And many of these features are widely used by a variety of different themes. Obviously not every theme uses all of the above functions but many use some of them.

But there’s one native feature that, for one reason or another, doesn’t seem to have taken off as much as other features:  WordPress editor styles.

This is a bit odd to me, because I think it’s one of the features that can greatly enhance the experience with a theme, and I think it can contribute to create greater differentiation in premium-grade products.

WordPress Editor Styles

First, the WordPress editor styles are  nothing more than a stylesheet applied to the TInyMCE editor within the dashboard of WordPress.

It’s really easy to enable the feature: add_editor_style( ‘editor-style.css’ );. Done and done (well, with the exception of actually writing the stylesheet), but you get how simple it is.

WordPress Editor Styles

But, as I said, this particular feature is one that I don’t often see discussed let alone implemented in themes as frequently as I would expect (or at least as I would like to see).

1. Narrowing The Gap

One complaint that people in the WordPress development space often hear is that the drafting area – that is, the TinyMCE editor – although powerful, doesn’t always reflect what the author is going to see on the front end of the site.

This creates the experience of draft , save, preview, draft, save, preview, and so on.


But it doesn’t have to be that way: Implementing an editor stylesheet can help close the gap of what the user expects to see on the front end by actually styling the content as it will appear in the main content column.

2. Gets Us Closer To WYSIWYG

Over the past few years – and perhaps the last decade or two – we’ve made the idea of WYSIWYG synonymous with bold, italic, underline, anchors, and images.

But come on: those are features of HTML, they do not constitute WYSIWYG. It gives an idea as to how the content will function within the browser – not how it will appear.

WordPress Editor Style WYSIWYG

Thus, how is the editor, within the context of a theme, even considered to be “what you see is what you get” when that clearly isn’t the case?

Again, introducing an editor stylesheet can actually address this issue by truly giving users a WYSIWYG editor. And speaking from experience, this goes a long way in saving time on toggling back and forth between drafting and preview.

3. It’s Native (Why Not Embrace It?)

Just as we have post thumbnails, content image sizes, automatic feed links, post formats, and so on, why not take advantage of the editor style functionality?

It’s built into the core API, it’s really just as easy as enabled the feature by calling a function, and – to be completely honest – providing styles for it isn’t that difficult especially if you’ve already styled the front end.

After all, if the editor is going to be responsible for providing the content on the front end, then much – if not all – of the CSS is already written.

4. Premium Themes

For whatever it’s worth, this is something that I believe that premium themes should include out of the box – it’s a non-negotiable. If someone is paying for a premium-grade product, then there are certain features that should be standard for each of those features.

Although, and as I’ve mentioned, I think it enhances the experience of the theme, the hard truth is that there are a lot of premium themes that offer very little compared to what some really nice free themes offer (other than a price tag), and it shouldn’t be that way.

Instead, premium themes should be expected to include a certain level of functionality that helps to differentiate them from the freely available themes.

This doesn’t mean free themes can’t take advantage of the features, but that premium themes should be expected to do so.

Why This Matters

As it relates to free versus premium themes, premium themes are supposed to be products that are in a class all of their own. I know – most of the cost that goes into premium themes are usually spent on support, but even free themes (and plugins) for that matter offer support and they do so for free.

Is it that unreasonable to expect a higher grade of quality and features from our paid products?

Or, perhaps a better way to ask it, is that if we’re trying to create a top-shelf brand of themes, then why would we settle for anything less than what would help us achieve that?


Join the conversation! 13 Comments

  1. It’s definitely something that enhances the experience of a theme, versus one that doesn’t include editor styles. But due to the ‘cascading’ part of CSS, it can sometimes be hard to filter down just the essential rules to include. You don’t want to just copy your full site stylesheet, but it can be an adventure pulling out just the rules that are needed for the editor.

    And if your theme is actively maintained, you now have a separate set of rules to maintain. Unless you are able to distill and reuse the rules intelligently. I think that an article on strategies for doing that might be pretty useful.

    • I’d disagree that editor stylesheets need to be as extensive as you make them out to be, Dougal.

      The editor, by default, uses a serif font with little allowance for font-size changes between paragraph and headers. This is a huge problem, especially for me, as I tend to favor sans-serif in my projects.

      At the very least, you need to see the basic typography, so line height, headers, fonts, and maybe even the base text color. Throw in the blockquote, pull-left quotes if you’re using them, and maybe image floats if they’re not translating, and your editor-style is maybe 100-150 total lines of CSS. For good measure, the basic link styling would be a plus (although it is kind of nice using the default to find links in the editor).

      To me, at least, the front-end post view formatting shouldn’t be that complicated. Most of my stylesheet changes are targeting the rest of the layout – widgets, footer, etc. So the overall cascade is at a very high level. I don’t think that the editor needs to be as specific – it’s about closing the gap in display between the two, not replicating it with all the nuances of the theme.

    • Great article! I agree with Dougal, I definitely would like to see an article on implementing strategies for this. I feel if more people realized it wasn’t as difficult to do they would do it.

      Some ideas:
      * Use a CSS Processor (I use SCSS for my clients, but LESS is also popular). This would let you use a single source file for both front and backend.
      * @import a separate “both-backend-frontend” stylesheet would be an option too if you don’t use a CSS processor. I know it’s not ideal, but it would certainly make maintaining a lot easier
      * Using distraction-free editing

  2. I think that commercial themes should definitely support editor styles. If someone is releasing a theme for free, I completely understand if they don’t want to take the time to implement editor styles. However, if I am purchasing a theme from someone, it is because I don’t want to take the time to build the theme myself. If I have to go back and implement the most basic functionality (editor styles) in my own time, it really defeats the purpose of paying someone else to do the work.

    • However, if I am purchasing a theme from someone, it is because I don’t want to take the time to build the theme myself. If I have to go back and implement the most basic functionality (editor styles) in my own time, it really defeats the purpose of paying someone else to do the work.

      Agree completely.

  3. Completely agree with Tom, that they should be non-negotiable in premium themes. Editor styles are an incredibly underutilized feature.

    And I love RJs comment about what should be included. A few simple styles can go a long way, especially with the less tech savvy audience… which is probably a majority of who’s buying premium themes.

    • A few simple styles can go a long way, especially with the less tech savvy audience… which is probably a majority of who’s buying premium themes.

      Exactly — people are generally trying to manage their content, and anything that we – as the theme developers – can do in order to improve this should, y’know, be done to help them manage said content :).

  4. Nice? Sure. Necessary? No, especially with WP’s eventual front-end editing, assuming that’ll bridge the gap automatically for themers.

    • When front end editing is part of core, then I can see a viable argument, but based on the way WordPress usually evolves, that’s a long way off.

      First, the front end editor would be introduced (and I’m not even sure that will be in core anytime soon), but the backend editor will continue to persist for backward compatibility reasons. If the backend editor persists, then the need for editor styles still persists.

      Secondly, if we let the user edit on the front end, they are still going to have to use the backend for some management – how much is yet to know – but if it doesn’t solve the problem of having the author toggle back and forth between areas of the admin.

      Don’t get me wrong, I think front end editing would (or will) be nice, but that won’t alleviate the WYSIWYG problem during its first iteration unless it’s extremely well thought out, executed, and adopted. And I don’t think that will happen – that’s based on how people react to something like a color scheme change to the dashboard :).

      Anyway, though I know it can be done (and likely will be), I don’t see it being something that addresses some of the more complex problems associated with it (such as categories, tags, featured images, post formats, etc.). There’s a lot of work to be done to bring front end editing to a level maturity that matches the backend.

  5. With how easy it is to implement, I’m appalled thats its not widely practiced.

  6. Great write-up! I just wrote a little tutorial on adding editor styles and someone pointed me to this article. I agree completely, theme authors really are not thinking of end users when they neglect this native feature of WordPress.

Leave a Reply