I am sure we have all had it – that feeling of excitement of a crisp blank piece of paper and a set of freshly sharpened coloured pencils. You are about to start implementing Tridion templates for a greenfield website implementation. No legacy VBScript scribbles already on your canvas to worry about, your favourite .NET TBBs and Custom Functions at hand to boost productivity. You will be knocking out Component and Page Templates by the hour and feel the buzz of seeing that sexy new site start to form on staging before the end of the day! Then you check the source of the html files in the zip provided by the design agency and your heart starts to sink…
At first glance it may look like nice, clean HTML, but when you actually start chopping it up into templates things start to niggle. The CSS class on the <body> tag changes on each different page, depending on what content is shown in the main content area… Component presentations in a column layout need to have specific styling depending on which column they are in… Images within HTML that would be part of an RTF field use tables or divs to provide alignment… Images are used for editorially managed content text such as navigation and headings. And so on…
Each of these challenges requires a workaround and leaves you with an increasing feeling that your implementation is becoming more complex than it needs to be. Your templates fill up with more and more noise from all the conditionals and custom function calls until your nice clean HTML is hardly visible any more, and your Default Finish Actions TBB contains 27 different sub-TBBs to do various pieces of sorcery to warp and bend the output to match what was provided by the design agency and signed off by the customer.
So what’s the best way to deal with this? Like any ailment, prevention is the best cure. You need to get in there early, before anyone signs off the HTML. When the agency (or whoever) starts cutting HTML from their Photoshop design concepts make sure someone who knows Tridion templates can review the output. Give them a little training (SDL has a Design Principles training which covers such stuff), especially on how a page is broken down into Page Template and Component Presentations, and what you can and can’t do with a Rich Text field. Help them understand content reuse, and the impact of this on the separation of content and design.Â
There are a lot of things to look out for to make and HTML Design play nice with Tridion, but here are some of my top ones (based on how often I have seen them, and how much pain they cause).
#1 Apply content styling at Component Presentation (CP) level
Often I have seen styling applied at too high or low a level. An extreme example of this is the <body> tag having a different class depending on what content is displayed in the main content area (news, events, products etc.). Usually this is not necessary, as simply moving the class down to the container for the content (ie CP level) will have the same effect. Without this you have pain as you have to put logic in your Page Template, or worse still Master Page or equivalent. If the Design Agency understands what a CP is, they should start to understand why this is important. It will also help your CPs work in different combinations on different pages, should that be required in the future (an event summary CP could be shown within a product type page without styling issues and so on…).Â
At the other end of the scale, you will also have problems if your styling is too embedded in with the content. If our news articles have a specific style for bullets, and this is specified in the HTML on the <ol> element itself, editors will have to select this style when entering content (or we will need to write a TBB to add this in). Better to specify this in CSS for the whole news article CP block.
#2 For a list of items, use a list!
If I had a euro for every time I have seen a page with a list of component presentations shown using a table, or divs with classes like col1, col2, I would be able to have a decent night out in Amsterdam. The problem is presented here (along with my solution in the comments) and John has a great solution for dealing with this but wouldn’t it be nice if a list, was represented as… a list? People bang on about the importance of semantics, but in this case, it also makes template logic so much easier, and indeed your output much more cross-device friendly (if the screen width cannot handle 3 columns, a list flows much more gracefully than a table or proprietary div structure into a layout with fewer columns)Â
#3 Will that content block work as a Rich Text Field?
Although you may not have yet done a full schema design, there will be some content areas which look good candidates for implementation as an RTF field. Bullet lists, hyperlinks, images and other formatting features are in the content text, but take a look at the source. Does this map well to simple XHTML? Some styling is perhaps inevitable, but preferably styling should be applied on a higher level element (see point #1) so editors do not need to worry about selecting CSS styles on the content in the RTF field. Image alignment and captioning is a common problem. Editors are not going to want to add a table and/or div in order to align their images and add a caption.
#4 Do elements containing editorial content scale well?
This is a classic. When we cut up the design into HTML, we create some test pages, and because we are lazy, we just use the example content already provided in the HTML design. We publish, and hurray – it looks great! Then testing starts, real content is used and disaster! It looks a mess – they added another footer link and the whole footer became misaligned, one of the product summary boxes has a bit of a longer description than the others and it screws up the look of the whole list, when translated into Finnish, the top navigation doesn’t fit on one line and makes the main content area mis-aligned with the other elements.Â
While you will never be able to catch all problems, it is quite easy while viewing the HTML design using Chrome or Firebug in Firefox to jiggy the content in the HTML source around a bit , and check that the main elements scale well with different content.
#5 Avoid images for textÂ
There are so so so many reasons not to use images to display heading or navigation text on your website, and only one reason to do it (the company brand uses a font that is non-standard). You want to know them? Well think about SEO, accessibility, font-scaling and inability to globally change the style first, before moving on to Tridion specifics like having to write code to generate the damn things and integration with SiteEdit/New UI. Its 2012! Most browsers have a pretty extensive set of fonts, and most screens are pretty good at rendering them nice and smoothly.
To conculde…
As I said, that is just a few of the things to look out for. I am sure you have your own personal bugbears  – so let us know in the comments. My final word on this is do not be afraid to be stubborn. Any time you invest in HTML review will be saved 3-fold further down the line*, and if this agency continues to work for Tridion projects, they should understand that they need to develop a competency for producing Tridion (or indeed any CMS) friendly HTML.
*Time is saved not just in development and maintenance effort, but also in testing. In my experience, the effort taken to discover and fix an HTML bug during UAT can be totally disproportionate to its complexity. The bug is first discovered and logged by the tester, then processed by a test manager and probably assigned to a template developer who will then analyse it and discover its a problem with the HTML. This then needs to be explained to the  design agency (who often do not have access to the issue tracking system), who will issue new HTML/CSS which then needs to be updated in the the dev CMS by the developer, re-tested and deployed onto the test environment. The issue needs to be updated, retested by the UAT tester and then closed. HTML review cannot prevent all such bugs, but will certainly help.
Excellent post, Will. One big impact I’ve seen on the HTML is an organization’s current practices and environment. Anything from outsourced designs, to CSS frameworks, to IT cost structure (if template work is expensive, design can unfortunately get pushed into RTF areas) can all influence the design.
For example, I’ve seen object-oriented CSS work brilliantly well with that alignment of “namespacing” at a component presentation level with mostly class-free elements as you explain. But I’ve also worked with pre-Tridion setups and teams that preferred CSS class names on almost all elements. Sometimes templating langugage options might help (XSLT or TBBs that decorate elements automatically), but ultimately the technical debt is often spread between designers, developers, and the authors. Same approach, different outcome.
I keep telling people that ‘technical design’ is as necessary for HTML as for any other part of your implementation. You mention putting classes on the body tag; actually that can be a great technique, if you want to signal different page types to your CSS. So the same component presentation can display itself differently depending on the page layout, and all with exactly the same HTML.
My biggest bugbear, though, is the over-use of IDs in HTML designs. Fine if you want to call out the big divs in your page design: … that kind of thing. It works quite well for things that belong in your page template. But any template that might be repeated on the page (i.e. component templates) has got no business emitting IDs. Mostly when you find these IDs in the HTML design, it’s totally needless. OK – there are exceptions, such as when one HTML element needs to reference another. Where it’s necessary like that, you’ll accept the added complexity in templating, but not if it’s just to wire up the CSS,
In this day and age, anyone doing professional HTML design will be designing for content-managed systems, let’s say, 100% of the time, so there’s no excuse for being unaware of this kind of issues.
Good thoughts on ids restricting flexibility of design – I agree totally. However I think <body> is normally too broad a scope even for Page Type level definition, unless we are talking totally different page templates (with different header, navigation, footer etc.), or you have a design which applies different css for different sections of the website (news pages have a blue-theme, events green etc.). Usually there is a content container at a lower level where you can apply the style. If you are using .NET master pages for example, the body tag will be in the master page, so you have to fiddle around a bit to get different CSS classes rendered for different pages using the same master – its not impossible, but exactly the kind of workaround that builds up to make a messy implementation, for no reason other than the HTML designers were a bit lazy/incompetent.
As per SDL Experience Manager we should not use / avoid using CSS pseudo classes. Why we should not include (like :root, :first-child). Its something like Experience manager itself add tags to make the editable field and HTML hierarchy will change and CSS classes impact will be different?
I am not aware of issues with CSS pseudo classes and XPM – can you elaborate a bit more?
When SDL customers are using Experience Manager, please be informed that using the following CSS identifier might result in different behavior when viewing the staging website in Experience Manager. To avoid any problems, please don’t use the CSS identifiers below.
:first-line
:first-child
:before
:after
:lang
:last-of-type
:only-of-type
:only-child
:nth-child(n)
:nth-last-child(n)
:nth-of-type(n)
:nth-last-of-type(n)
:last-child
:root
:empty
:target
:enabled
:disabled
:checked
This is written in SDL Tridion HTML Guidelines. Just wanted to know why we should avoid the same.
I hadn’t seen that version of the HTML Guidelines – it sounds like a good question for tridion.stackexchange.com