Jeroen.. I'm not sure if that's a bad thing to start with.. I think extending the css in the mod itself is a much better option as it provides styling flexibility for each mod independently. As matter of fact, I write my own css for every mod and reference it in the start.php for that mod, and then delete all css relating to it in the core.. So far, no problems.

-Carlos

> Jeroen.. I'm not sure if that's a bad thing to start with..

It is not helpful.

>As matter of fact, I write my own css for every mod and reference it in the start.php for that mod, and then delete all css relating to it in the core.. So far, no problems.

This is pretty much what you need to do. Just to change the default color of the heading elements, you need to copy most of the mods views/default/ to your  mod/<theme>/views/default, just so you can delete the color setting each and  every time it is defined for each and every heading element. It is crazy. Still, I guess I should be grateful the modules don't also define the font used for headings - comic sans all over the place, anyone.

> provides styling flexibility for each mod independently.

They are called 'Cascading Style Sheets' for a reason. Take buttons - if you define a default button class, all elements of class button will inherit the properties. If you want red buttons, you only need to change the .button properties.

If you want to change the properties of an individulal button, you override the defaults using, say, #elgg_topbar .button, or provide an ID in the module for the element. You only need to override the properties you want to change.

As it is, every module seems to define every property of every element. If you want to change the default background color all buttons, you need to find each and every button and change (or delete) the color specified. ditto border radius, padding etc.

Ideally, modules would define their content in a consistant manner so they can be overridden more easily - if all modules used a <div id=module class=contentWrapper, the style could be overridden using #<module>.contentWrapper .button (for all the modules buttons) or a button's ID. Or maybe

elgg has this amazing object heirachy - and I'd love to get into it and see what I can do with it. But I am spending all my time hunting down every #0054A7 ...

@Don
Puleeze believe this...

You ARE barking up the wrong tree !!!

Back up and apologize before..... you piss off a lot of good and **influential people.. you ain't been present here on the ELGG community for quite some time...!!!

Dhrup is right.  It's free software, and if you've done as much work in the CSS as I have, you'll realise it has evolved to where it is, it was not written as so.  As such if you don't like it change it, otherwise put up with it (it's free after all). 

As for cascading styles, each module can add .css sheets to the code stylesheet, so you can just define the ones you want it a single page, and it'll happily override the core styles  to make things work however you want :-)

Hope that helps. 

Simon

I think this could be worth discussing. I've seen a few cases of plugins in the full elgg distribution where the custom styles in each mod are duplicating styles that are set in the core css file. It would be nice to see a more consistent style driven from the core, so someone who isn't a css expert could subtly change the core theme without breaking the overall look and feel. Someone with better css skills probably should be able to handle the additional complication of changing the plugin styles on a more ad-hoc basis.

Although from what i've seen over the last few releases everything is getting better and better

Also one example of fix i've personally made to my theme's css (that overrides the core - that's i've been meaning to send to pete) is:

.input-checkboxes {

    background-color: #252525;

    border-color:#252525;

}

.contentWrapper, .input-checkboxes {

    background-color: #1C1C1C;

    border-color:#1C1C1C;

}

.input-radio {

    background-color: #252525;

    border-color:#252525;

}

.contentWrapper, .input-radio {

    background-color: #1C1C1C;

    border-color:#1C1C1C;

}

This is a small basic change which lets IE6 correctly set the background colour of checkboxes and radio buttons (please don't get me started on how much I dislike IE6, but a lot of my users still use it), but it's just a small example of how small changes & feedback over time can improve consistency for all users.

It looks to me as though the original way of doing things was to have a single css.php file, whereas subsequently that method has evolved to have separate css.php pages for each plugin. What has never happened (by the looks of it) is breaking up the original css.php page, to populate the core plugins. 

I would suggest, with heinsight, that the best option would be to have the core classes in the main css.php page, and each plugin just define the ones that relate to that. 

As an extension of that, there could be more attention paid to inheriting classes from the base, rather than redefining them, so that subsequent changes to the style wouldn't require quite so much work. 

I've attempted to do that in my own copy, by placing PHP variables in various places, then defining them centrally, so that the styles can change quickly and easily, but to do it properly is a lot of work.  If anyone want's to volunteer, great, otherwise I think we just need to ensure new stuff follows the new style and leave the old stuff alone.

Simon

Related trac ticket: https://trac.elgg.org/elgg/ticket/952

I agree with Don. The current core css makes it difficult to write a plugin without writing custom css. There are very few elements that are generic that can be used. This then makes it difficult to write themes since every plugin has it's own css.

I'd like to see the core css at least define a set of primitives and then have plugin authors encouraged to use them.