Rich Text Format Area CSS Classes vs. Custom XML Nodes

I’ve seen requests on how allow Tridion content authors the ability to:

  • control styling
  • change the selectable options
  • insert custom XML tags, or
  • embed component presentations.

Consider using author-friendly, business-focused CSS classes along with your rich text format area GUI extension to accomplish this.

Control Styling or HTML Elements

Website and content professionals know about the risks with author-controlled manual look-and-feel styling. Inline styling might work for small sets of content on a single site, but doesn’t scale well, is brittle to change, and allows content that doesn’t apply to company branding.

Rather than giving inline styling control, you could offer CSS classes to separate content from layout, but you miss the point if you use design-related class names like “red.”

Good CSS class names to offer Tridion content authors:

  • priority (high, medium, low, urgent, etc)
  • department or product-related (marketing, mortgage, finance, featured)
  • functional terms that have semantic meaning (note, callout, quote, video)

Not-as-good for the rich format (RTF) area editor:

  • position (left, right, top, bottom–may be okay, but consider internationalization or what “left” might mean in a different context such as mobile)
  • color, font, or presentation-related (red, blue, Arial, large)
  • terms not clear or relevent to authors (col-20, clear, doc)

We can debate on appropriate names, but it’s better to err on the side of business terms and functionality rather than presentation.

Custom XML

I understand the appeal of allowing custom XML nodes in RTF. But it’s better to avoid these unless you’re willing to change the config and make an author-friendly extension to add, modify, and remove these tags. Though content editors may need control over source, ideally they should be able to do much of their work in the rich text format editor.

I don’t use “Best Practice” lightly, but maintaining valid markup, separating content from presentation (code), and reducing IT risk by not adding proprietary tags to rich text are all CMS Best Practices.

Custom tags, especially to a specific framework (3rd-party integration, .NET controls, Java tags, etc), add unnecessary risk to your CMS implementation. You’re asking for trouble if/when the CMS changes, the framework changes, or that hot social media API changes.

Embedded Component Presentations

Tridionauts regularly use component link references to associate content. Occasionally we have requirements to choose content and presentation within an RTF. Though I’d rather not have typical authors need to make these choices, occasionally you do need to place such things in an RTF area. For example:

  • In-context placement for existing content (as in a call out, quote, definition, or certain media)
  • Content authors that act as designers for select pages (use sparingly)
  • Some other script-driven functionality when you don’t want authors to actually enter JavaScript into the RTF

Though you won’t be able to see the injected content in the RTF (without some creative extension work), you could easily mark such content injection with appropriate styling such as a border, background color, image, etc.

Worthy Formats

Frank van Puffelen suggested the “data-uri” HTML 5 attribute would make an ideal future-proof way to store such merge field references.

  <span class="keyword"
        data-uri="tcm:0-1-2">My keyword label</span>

Unfortunately, the default XSLT rich text filter + any content manager validation removes this element (at least in my SDL Tridion 2011 SP1-1 VM). If you can configure this the CMS to allow this, I’d suggest it as a good option and a great blog post topic. ;-)

Update: Nick Roussakov shows you how to allow the HTML data-* attributes. The biggest caveat is this is not a supported approach. Add it to your upgrade scan list (things we changed) and use sparingly.

Dominic Cronin has used the script tag to denote such merge fields. This lets you include both a value and a attribute/parameter value for use in your templating code. It also hints there’s more to this content than just content.

<script type="{something indicating json}">{foo: bar}</script>

He’s also pointed out that we’re not exactly dealing with XHTML in the RTF area, but rather “XML in the XHTML namespace.”

Chris Summers, Outbound Email itself, and plenty of Tridionauts I’m sure, use plain text with a delimeter. It’s a bad idea to use a single characters such as “[" and "]” since they could be part of the content.

  • [[merge field]]
  • [*merge field*]
  • {{merge field}}

Choose a format that fits your development needs. For example, you might find it easier to parse text delimiters or XML attributes. Also avoid delimiters that your authors may need (unless you offer a way to escape such characters)

Sample Code

To add some visual flair, backup then update the FormatAreaStyles.css file in %TRIDION_HOME%/web/WebUI/Editors/CME/Configuration/.

And add a class such as:

 
.note {
	background-color:#FFFF66;
	padding:3px 5px;
}

Authors can then apply this using the style drop down. If you want to get fancy (creatively lazy), check out CSSButtonGenerator.com to create a button look.

Adding custom classes and corresponding styles allows editors to visually see their selections.

What’s next? Convert this agnostic, business-friendly format, to code or markup your presentation server can use. For the best performance, do this with Tridion templating. But if you need any (render-side) post-processing with non-Tridion data, consider some type of coding “hook” (tag, control, script variable) as the preferred approach. Use brute-force text replacement as a last resort.

Thanks to Dominic Cronin for the debate the revelation on worthy CSS class names for the RTF editor (he’s quite convincing on TridionWorld, Frank Van Puffelen on the HTML 5 format, and Chris Summers (et al) on the merge field variation. Follow and contribute to the StackOverflow Q&A on this topic. +1 specifically to Kah Tang’s answer–he offers yet another approach on converting these such classes delivery-side (actually client-side).

3 thoughts on “Rich Text Format Area CSS Classes vs. Custom XML Nodes

  1. Great post Alvin. I have often seen RTF usage not particularly well though out up front. People tend to look at an HTML design, see a block of formatted text, add an RTF field to their schema and move on, without looking at the details. Then during implementation (or even worse, UAT) developers find they need to start implementing little tricks to get the required output. Without proper strategy and design, these build up in an incoherent way and you end up with a mess of little workarounds and hidden magic that developers find hard to maintain, and editors get confused by.

  2. Hi Alvin, nice post!

    I’m getting more and more clients needing to use HTML 5 on their site, and this includes HTML 5 within RTFs. It seems from the discussion above that “custom xml nodes” are the approach to enable HTML 5, since the new elements, such as

    are just custom xml nodes in the eyes of the existing rich text editor.

    The unsupported approach in my post will actually work for any HTML 5 within a Rich Text Field, not just data-* attributes. But it will also let you input non-html 5 junk as well. So it’s not ideal.

    Out of the options you mention above, if HTML 5 is the required standard for a website, which would you choose?

  3. Hey Nick, I’m interested in what approach your clients are taking.

    I’ve personally yet to meet authors that actually author _in_ HTML 5.

    If on a budget or as a POC to try out approaches, I’d consider moving the in-RTF elements (tags) to css classes and maybe some standard for HTML 5 attributes and their values like maybe class=”html5_color-colorvalue” or maybe class=”html5_attribute_size-value.” You might play with the naming convention and what’s easiest to parse.

    For longer engagements or if the customer can own and support them, consider GUI extensions for certain elements or attributes. The content-related tags like article or footer feel like they should be templated (rather than allowed in the RTF).

    Some should be easier to implement by looking at the business requirement. For example if adding a video you could simplify it down to a component or image link and change it in the template or in delivery.
    http://www.createandbreak.net/2013/01/making-config-component-disappear.html

    Either way, you can always add an XSLT filter to further restrict elements, even if you’ve allowed more than you wanted.

    If the customer really wants an HTML 5 editior and they’ve planned and measured the business impact of “HTML 5 in the RTF,” then maybe it’s just a plain text box in Tridion. Get the HTML 5 from some editor and get it into a text box in Tridion.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>