rdb: 7 reasons not to integrate CSS into RedDot CMS - A best practice
Another big question that comes up every couple of weeks when people start developing websites with the
RedDot CMS Open Text Web Solutions Management Server is this one:
How should I integrate my CSS code into the CMS?
And the answer is fairly easy to give and even easier to remember:
Don’t do it. Do NOT integrate your CSS code into the CMS !
It took me several projects to actually reach encounter this epiphany. It’s not worth doing it. And there are several good reasons for not doing it. And I will share them with you, more than happy to discuss it.
Since last year I suggest the following procedure for every project I come across:
Remove the CSS templates and related images to style your site from your project and put them outside of the template and therefore outside of your CMS logic.
A template is meant to semantically structure the stored data from the datasource (a database or sometimes even just XML files). We call this environment a CMS – Content Management System. The presentation layer for this content is formed by those templates and the combined usage of style sheet files. This methodology is similar to XML and XSL, where one stores content, the other defines the way to present it.
Don’t integrate CSS into Content Classes » Markup arguments
CSS is not a template
Keep in mind style sheets are NOT templates. CSS influences the way content is presented graphically. CSS is not responsible for the semantically correct markup. There is a reason why it is called “content class” inside the CMS. Because it’s about content.
Background images are no content
Images such as background images, bullet points, logos, etc. are NO content, they are a way to present content. Hence they don’t belong inside the CMS template structure. They do not help you manage the content nor do they store any valuable information for your visitors which you want to change as CMS editor.
Border or Shades are no separators
A border below a DIV or a headline is not a separator, a separator is a horizontal ruler set in the HTML by using a <hr>-tag and. That’s how content is semantically correct separated not using the content elements borders.
Don’t integrate CSS into Content Classes » Process & Budget
And if these three semantic reasons are not enough for you then here are another four development reasons why you should not mix up CSS & templating.
It takes more time
Changing a value in a CSS file takes about 5 minutes. In RedDot CMS you have to do this: Open your CSS template, change the value, publish it to your staging server, test the result, go back to the CMS, if required make some changes, publish again to the staging server, then test again – repeat this step until you have the desired outcome, then – publish the file to your live environment, done.
It doesn’t work fast enough with international projects / shared RedDot projects
When using shared content classes for several projects they develop over time different layouts. Some marketing departments want slightly separate styles and your CMS construct starts to get cracks and you have to add an special CSS template here and another one there. Keeping styles separate from projects gives you more options to change them faster without having to pay too much attention to all depending projects.
It gives you more flexibility
Assuming you have multiple projects and you run a style change on all of them. You have to test each change which works for Project A also in Project B, C and all the others. And you have to wait for all of them to be changed in the development process until you can start testing because they still might change in the background if you start testing before the last change has been made
It adds more stability
Your presentation layer should be static. Whenever your content gets published usually the styles heet files will get published too if they are part of the template set. Content changes approximately everyday in your company.
How often does the style change of your project? Exactly. Seldom to never.
Why would you re-publish this everyday risking that it might fall over because editors have the ability to influence your companies CI? They don’t have access to it? Fine then again, remove the CSS from your CMS project it doesn’t need to be in there.
What should you do instead?
- Use a proper set of HTML templates before you start setting up your RedDot CMS project. Each final page template in the CMS should have an according HTML template. (If you didn’t go down that path yet it’s about time to set it up now, it safes you a lot of maintenance time and stress)
- Develop, test and maintain CSS changes in these HTML templates. If you find out that entered content in the CMS affects the way your site renders then test it in here and create an example page. It’s faster to test these pages in all browsers anyway.
- Once your development & testing is ready set up your project or update your existing project. A good place for your CSS files is the plugin folder of your CMS.
- Create a folder for each project inside the plugins folder and place the CSS folder structure and relevant files in there.
- Do the same by manually deploying the CSS files to your web server.
In your RedDot CMS project reference to the CSS files on your RedDot server when parsing the template code. For published files reference to your website CSS. This can be done by using render tags as described here.
How could Open Text tackle this issue
Open Text could easily integrate a CSS file compressor. This module takes the set of referenced CSS files and compresses them as one single file. It also reads out the image references. The compressed file and the image reference then will be attached to a publishing process. A file watcher checks for updates on the CSS files / CSS images. Whenever the CSS files change the compression / publishing process takes place.
This module can be switched off for development purposes and specific publishing targets. The RedDot CMS is NOT an IDE and should not be used to develop or maintain HTML and CSS changes. This module would be a great enhancement.