Jan,

I don't see how a new version of skin.css would overwrite the CSS for a module if you upload te right new skin?

If you use a portal skin, you can add an @import on top of your skin.css and include a custom module.css, so IMO you can already do what you suggest.

BTW, the major problem with module.css is what's in there sometimes, not the fact they exist IMO.

It sucks if you have to overwrite a lot of CSS you don't need (I have seen font-family definitions in module.css...)

BTW, I have a skinobject to solve this and some other css issues.

It lets you UNLOAD any CSS file the framework injects (server side) so module.css or for instance default.css will not be in the page HTML source.

Will release that one later (not as a part of the Core)

Timo, the overwrite was a response to Sebastian.

If you add parts of the module.css to the skin.css and after that upload a new release of the skin the skin.css will be overwritten.

If you dont see the problem with that I will explain better later but I think you understand the problem.

@import have the same problem you have to change skin.css that will be overwritten with new relese of the skin.

I hope you see the need to have access to the module.css from the file manager.

Jan