RedDot and CSS: A better way

[NP]

I have always had an issue with RedDot and stylesheet handling.
Whenever CSS changes have to be made, i generally receive changes made
by front-end developers to static CSS files, which I then have to diff
with the files on the RedDot server. This is a miserable diff because
RedDot does all kinds of crazy things with white space, not to mention
that all the images have to be replaced with placeholders (or you can
put your images into the file system, but then they have to be
repeated on the CMS and publishing targets).

On my next project I was planning on trying a new tactic: separate CMS
and static sites. The gist of it is that all style sheet references
would be full URLs referencing the static site, like:

<link rel="stylesheet" type="text/css" href="http://static.mysite.com/
mystyle.css" />

instead of re-creating all the style sheets in RedDot and inserting
placeholders for them. This way, when the front end work is done, the
changes get pushed to that static site and RedDot will start reading
those styles in immediately, eliminating the need for long and error-
prone updates.

Anyway, I wanted to get some feedback from the community before I give
it a try since it seems a little too good to be true and I feel like I
might be missing something. Anyone have any thoughts?

[joshua...@gmail.com]

> Anyway, I wanted to get some feedback from the community before I give
> it a try since it seems a little too good to be true and I feel like I
> might be missing something. Anyone have any thoughts?

I'll try to get something put together for the RedDot blog... we have
a couple of content classes that allow our developers to have full
control of the stylesheets, and they work in such a way that image
references etc. work in smartedit the same way they work on the
published site. If you trust your content providers, this eliminates
the burden of CSS management from the RedDot administrator.

[Ingo Hillebrand]

> Anyway, I wanted to get some feedback from the community before I give
> it a try since it seems a little too good to be true and I feel like I
> might be missing something. Anyone have any thoughts?

i still have doubts concerning your solution with static css files. In most of our projects are multi lingual, so you have to build a seperate css file for every language - if i understood your approach. Corrections in the css file is everytime a little bit annoying, but this task is done by our frontend-developers - not the reddot-administrator.

Greetings,
Ingo

[Chris Nixon]

Fwiw.. We have taken to hosting css files in a central location and hardcoding the link back to them. We do manage a unique css file as a content class in cms but it's purpose is just for extra styles unique to a site.

Otherwise a screen css file as a content class linked to an anchor, or in v9 a container to help with mozilla rendering and set to show link only, works ok.



Chris Nixon
4792364930

--

You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To post to this group, send email to reddot-c...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=.

[kimdezen]

We've had some very lengthy discussions about CSS/RedDot in the office
over the years (many developers have conflicting ideas about the best
way to handle CSS)..

However - here is the general consensus:

1. When developing a new site, always keep stylesheets outside of
RedDot (create absolutely referenced links to the stylesheets). That
way whilst you are developing your templates/content classes, front-
end developers can continually keep make changes to the stylesheet to
fix an bugs/browser compatibility issues without having to touch the
CMS. This is particularly helpful if you are using a deployment server
- whenever changes are checked in to Source Control, they are
automatically deployed to the location/server where they are being
referenced.

2. Once your site has been developed and test and is ready to deploy,
either:
a) Convert the stylesheets into Content Classes so that all
styles are managed within the project

OR

b) Reference the stylesheets directly from the published
site


I would suggest using option A if you are unable to directly access
the live server (via FTP etc) due to security restraints/restrictions
(particularly if the site is an Intranet hosted within an internal
network). The CMS makes it easy to update styles in this situation!

If you need to create specific styles for SmartEdit mode, or for
specific language variants - then simply manage these within a Content
Class. Any style within the referenced stylesheets can easily be
overridden within the CMS.

The main reason to keep stylesheets out of the CMS is to cut down the
amount of 'manual' duplication required to copy styles from the
'cutup' templates. Whenever you need to manual deploy changes, you
will always need to re-test everything in case you screwed something
up (which can easily happen from time to time!!!!)

Cheers,
Kim

[Nathan Palmer]

Kim - You hit the nail on the head with the manual duplication problems. That's my primary motivation for moving to a model that cuts RedDot out of the style sheet process as much as possible. Clearly I'm not the first to think of trying this and I'm glad to see the larger community has taken to it (or something similar) and had good results.

[Dave R]

I've started to build a series of content classes for css so I can
quickly parse and edit sections like basic layout, typography, colors
and background images. I dump all of them into another content class
that is just a container so when the css actually gets published it's
still just one file.

The main problem may be that the person who is generating the CSS
isn't also working in RD. I'd work at getting him more involved in the
CMS process. That would actually help both of you. One, he'll
understand better what you do and two, you'll hopefully have a bit
more influence on how things are coded.

I'm not sure there is a way to avoid what you are doing now. Even if
you do separate the static out, how do you plan to upload the images
to the site? Wouldn't you need to do that manually then outside of RD?
What happens 3 years from now if you aren't on that project? Are you
going to document that well enough that they will understand those
files aren't in the asset manager? That would be my biggest concern.