[Mailman-Developers] Styling patch

[Ethan Fremen]

A.M. Kuchling wrote:
> On Sat, May 05, 2007 at 11:24:27AM -0400, Terri Oda wrote:
>> Have the CSS generated by a CGI (which could then use these variables  
>> if they're available).
>> - extra processing for each web request
>> + could lay groundwork to make it possible to change settings on a  
>> per-list (or per virt-domain) basis rather than site-wide.
> 
> The extra processing may not be too bad if we set an Expires: header
> on the CSS output.  I imagine most crawlers, well- or badly-behaved,
> don't crawl the stylesheet linked from HTML pages.

I do not think this is a good idea. It is better to have a CSS file that 
just declares the colors and then use those definitions elsewhere. 
Backward compatibility would involve reading the color definitions from 
mm_cfg, deleting them from the config, and writing them into the css file.

There are very few good reasons to put dynamic markup in CSS. Designers 
are very comfortable with CSS files. Having to edit a python file to set 
colors is very much out of their comfort zone.

It is possible to have multiple classes per element, eg 
class="aLegacyClass aClass". This has excellent support across browsers. 
Changing this list dynamically is the best way to change styles "in code".

Any time we need multiple style-states for one element, we should have 
multiple classes. If the set of states exceeds that which should 
reasonably be typed out - like the location if one is allowing dynamic 
dragging- then the style manipulations should be achieved by javascript 
that may be partially dynamically generated or better by static 
javascript that gets whatever server data it needs via JSON.

>> Use a "style" attribute as well as a "class" one:

We should never use the style attribute if we can at all avoid it, as 
there is no (easy) way for a CSS stylesheet to override the style 
attribute. The exception is manipulating element.style in javascript.

~ethan