I agree with you that this is a problem that needs taking care of. Currently the usage of CSS in Rainbow is somewhat disjointed and inefficient. Most certainly, this will be addressed when the overall Layout/Them area is updated, as has been discussed. But in the meantime we must be careful not to introduce any “temporary” solution that may compromise or complicate backward compatibility.
In the long term, the solution lies in the proper usage of two CSS “features”. Firstly, a page sent to a browser can specify multiple stylesheets: there is no need to merge them. Secondly, the inheritance rules of CSS provide a full override mechanism at multiple levels.
Thus if a module appears on a page, it would be a trivial matter to add its CSS stylesheet to the end of a list which is then injected into the HEAD section of the page. That stylesheet could specify attributes for, and therefore override, any identically-named tags in stylesheets above it in the list. Furthermore, that stylesheet could introduce “instance-specific” variations to existing tags without affecting other elements using the same tags on the same page (by using contextual constructions). And even then, the style applied to an element can be overridden by adding CSS attributes to the element itself, i.e. within the module code.
The big problem, as I see it, is maintaining the “one click to change the whole site” capability. In my opinion this is a triviality anyway, but it could be kept if the module-level CSS confines itself to adding or re-specifying spacing/positioning attributes, i.e. the font/size/color attributes are specified higher up the tree.
All of this will be addressed in a future release (I don’t dare say which release!). If someone needs to introduce new solutions ahead of that, I’d be very pleased to discuss specific techniques.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Mark McFarlane
Sent: 28 April 2003 14:01
Cc: Mark McFarlane
Subject: [Rainbowportal-devel] How to support Module specific .css styles
The IBS default.css included a couple of module-specific styles. In designing the discussion module I followed this lead and added 4 new styles. Bad choice !
The fundamental problem with this is that every time a new module introduces new styles they need to be added to ALL existing themes for on-the-fly 'theme switching' to work well. This is a big enough nuisance for Rainbow core developers, but an even bigger problem for external module writers.
So what do we do?
Option 1: Each Module ships with Module.css that is dynamically #included to the current theme's style sheet: - disadvantage is that there is only one Module.css so it might not look right under different themes, and there is a performance hit
Option 2: Strongly discourage modules writers from using custom styles :), make them explain in their readme-help file how to use their styles.
Option 3: Have the ModuleInstall routine copy-insert the module's custom styles into all existing themes. This breaks down when you add a new theme later.
I'm leaning toward option 2, discourage custom module styles, and then insisting that we add a few more base styles to all of our themes, at a minimum TR, and TD !