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