A Review of ContentTools – a Rich Content Editor

I’ve written multiple articles for the Telerik Developer Network and sometimes Brian, the editor of this site, will offer up some ideas. Recently he floated a few ideas my way, one of which was a rich text editor (RTE) tool he’d found interesting. My immediate response was something along the lines of…


I’ve been in web dev business for over twenty years, and in that time I’ve gained a healthy fear for RTEs. They typically produce code that looks like a drunk monkey sat in front a keyboard using Microsoft Front Page.

Even when they produced good code, it wasn’t long before the client tried to do something not supported by the RTE and asked you why it didn’t work. In my years of experience working on CMS platforms with an RTE I’ve only found one that acted decently, and they were bought out by Macromedia years ago and the product was killed off.

As I said – I wasn’t interested. Nope, wasn’t going to even give this idea a chance. But…it had been years since I really looked at a RTE. And this product was both free and open source. In the end, I thought I’d give it a fair shake.

ContentTools is a rich content editor created by Anthony Blackshaw. As I said above, it is entirely free and available up on GitHub. Let’s look at what makes ConentTools differnet and why it might be worth a look if you are in need of a RTE.


Unlike a traditional RTE that plops a toolbar of Microsoft Word-like controls over a text box, ContentTools is an “in context” editor. That means your user edits the live page itself and sees their edits in the context of the rest of the site.

Here is an example from their demo:


Obviously a screen shot doesn’t really do it justice, but you can see where I’ve modified the text as well as how some of the controls work. So, sure, it’s pretty, but how do you make use of it?

The getting started guide does a good job of explaining things. Essentially it boils down to downloading the assets for the tool, including the JavaScript library into your page, and then launching the editor. Obviously, this is something you would only enable for users who are authenticated and have permissions to edit the content on the page.

Creating the Markup

For testing purposes, I decided to start off with the Jumbotron Bootstrap demo since it offers some layout and initial text. As the getting started guide instructed, I added the CSS and JavaScript file for the tool to my page. Next, I needed to identify the parts that would be editable.

editable regions

You can download the sample source as a zip file to test it locally.

In the screen shot above, the areas that I’ve boxed will be editable. The third box on the bottom is not editable purely just demonstrate how not everything needs to have the ability to be modified by the client.

To mark up these sections, I added two attributes to each block:

  • data-editable
  • data-name

The data-editable marks the area as editable. Meanwhile, data-name lets you provide a name for the content. The name becomes important when you are saving the changes a user makes.

A crucial thing to note here is that the data attributes must be placed on an item that wraps the content you want to edit. That’s something I messed up myself while testing. For example, to make the header editable (as you see in the screen shot above) I wrapped the H1 block in a section tag and placed the attributes there. (Big thanks to Anthony for helping me with this point.)

Here is an example from the top portion of the file showing the editable header and main paragraph:

<article data-editable data-name="mainHeader"><h1>Hello, world!</h1></article>
<div data-editable data-name="mainPara">
<p data-editable data-name="mainPara">This is a template for a simple marketing or informational website. It includes a large callout called a jumbotron and three supporting pieces of content. Use it as a starting point to create something more unique.</p>

Adding the JavaScript

Next I made a new JavaScript file and included the code from the Getting Started guide:

window.addEventListener('load', function() {
    var editor;

    editor = ContentTools.EditorApp.get();
    editor.init('*[data-editable]', 'data-name');

Remember – this code is not something you would load by default. Instead, it would only be loaded for authenticated users who have permission to edit the content.

Right away you can see a difference on the page:

Editing enabled!

Clicking the pencil icon opens up the editor toolbar:

Toolbar enabled!

You’ll notice that the toolbar is over some text, but you can grab and move it to a better position. Another cool feature is that you can hold the shift key to highlight editable regions:

Editibable regions

What isn’t visible from the screen shot is that those boxes are blinking, which makes them stand out even more.

Saving content changes will require back end code of course. The JavaScript portion though is rather simple. You can listen for a save event on the editor which will pass all the regions and the text each includes. The getting started guide has a full example you can literally just copy/paste – you’ll still need to build the back end support to take in those changes and persist them of course.

Configure Styles

One more cool aspect of ContentTools is the ability to configure styles for your content. Assuming your site has specific styles for paragraphs, you can actually define them so that the editor is aware of them too.

For instance, Bootstrap has many predefined classes to make it easier to style text. If I tell the editor about them, I can use them while editing. Below I’ve told the editor about some of the text styles Bootstrap supports:

    new ContentTools.Style('Muted', 'text-muted', ['p']),
    new ContentTools.Style('Primary', 'text-primary', ['p']),
    new ContentTools.Style('Success', 'text-success', ['p'])

In each case, I pass a “nice name,” the name of the CSS class, and the tags that it applies to. Now when a user selects a paragraph in the browser, and then select the P tag in the bottom toolbar, this pops up:

Style editor

As you can see, the “nice names” I supplied are used, which is more friendly for the non-technical user. Simply click a style to apply it.

Modified paragraph


All in all, I’m pretty impressed with ContentTools. Obviously it will take time to integrate it into a CMS, but the front end work is straightforward and the general ease of use seem to be really well done. I also had great success working with Anthony, the tool’s creator, as I played around. In the end, I may have to – cautiously – adjust my stance on rich text editors!


  • Loved the article thank you Raymond.

    I just wanted to post a link to a screencast of the editor integrated into a full CMS so that anyone interested in adding ContentTools to theirs can get a feel for how it might fit into their workflow. I’m also hoping to shortly release some more docs covering the topic of integrating an in-context editor into a CMS UI.

    The screencast can be found here: https://www.youtube.com/watch?v=Vh3Fd91pVqQ it’s by another developer and friend Guillaume Piot and it shows a Django based open-source CMS he’s working on.

  • would love to see this in some IBM products!

    • This would work well with a Node.js back end which you could host up on Bluemix. I could show that, but not sure what folks would gain out of it outside of seeing it just plain work. 😉

  • It looks good, however I’m not a fan of Coffeescript so it is a non-starter for me.

    • I’m not either, but why does it matter *how* he built it? If the end result is good, and you don’t need to use Coffeescript to use it, I don’t see what the issue is here.

      • I tend to have to bend/tweak things to meet my specific needs and having to grok Coffeescript first is not something I want to do. I also tend to spend time in the debugger when things go awry, so again there are barriers here.

        I’ve got fairly complex web app I’m developing name Clibu http://www.clibu.com which has a RTE as a core component and I’m always interested to follow developments in this area.

        Right now I’m in the process of updating an old version of wysihtml5 into a forked and much better version of it by Voog. You may be interested in that: http://wysihtml.com/ No connection other than a happy user.