Adding styles to the WYSIWYG editor style drop down

I would like the styles drop down on the WYSIWYG editor to be customizable. right now there are only a few options. These are the canned options. I was told I can customize the canned choices but there are only 10 or so choices. I have to keep the same names as well. I would like an option to customize and add as many as I like. I cannot expect my users to use just the ones on the list. That blows my style guide.

I think this is a great idea. Especially when importing existing site designs into CM1, it would be great to be able to manually specify the classes I already have styled in my CSS file for certain blocks of text, rather than switching them over to the canned options here.

I know this question was relatively recent, but has this been added to the WYSIWYG?

If not, are there any other ways that a user can add customized styles via the WYSIWYG interface (not code view)?

If not, are there plans to do so in the near future?


I am not aware of this particular enhancement being locked into our road map at the moment. As it is, most customers have been able to successfully add their own custom styling by taking advantage of the unique class names that are already tied to the options in the RTEs select box, and simply punching one of those root classes into an existing rule set in their style sheet.

For reference, my first reply in this topic outlines the exact class names that the items in the select box are tied to:

Thanks–we’ve already started editing these styles.

This may have been answered already, but I was curious if the names of these styles could be edited. Instead of “Body Text 1,” could we title this something else?

Also: I realize this is somewhat independent of Percussion, but is there a way to see style changes while in the WYSIWYG? For example, we have a style that’ll change the text color to red, but this only shows up after a user clicks Save.

If this is not possible, it would appear that what you see is not quite what you get and, therefore, the name of the editor should be: WYSINQWYG. Totally kidding.



I think being able to change the names of these styles as they appear in the drop down box is really what’s at the heart of this Idea topic, and I do think that that would be helpful in order to supply contributors with a more intuitive set of options. That said, no this is not possible at this time – if you haven’t already done so, please “+1” this Idea to vote it up.

As for your other question, WYSINQWYG might have to be the new acronym here. Saving the content and viewing it in the main editor is the only way I know of to view the results of adding classes to content in either the Source View or through drop down class select box.

I have to agree with Oliver Wood. Not to go on an off-topic rant, but here’s my two cents on the editor topic as a whole:

CM1 is simple enough to use, but it’s the WYSIWYG that’s lacking. It doesn’t show changes dynamically like it should, and it changes code constantly. For example, coding simple br tags manually quickly turns into a mess. I realize it’s auto formatting for the sake of HTML standards, but there shouldn’t be a problem with placing a br just about anywhere. Using an HTML widget in lieu of this to get the job done is a solution for developers like us, but certainly not for your average user.

And if the purpose of CM1 is to provide both developers and users with an intuitive interface, but ultimately has an unfriendly editor–that’s a problem.

We are looking at enhancements to the WYSIWYG editing process for 2013. Having custom styles is definitely part of that scope as is the concept of true inline editing. Either enhancing or replacing the TinyMCE editor is being evaluated. As we nail down a firmer timeline we will keep this thread updated.

As a recommendation, I would would advise against modifying the tinymce config properties. Supportability, stability and upgrade issues may result. As Dan mentioned in a previous post, we are actively evaluating enhancements or a replacement to the editor in 2013

Thanks for the info!

Thanks for letting us know! We were uneasy about doing so.

Agree with Matthew. The users to whom I wish to push this out will know very little about formatting. CM1 is currently a very nice tool for those working on the backend of a site but content providers still really can’t use it without a lot of training.

The WYSIWYG side should also apply to the choosing of images (there is currently no thumbnail browser) and sizing them appropriately within the context of all the rest of the text.

I’ve looked at this feature when working with WordPress and the WYSIWYG editors out there do support this feature, including TinyMCE. See here:…

The feature does then truly make a WYSIWYG editor WYSIWYG.

This was delivered in 3.1, released in early July 2013

Hi Dan,

Please keep us informed about the image browsing feature. This is a pretty critical function for multimedia oriented sites.

Looking forward to using the next rev of CM1.


is there any documentation in the how-to’s about how to use the feature?



Here is the documentation on how to use the feature:…

For reference, the page has moved to… (found it easily by searching)

I can’t believe there hasn’t been more activity in this thread!

This is absolutely critical to the usability of the product. If the editor isn’t structured, like CM system, which allows for extremely atomic levels of control over styling output, then you have to hand over control properly to the end users.

Have I missed something here: is CM1 only aimed at competent HTML users?

Here’s my suggestion:

  • Make a rich-text widget property [stylesheet] which allows you to override the default styles with a stylesheet on a per widget basis
  • Or have a themed stylesheet tinymce.css that is picked up by the editor only.

In the meantime, I’m left with another annoying problem to work around, not fix.