Hi Tjerk,

As Joe mentioned, you are complately free to organise your css files as you see fit by defining them in the style.config file they will be combined and minified so its possible to organize in multiple files as I did or you could put it all in one and you can put common ones in a shared location. The  only reason all the included skins are done the same way is because I made them and I tend to do them the same way. A Few years ago I read a CSS book where the author mentioned it was a useful strategy to break things up by functionality like colors in one file borders in one file, background images in one file, then you could easily change just the colors by swapping out a different color file or change borders etc. I admit that over time as I have added new things to the css I tend to just add stuff to the bottom of the stylelayout.css because its less work than editing multiple files especially when I'm needing to add some css to all the skins I include. Different designers have different preferences about how to organize them so we support that by our style.config file and css combiner/minifier.

Its true you don't have control over css class names but enough classes are used in the markup to allow any kind of selectors for any kind of styling. The markup is structured with good semantic headings and structure but it does have extra non semantic divs primarily to make it easy to skin.

Its true that you don't have control over the markup of features but you do have control over some markup in the layout.master and you also have control over all the markup in your content like within an html module or within a blog post. Please understand to make it possible to skin a site with CSS there have to be consistent markup otherwise how can I make css based skins to style it. I've looked at ways of trying to make templates for different features but it would be complicated and would result in an explosion of files because the templates would have to exist in each skin to meet my goal that skins are self contained and can be changed with one click. Also upgrades would be problematic because templates would have to have some code in them so if my code changes and someone has a skin with an old template it becomes a problem.

I do have some future plans for some extensibility points that will allow you to inject some extra markup in various places like the side bar of the blog for example.

There are some differences with working with a pre-compiled language vs an interpeted scripting language like PHP. They have easy mechanisms for include files for both markup and script and if you are used to that it can seem like you are losing some control things you had more control over in that environment. But really our markup is pretty good and limitations mainly come from lack of CSS knowledge. Those who are really good with CSS don't have much trouble skinning mojoPortal at all.

So, in short its not easy to provide something that both provides consistent markup and a set of skins that work and also give you complete control over markup. If there were an easy way to do it I would but all ways I see are complex. its a little better in the new ASP.NET MVC model where you can override views it becomes easier but its still problematic because there is code in the views and a custom view could easily break when a feature is changed or upgraded. And its gigantic task to move to the MVC framework from WebForms. Over the long haul I plan to begin a separate project for and MVC UI on top of the same plumbing as our WebForms version but it will be a long time before it has anywhere near the functionality we have now in WebForms. Any CMS is going to take away some control over markup, the only palce where you have complete control is static html, there is always a tradeoff.

Best,

Joe

The "over-complication" you speak of is a matter of preference in how to keep the css files organized. You can have just one css file and mojo will work fine. You, as the designer, control the inheritance in CSS. When you move the selectors around inside of your single CSS file, you control the inheritance. Also, if you choose to use multiple css files, you can change the inheritance by (1) organizing the content of those css files and (2) changing the order in which the skin.config file lists all of your css files.

I agree, WordPress is not a CMS.  Now if we could just get all the WP junkies to realize this simple fact.

-Joe D.

Hi Tjerk,

Also wanted to say that if you do take an existing skin and re-organize and condense the css to one file I would be glad to have it in the project to replace the existing version and have an example for others to follow that is more simple. I do get your points and see the value of that.

Best,

Joe

I have a skin I will be contributing to the Project soon. I will make sure it is reduced to one css file when I submit it. :-)

Hi Tjerk,

I am beginning work on condensing the dcarter-ticktockpro skin into 1 css file. Its time consuming but easy and mechanical work for me. I will probably devote some time to do this for the all the skins eventually. I have to admit that while there was nothing incorrect about the current css organisation, I can see how it is kind of imposing a complexity that can be off putting for designers trying to grok mojoportal skinning, especially at first. Your feedback is right on, simpler is better, and if I can provide skin examples that are not complex it should mae it easier for designers to get going with mojoPortal.

Best,

Joe

Hi,

fyi, for the next release I re-organised the css of the included skins.

I combined the stylelayout.css, stylecolors.css, styleborders.css, styleimages.css stylegridview.css using this online tool.

I also renamed some of the other css files to make them sort together in the file system so they are easier to find.

So now the style.config file f included skins looks like this:

<file csswebconfigkey="YUITabCss" imagebasewebconfigkey="YUISkinImagePath">none</file>

<file cssvpath="/ClientScript/oomph/oomph.css" imagebasevpath="/ClientScript/oomph/">none</file>

<file cssvpath="/Data/style/cluetip/jquery.cluetip.css" imagebasevpath="/Data/style/cluetip/">none</file>

<file>style.css</file>

<file>stylemenu.css</file>

<file>styletreeview.css</file>

<file>styleblog.css</file>

<file>styleforum.css</file>

<file>stylefeedmanager.css</file>

<file>styleformwizard.css</file>

<file>stylewebstore.css</file>

<file>styleaspcalendar.css</file>

<file>styledatacalendar.css</file>

style.css is the main file made from the combined ones

Best,

Joe