A.M. Kuchling writes:
I don't think this choice would work very well; requiring a rebuild would break backward compatibility. I don't know if that breakage would be OK for Mailman 2.2 or 3, but it's surely off-limits for a 2.1 point-release.
Going to CSS at all is presumably off-limits for a 2.1 release. I think it would be a very bad idea to constrain the design to be backwards compatible to a non-CSS solution, but not doing so is unfair to people who expect a 2.1 release to be a 2.1 release.
IMO, the point of doing the CSS branch off of 2.1 is so that people who want to experiment with CSS but aren't core Mailman developers can avoid working with experimental distribution code. Sorta like you don't have the plastic surgeon doing a facelift while the orthopedic guy is slicing into your knee. But hoping for a 2.1 release with CSS is just dreaming.
Terri Oda writes:
Use a "style" attribute as well as a "class" one:
- might make conversion from one type of settings to another easier
- just going to look inexplicable and hackish later, potentially make
it more awkward to do CSS-only skins
-1. This is precisely the kind of thing we need to avoid at all costs. You aren't going to decrease the pain of deprecating colors- in-mm_cfg.py by postponing it, so may as well release CSS-only as 2.2 as soon as CSS is ready for release (and have at least one more 2.1 release for those who aren't ready to go to 2.2).
In the transition, I think that we should definitely use the cascade. The multiple class method that Ethan describes is a good way to provide a deprecation path over time as the code matures, although I wonder if it's even necessary. In a different dimension, we probably should have a mailman.css analogous to Defaults.py. Site and list admins never touch this. Then there would be a site.css, analogous to mm_cfg.py, and finally a $list.css for each list, in order of increasing preference. For the sake of virtual hosts, site.css should either be kept in a site-specific folder, or given a site-specific name.
As Ethan points out, these should be "real" files, not inline CSS in the HEAD element generated by the cgi. It should be possible to generate simple site and list stylesheets (eg, changing colors) for the default templates through-the-web, but designers will want to deal with CSS, not Python code. Note that with a little care, the same module that does the t-t-w CSS generation could probably accept an mm_cfg.py and (a) use the variables defined in mm_cfg.py to generate site.css and (b) remove them (warning loudly that setting them in the future will have no effect).
Finally, we could have a check_config script analogous to check_perms, but it would examine mm_cfg.py and the list configs, looking for variables that are deprecated and variables that Mailman doesn't even use, odd values and stuff like that.