Joe,

About 1,5 years ago I have created 2 skins for MojoPortal-based project (that is still in development), and since then I maintain them. Now I also need t create the third one. Here are just some thoughts.

1. Skins are difficult to create.

The typical situation is that I recieve html with css from the designer with the task "make the site look exactly like this".

I begin with copy of one of the existing skins. Then I mostly replace contents of layout.master with my html with inserting some portal controls into it. Unfortunately, it's not that simple (for example, trying to just insert content placeholders into html results in NullReferenceException from portal code, and inserting them with their panels results in changing their css classes from code), but accessible.

The hell begins when I try to make the designer's css work with MojoPortal. The thing is that I cannot just throw away the original skin css files and replace them with the new ones (if I do that, some portal functionality like admin pages will stop working as it uses css for positioning config pages parts). I also cannot just place them together because they usually set the same properties of the same elements, and very strange things happen. So I begin to parse the designer's css and line-by-line integrate it into the original skin css files. It's not a simple task. And if the designer changes anything, this work sometimes begins from stratch again and again.

2. Skins are difficult to maintain.

After being created, the skins must be maintained so that they work correctly in new portal versions. The only way I can do this is regular reading svn log, analyze all the changes to the skins folder and make corresponding changes to my skins. For example, in revision 5006 you fixed a bug with Opera, so I made this change to my skins as well (because I also do not want to have this bug). Sometimes new styles appear and I need to add them as well to make the portal admin pages and standard features work correctly.

If I do not do this, after a while my skins become incorrect, and so I regularly spent plenty of tyme for maintenance.

3. What can be done to simplify this?

As far as I can see, there are some ways to simplify the process.

a) Now css files are mostly devided by functionality (layout, text, color, etc). It would be nice if layout is devided by usage (core with all admin pages, master page, particular features). In this case when creating a skin one can throw away just old master page css and use the others without any change or with very little changes.

b) Some features have their own layout in css that is duplicated in each skin and differes rarely. When something changes there (something new or bug fix), any author of any custom skin must perform the same change. It would be nice to have some "default" skin-independent css that will be included automatically to each skin that does not override it (for example, by having the file with the same name). In this case it will be easier to maintain custom skins that are "nearly standard, but with a little change". Another solution can be to set one of standard skins as "base" skin and use css files from it in case they are not overrided in the "child" skin.

What do you think of this?

Joe,

I understand your position, I do not want you to rewrite the skinning system. Just wanted to discuss the ideas. If you like the ideas, I shall try to produce a non-breaking patch that will implement some new functionality (like standard feature css).

Ok.