Ok Jan, so  I guess we just don't agree..

Module.css management would be very difficult since you would have a local copy in every portal, so what to do if you upgrade the module?

The solution like the one for portal.css would mean a clone of module.css (portal.css is an empty clone of default.css)

This would add even more CSS files.

IMO your suggested solution is quite complicated for something I don't see as a real problem since we have portal.css for it.

Hi Jan,

I see your problem, I have experienced it myself many times, E.g. lately with a nice and simple forms module that always uses .NormalBold for the label and no way to hookup to this class without affecting the other .NormalBold instances on the page.

First, Timo's enhancement would help me (so I am in favor), now I can hook up to:

.SimpleformsModule .NormalBold { color : red ;}  

I can place the styling anywhere I want e.g. portal.css, skin.css, in the header of the page (< style type=" text / css " >.SimpleformsModule .NormalBold {color: red}< / style >), in the headertext of the module, etc.

Would your solution, having a separate "modulename.css" file help me?

In the above example I would not use it, because It is much easier to do it quick and dirty (in the module). A drawback that I see, is that this solution introduces yet another complicating factor, that is, yet another file in the already crowded portal file structure, which your clients should keep their hands off. I must always explain my clients not to poke around in the templates, skin, container, cache, etc. directories.

Given the fact that there already are a number of ways to takle this issue I would not recommend a separate "modulename.css" file in the portal directory.

Peter

As you can see in the mentioned Gemini item, this has been changed slightly.

The name of the class of the surrounding div will not be ModuleName, but ModuleNameContent. The reason for this is that some Admin modules are already using their name as a class and thus it would be added twice.

For instance, the Filemanager already used the class "FileManager" which conflicted with the new added class (they were the same)