by

Front-end Best Practices for Tridion’s Experience Manager

Reading Time: 2 minutes

Tridion’s Experience Manager (XPM) has been a hot topic at Tahzoo recently. Piti Itharat, Shawn Webber, and I have all been talking about some of the “gotchas” we’ve experienced in the front-end of XPM implementations. Especially after a few front-end folks started asking for tips on how to be XPM-minded when writing HTML and CSS, the three of us put together a short list of best-practices and pitfalls for doing the front-end in XPM.

How XPM Works

SDL’s Experience Manager relies on HTML comments. Those comments get added through the TBBs (Template Building Blocks) of the component template. XPM provides some JavaScript that grabs some JSON that’s stored in those comments, and it wraps items, denoted by that JSON, in a span.

Markup

  • Wrap all unique blocks of content in an HTML container
  • Consistently use the same HTML element for each kind of content
  • Use xHTML compliant markup
  • Add a class name to every html element which contains content
  • Do not wrap content blocks in spans
  • Do not put spans inside of content blocks

Styles and Stylesheets

  • Use HTML conditional comments to add a class name that designates version of IE
  • Use Modernizr to target features in a browser for style fixes
  • Do not use inline styles written in content blocks
  • Do not use JS that writes styles on content blocks
  • Avoid browser hacks
  • Consider creating a stylesheet called XPM that contains all XPM style corrections

CSS

Selectors

  • Select elements with classes : .figure {}
  • Select elements with fewer classes, but more specific class names
  • Do not select elements with direct descendant, adjacent, and sibling : article > figure , article + figure, article ~ figure
  • Do not select spans by element name: h1 span {}
  • Avoid selecting with element selectors : article figure {padding:.618em}
  • Avoid styling on IDs

Properties

  • Use the cascade and specificity to override styles
  • Use The Roosevelt Trick to increase specificity: .someClass[class][class]{}
  • Do not use !important
  • Do not use negative margins
  • Do not use browser hacks
  • Avoid z-index

JavaScript

  • Add class names to the HTML element to give a ‘hook’ for style fixes: <html class="is-XPM">
  • Use Modernizr
  • Do not use client-side templating: Angular, Mustache
  • Avoid browser fixes (except for feature detection)

The Big Idea

A big thanks to Piti Itharat and Shawn Webber for helping put this list together. For the most part, our findings look strikingly similar to industry best practices. We don’t pretend that this list is exhaustive; it’s about 85% hindsight and 15% foresight — you may be able to prove us wrong on any of these points. But, if you wanted a quick and dirty list of what to look out for, here it is. And if you think we’ve missed anything, let us know!

2 Comments


  1. +1, though I’m sure HTML works. The Content Manager may use “XML in the XHTML namespace” but the final markup can be anything (though it should be valid).

    XPM will use span tags if using the default inline editing setting. Template developers could choose a different default or output a different containing element. The containing element point is important for XPM–most of the time the HTML I’ve seen has such an element, but occasionally images appear without a wrapping tag.

    I received a similar prompt on my side, but without getting technical–and it matches many of your points. I resorted to displays of beer:

    http://www.createandbreak.net/2015/02/tridion-user-expectations-for-html.html


    1. We had the question popup internally on our side regarding XHTML. I tried to research it, but couldn’t find a clear answer.

      However, on the flip side, you’re much less likely to have a problem if you do write valid XHTML.

Comments are closed.