Imagine you work at a company that has gone to lengths to build, share and strengthen its brand. Wouldn’t it be great if your content editor could help your authors produce on-brand markup? Good thing TinyMCE can do just that.
TinyMCE is jam-packed full of features to allow your content authors to focus on writing content without having to worry about the intricacies of ensuring they follow the company’s visual style guide. Let’s take a look at 5 ways to help your authors get the best possible authoring experience with TinyMCE, while keeping your content on-brand.
1. Present your editor content in your published styles
Not all content authors are fluent in HTML, let alone CSS. They may be focused on their words and the way they appear, and not the behind-the-scenes workings of styling. One thing you can do to improve the overall content creation experience is to render the content in the editor the same way it will be rendered on the published page. That way, your authors will know exactly how it will appear once it’s published.
Custom CSS
In TinyMCE, you are able to set a custom CSS file for the editable area so that the appearance of the content in TinyMCE visually matches the expected outcome. This means that when an author selects a “Heading 1” style, the appearance of that heading in the editor matches the way it will appear in the finished product. This level of user-friendliness can help non-technical content authors develop more usable and reliable markup, even without knowing a single piece of HTML code.
Setting a custom CSS file is as simple as passing it as a configuration option:
tinymce.init({
/* ... */
content_css: "/path/to/styles.min.css",
});
If your styles rely on external fonts, such as a Google font, you can also include these in the content_css option:
tinymce.init({
/* ... */
content_css: [
"//fonts.googleapis.com/css?family=Montserrat:300",
"/path/to/styles.min.css",
],
});
Your custom CSS file is most likely going to be a subset of your website’s complete stylesheet – just include the styles that are actually needed by your authors to give them the visual cues they need to see.
Adjusting the default font family, size, and color is a really good place to start to help your authors understand the final appearance of their content.
Inline Editing
If you are using TinyMCE in a custom application, you could also create an inline editing mode where authors can edit the content in what appears to be the finished product. Let’s say it is a CMS – you could allow authors to browse the website, and actually edit a page of content on the page itself. This gives the author a 100% authentic view of how the content appears in place – and better yet, all of the tips in this article can still be implemented with inline editing too!
2. Optimize the toolbar and menus
TinyMCE has such great power under the hood. But we all know, with “great power comes great responsibility”. Take some time to be responsible towards your authors: restrain some of that power to help keep your authors focused.
If your users don’t need certain options, turn them off. Customize the editor interface to give your authors exactly what they need. This can be a combination of things, including:
By removing unnecessary options, you are reducing unnecessary distractions and providing your users with the best authoring experience.
You can even take this further by having different content authoring configurations for different field types. For example, an editor configured for creating an article could be fully-featured, but a smaller editor configured for a snippet of text might only have a few simple options. It is really important when developing your data entry interfaces that they are designed for your users to deliver an exceptional, productive, and streamlined user experience.
To get your head around the TinyMCE toolbar, check out the step-by-step demonstration of building your best toolbar.
3. Configure the editor to follow your style guide
One of the big focus areas of a visual style guide is around the appearance of typography – especially fonts, sizes, and colors. TinyMCE makes it easy to adhere to the visual requirements of your brand by limiting what authors have access to.
Fonts and Sizes
TinyMCE can be configured to be a fully-featured editor – a bit like your favorite word processing software, including full control over fonts, colors, and sizes.
When selecting some content, and changing its font or size, TinyMCE wraps the content in a span and uses inline styles. The issue with this is that it ties the style of the content directly to the content – but using CSS is meant to decouple content from presentation.
By removing the font_formats and fontsize_formats in your TinyMCE configuration for the toolbars and menus, we remove the bulk of where TinyMCE creates its inline CSS. This can be done by reviewing your TinyMCE init call to ensure these options are not in your toolbar or menu configurations.
More importantly, when we do this, we remove the ability for authors to change the font to Comic Sans MS or Papyrus (unless that is your corporate font). And yes, I’ve seen content authors do this. If your brand makes use of different font faces, have these configured for the appropriate elements (such as Heading 1, Heading 2, etc.) in your “content_css” file as part of your TinyMCE configuration.
In our CSS file, we need to ensure that we are creating enough styles to give our authors the ability to do what they need, and include styles for things such as:
- Block-level elements, like headings, following your brand style guide for font, size, appearance and padding/margins
- Inline elements, like highlighting words
- Default paragraph spacing and font specifications
- Spacing and styling of lists and list items
- Additional styling of elements such as links, strong, emphasis, pre, blockquote, images – all depending, of course, on your content needs
And don’t worry, by creating a content_css CSS file and implementing Style Formats, we’re still giving our authors the ability to change font size and format – just using our predefined styles and satisfying our need to separate content from presentation.
Style Formats
Once you have your custom CSS file set up in your config, you should also configure the style_formats option.
For a working demo, check out the Custom Formats example.
The “style_formats” configuration option is typically configured alongside the “formats” option – these can be confusing at first glance, but let’s break it down.
The “formats” option details some rules that get applied when certain actions within the editor are fired – for example, making a selection bold.
The “style_formats” option lists the different styles that you want to appear in the “styleselect” toolbar (or in the menu).
Let’s start with the “formats” option, and imagine we have a paragraph of text, marked up in HTML as follows:
<p>This is my paragraph of content.</p>When a selection of text is made bold, it will be an inline span element and have the class “bold” attached to it:
tinymce.init({
/* ... */
formats: {
bold: { inline: "span", classes: "bold" },
},
});
If we select the word “paragraph” and click the “B” toolbar button, the markup would be:
<p>This is my <span class="bold">paragraph</span> of content.</p>We may want more semantic control though, and actually want a “strong” element for bold text, so we could adjust our format to be:
tinymce.init({
/* ... */
formats: {
bold: { inline: "strong", classes: "bold" },
},
});
This would produce:
<p>This is my <strong class="bold">paragraph</strong> of content.</p>In this case, you may not need a class at all, as you could write your CSS selector based on the element name, but it illustrates how flexible the “formats” option can be
On to the “style_formats” option now. This option expects an array, and each item can either be a single style, or an object of styles (that will automatically create submenus for you). Whether you go for a single list or a nested list is up to you – it depends on the number of styles you are defining. The documentation shows the default “style_format” options as a nested array if you would like to see the syntax.
Let’s keep it simple and look at these two definitions:
tinymce.init({
/* ... */
style_formats: [
{ title: "Blue Text", inline: "span", classes: "blue" },
{ title: "Bold (Red)", selector: "strong", classes: "red" },
],
});
This would give us two options – Blue Text, and Bold (Red) – in our style menu.
But what is really handy about this is that we can define what styles can be applied to what content.
Our Blue Text is an inline element, and will create a span around our content with the class “blue”. Following on from above, let’s make the word “paragraph” be blue:
<p>This is my <span class="blue">paragraph</span> of content.</p>Really neat. Now if we tried to make the word “paragraph” be “Bold (Red)”, TinyMCE won’t let us – the rule is declaring that it must only be applied on a <strong> element.
If we undo our “blue” example, and go back to our bold “paragraph” and then select “Bold (Red)”, we end up with some clean markup:
<p>This is my <strong class="bold red">paragraph</strong> of content.</p>This is based on the “format” rule adding a “strong” element with the class “bold”, and the “style_format” rule applying the “red” class, but only to a “strong” element.
The “strong” example is a trivial one – another use case could be to allow authors to float an image to the left or right, but only image elements. Let’s update our style_formats to include two image-only styles:
tinymce.init({
/* ... */
style_formats: [
{ title: "Blue Text", inline: "span", classes: "blue" },
{ title: "Bold (Red)", selector: "strong", classes: "red" },
{ title: "Image Left", selector: "img", classes: "float-left" },
{ title: "Image Right", selector: "img", classes: "float-right" },
],
});
And let’s insert an image to our content:
<p><img src="images/logo.jpg" alt="Acme Logo" /><strong class="bold red">Hello, World!</strong></p>If you select the image, and apply the “Image Left” style, we would then get:
<p><img class="float-left" src="images/logo.jpg" alt="Acme Logo" /><strong class="bold red">Hello, World!</strong></p>If you try to float any other element, TinyMCE won’t allow it – this can only be selected if we have an “img” selected in the editor.
We can then use our custom CSS file to define what each of these styles means.
This is just a simple demonstration of how these two options can be used to give your authors strict access to your stylesheet but also governed by element type.
Colors
In a perfect world, we should keep our content separate from our presentation – and that means avoiding inline CSS. The TinyMCE color picker allows authors to select colors, but applies the color as inline CSS, including the hex RGB code.
Depending on your needs, there are a few options here:
- Disable the color picker, and use “style_formats” to define color changes in your style list (note, this is a great use-case for using the nested style definition for ease of use), or
- Live with inline styles, knowing that inline CSS will be generated
Which option you choose depends on your needs – but let’s assume that you are happy with inline CSS and would like to keep the TinyMCE color picker.
Using the color_cols and color_map options, you can completely override the color definitions in the TinyMCE color picker.
While inline CSS may not be ideal, this gives your authors the ability to select colors, but only from the list that you define.
If your brand style guide contains a deep shade of red, you can define this using the RGB hex code, and your authors don’t need to stress about the exact shade of red – they can just select it from a visual list. Even if you have authors who are color blind, the visual list also includes the name you give each color to help them select the right color based on name, rather than what they actually see.
The biggest downside of having inline CSS is that if one color changes, you would need to search and replace the markup of all content to update the color reference. This itself is the biggest argument for trying to use “style_formats” where possible. But if absolutely needed, it is good to know that you can at least control your color picker.
4. Produce clean, semantic and accessible content
Clean and predictable markup
Are you a Shift+Enter person? Or an Enter person? What about the content author next to you? Do they follow the same standard?
TinyMCE has a number of configuration options that can help you dictate the rules that TinyMCE should follow when generating its markup. Exploring these options gives all of your authors the ability to generate the same style HTML, regardless of their keyboard shortcuts. Take a look at the Content filtering options of TinyMCE’s configuration, specifically:
- element_format for the closing behavior of elements
- entity_encoding for adjusting how entities should be processed
- forced_root_block for Enter/Shift+Enter behavior
- invalid_elements for cleaning unwanted elements from your markup
- remove_trailing_brs for what TinyMCE should do at the end of your content
If you want to get really strict, you may also like to look at:
- valid_elements (and extended_valid_elements) to dictate exactly what attributes can belong on specific elements
- custom_elements if your backend system makes use of XML-based custom elements
Semantically-correct is always best for the variety of browsers out in the world (and to deliver your content with consistency), and TinyMCE is incredibly flexible with ensuring produced markup fits within your project’s coding style.
Premium Plugins
Tiny’s Premium Plugins give your authors an elevated and best-in-class authoring experience, with incredibly useful and streamlined features that can help optimize your editing workflow.
The PowerPaste plugin is such a timesaver if your authoring workflow includes copying content from other applications, such as Microsoft Word. One of the challenges of content authoring is that in order to have something appear a certain way, it requires hidden markup – and that markup may not be compatible or compliant with your finished product. PowerPaste gives you a helping hand by stripping all of the styles, leaving you with clean and reliable markup.
When combined with the styling provided by your custom CSS file, which should pick up the semantically-correct markup, your authors only need to apply any additional styles needed for specific highlights. This means that the end result is clean markup that references your stylesheet classes – and if you ever need to change the definition of a class, simply change your stylesheet, and your content will change its appearance – this is why we love separating content from presentation.
The Accessibility Checker is another useful plugin for your authors. While not exactly a “visual” brand tool, your brand may be committed to generating accessible content for all users – even those who rely on assistive devices. Writing accessible HTML can be intimidating for users to comprehend. Thankfully the Accessibility Checker can help your authors ensure their markup is accessible by stepping them through the issues detected, and helping them provide a fix to improve its accessibility.
5. Create features that help your authors
Create your own TinyMCE plugins
Creating your own TinyMCE plugins is incredibly easy – and can give your authors a helping hand with performing special tasks.
Maybe you need to give your authors some help with importing special markup or content from an existing system. Or maybe you have an internal document system that has its own link styles.
Using the TinyMCE UI component library, you can create your own TinyMCE plugins in JavaScript that can extend TinyMCE’s functionality to make it excel for your content authors.
To help get you started, find out more about how to:
- Create a TinyMCE 5 plugin
- Use the Autocompleter UI component
- Use iframes for embedded content (and cross-window communication)
And as always, the Tiny documentation provides a wealth of knowledge.
Create reusable templates
The Template plugin is an incredibly useful plugin to help your authors insert reusable templates of content for commonly-used tasks.
As an example, your authors may often need to include specifically-styled tables in their content. Given table styling can get confusing, rather than leave it up to each author to guess and figure it out, using the templates plugin, you can define a shell table, and allow the author to insert an empty and pre-styled template, including any necessary markup.
The best way to do this is to create an endpoint as part of your backend system that returns a JSON array of templates. This way, you can manage your templates in another part of your system, and have them dynamically selectable within your TinyMCE editor. You can see how this works in the Template plugin documentation.
Using templates for commonly-used HTML snippets can save your authors time and effort in trying to match markup each time they need to use it.
Conclusion
Configuring TinyMCE to keep your authors visually on-brand helps your company reach its brand goals, and with a bit of tinkering and configuration, you can get your TinyMCE editor instances to work for your authors, work for your brand, and all the while generating clean, consistent and on-brand markup.
