// you’re reading...

Best practice

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.


How can proper CSS integration save time and money?
Read more

Share and Enjoy:
  • Print
  • email
  • Twitter
  • Digg
  • Reddit
  • StumbleUpon
  • Google Bookmarks
  • del.icio.us
  • MisterWong
  • Facebook
  • LinkedIn

No related posts.

Pages:

1 2 3

About the author:

Markus Giesen Markus Giesen is a Solutions Architect and RedDot CMS Consultant, formerly based in Germany. Travelling around the world to find and offer solutions for a better world (in a very web based meaning). He just found a way to do this as part of a Melbourne based online consultant house. On this blog Markus shares his personal (not his employers) thoughts and opinions on CMS and web development. In his spare time you will find him reading, snowboarding or travelling. Also, you should follow him on Twitter!

Discussion

15 comments for “7 reasons not to integrate CSS into RedDot CMS – A best practice”

  1. Markus:

    I went about halfway to this solution with our most recent project; I hard-coded absolute URLs to the CSS, so that editors can see the page layout as it will appear when published. The same with JavaScript includes, which we had formerly (and maddeningly) tried to manage from within RedDot.

    The downside appears to be having a single URL for the CSS (www.example.com/css/main.css) on all language variants (even on de.example.com, say), pulling content from a different domain. The functionality within RedDot is good. The only place it doesn’t seem to work is on the RedDot server itself, which is firewalled off from external sites and so cannot access the CSS files.

    All that said, it would be *great* to see CSS integrated into RedDot. I would like to be able to say, “copy all the .css files and related images from the main server to the ‘css’ directory on all the various publication-target servers”.

    Posted by Rob Palmer | February 9, 2010, 1:26 am
  2. There’s another good reason to do this.

    I’ve had the CMS (because of internal bugs) accidentally not publish the CSS files, resulting in a completely broken looking site.

    I’ve come to this realization lately too, and will be recommending it in all future cases.

    Posted by Ed | February 9, 2010, 1:28 am
  3. I’ve been following a thread on the google groups about this. I think there are both pros and cons to this approach. One benefit i think you may have missed above is that the pages should render a bit faster as the cms doesn’t need to render the css files and draw the images out of asset managers. static file access should be that little bit quicker.

    One negative i can think of for storing the css externally is that it’s another thing to configure, setup and backup when moving projects around instead of it all being bundled up in the cms project. One of my clients also appreciates that they can control the bulk of their website from within the CMS (including the css) as they have greater control compared to the OS and server software level (they don’t have the admin logins or the interest to muck around at that level).

    I think your suggestion above of the cms handling the css in a smarter way is a good idea. A quick way for OT to get something up and running to publish out the static css and images would be to reuse the .net folder code and have a “static file” folder that references a network share (the css folder containing static css and related images) and publishes if they are changed/updated as you suggested above. I know a lot of people have discussed this kind of functionality in the google groups in the past.

    I’d be a bit hesitant to call keeping the css outside of the cms as a best practice as the “to integrate or not to integrate” question, i think, really needs to be discussed and answered by the client depending on their circumstances.

    Posted by morgan ritchings | February 9, 2010, 1:32 am
  4. @Rob: I can think of many solutions for this one. You can create ONE standard field in your project which defines the current language. Depending on the fields value (for example: “de”,”en”,”es”,…) you can use render tags (http://www.reddotcmsblog.com/render-tags-an-overview) to check which language gets published and include language dependent files.
    Does that help you?

    Posted by Markus Giesen | February 9, 2010, 2:09 am
  5. @Ed Good point! That can happen easily when you start making elements editable within templates or the template editor messes with your CSS code. Not unlikely seeing that the template editor is not exactly what I would call state of the art..
    @Morgan: I think that the risks involved in changing CSS on the CMS are not worth the hassle. PLUS it’s faster to change CSS files via direct upload in my opinion. Sometimes a clients shouldn’t be that lazy. :)
    I like the idea of the copied .NET folder functionality, although I think that even that one needs tuning and definitely more setting. I’d rather have a plain text editor for my CSS than the RedDot template editor.

    Posted by Markus Giesen | February 9, 2010, 2:16 am
  6. Markus, I like the idea of the CSS compressor as I also felt this could be done as a step for delivery optimisation.

    Posted by Danny Baggs | February 10, 2010, 11:48 am
  7. Hi Markus,

    Well I agree with some of your arguments but for others in our case particularly we have to use a hybrid mixture of some css as dumb files but others through the CMS. We have splash background images, sponsor templates which have designs using css components that would result in a massive increase in tech team work if editors were unable to schedule and modify these css elements.

    So from my perspective you have to consider; how often styles change on your site, do you have various sponsor commitments that follow a templated style approach before making this call.

    Cheers,
    Barry

    Posted by Barry | February 10, 2010, 10:49 pm
  8. Hi Barry, another good point. Of course I am picturing the perfect solution only existing in a developers world of candy & chocolate..
    Based on your example I have to agree, you are right, sometimes editors have to be able to change a background image or other things.
    I usually use the <style>-tag to give access to these elements.
    If your style never follows a pattern I would say give editors with appropriate knowledge access to their own dynamic CSS parts and let them change what they have to change.
    The compromise between no-access and full-access is always somewhere in the middle with the best commercial outcome or so to speak less load on the development team when it comes to content related day to day tasks.
    One day I would like to have a look at the structure of your system to see how it is set up. Seems to be an interesting combination.
    Cheers,
    Markus

    Posted by Markus Giesen | February 10, 2010, 11:38 pm
  9. Compressors for JavaScript, CSS and images can be added inline to the delivery system of the web server (apache/iis) and needn’t be a function of the CMS. That way the files are always readable for authors/developers should it be necessary.

    Obfuscators can be added to the delivery of JavaScript files too if desired.

    For IIS these come as plug-in ISAPI or .Net pipeline modules (depending on your IIS version) and are relatively cheap, compared to RedDot anyway.

    This makes for a no-touch solution which is generally less prone to problems and reduces the load on the CMS to boot.

    You should definitely set compression on in IIS/apache and this makes removing the whitespace in css and javascript a bit moot anyway.

    Posted by Richard Hauer | February 11, 2010, 3:10 am
  10. I think this is a good solution for a .NET based environment. Although Open Text has to stick to their manifesto of “our solutions run on any web server”. Hence my suggestion of solving this issue on the CMS side.
    The CMS brings together content & templating, therefore it should as well take care of CSS delivery. Assuming you want to publish to several servers / a staging environment managing the CSS compression on the web server is another moving part that adds risk and instability to projects.
    And again: It’s not an IDE therefore you don’t need to see the code. If it breaks on the website one should go back to step one (HTML templates) and check what went pear shaped in the first place.

    Posted by Markus Giesen | February 11, 2010, 5:34 am
  11. We also found out very quickly not to integrate CSS with our projects (we have in-house designers who complained almost instantly about it), the set-up is a bit of a pain as we have a virtual folder to store the css on the CMS server and another on teh live server and just use rendertags to change the linking to these files. It takes a littel biut of setting up but once you have done it a few times it becomes second nature and it speeds up design no end. (plus you can then put them in a source control application and not have to use the almost useless source control in reddot)

    Posted by Tony Gayter | February 11, 2010, 12:18 pm
  12. @Tony: Absolutely true, source control and versioned CSS files are incredibly helpful! We have a deployment server in use to automate the deployment of approved CSS file changes.

    Posted by Markus Giesen | February 11, 2010, 12:56 pm
  13. I tend to agree with Morgan on this one as well..

    I think it depends on the project, client and where the site is going to be hosted.

    Of course the best approach is to completely remove CSS/Images out of the CMS, however i will always way up the pros and cons before i start development.

    Ive worked on so many projects that were hosted on servers that were only accessible via a Citrix/Secure connection. To try and upload changes to CSS/Images directly to the server would be so much slower than logging into the CMS, making a quick change to the template and republishing.

    Despite which approach you use, i would ALWAYS recommend that stylesheets are kept out of the project during initial template development. That way your cutup/front-end guys can make all the changes in the world to the stylesheets without the need to constaintly update styles in the CMS.

    Posted by Kim Dezen | February 12, 2010, 4:56 am
  14. Alright, I have started to attempt this approach. I have the CSS folder set up as a file folder on an asset server (which I have access to). I also have the images set up on that server, in a different subdirectory:

    assets/css
    assets/cssimages

    The problem I’m seeing is the images won’t load using this method. I have attempted to use:

    background: url(’../cssimages/myimage.jpg’);

    Thoughts? Am I missing something?

    Posted by Joel K. | April 20, 2011, 1:25 am
  15. of the 280 some projects we have in CMS 10 we put the css in a content class and then link to it with an anc placeholder. We store anything that is used for design that the clients will never be able to get to inside file folders and not asset manager folders. I’ve never had an issue with the CSS not publishing.

    Posted by Cherri D, | July 8, 2011, 10:33 pm

Post a comment



Stay up to date! - Get notified about followup comments

If you don't feel the urge to comment but wish to stay in the loop:
Just enter your email and subscribe to new comments.

Subscribe without commenting

Recent Tweets

  • RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
  • The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
  • RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
  • Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
  • More updates...