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”.

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.

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.

@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?

@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.

Markus, I like the idea of the CSS compressor as I also felt this could be done as a step for delivery optimisation.

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

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

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.

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.

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)

@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.

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.