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