On 5/6/07 5:00 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
In general I agree with Ethan and Stephen, designers want CSS to be in its own file (for good reasons) and don't want to have to work in python or XML files if they don't have to. Since we're concerned about maintaining compatibly with 2.1 users that have modified the templates using the current limited options, we shouldn't do a great deal under 2.1. But I think we can do more in 2.1 than Stephen proposes. If we don't edit the HTML content of the existing pages much, we can attach a CSS file that would allow people to do a great deal to customize their sites without needed to worry about breaking old behaviors. Ethen's ideas about how to handle dynamic setting of classes or style sheets might overcome any conflicts that might occur. Even if we didn't go that far, just linking in an empty style-sheet, or creating an option in mm_cfg.py to link your own in would help some users (the user that started the discussion on mailman-users that in turn sparked this conversation was hoping for a feature of that nature). It would leave people in a very hackish position, but at least they wouldn't have to hack the python to do what they want. Certainly adding something simple like that wouldn't cause problems for exiting 2.1 users that don't want to use it.
For 2.2 we could move to better XHTML/CSS design, which would break backward compatibility with old templates. Since it would be a more significant version change that would be acceptable to most people. At that point I think we need to remove all the current python-based settings and move them all into CSS.
If we feel the need to have good through the web support I would suggest for mailman 3.0 we build it in a manner similar to the garland theme in Drupal 5 (which provides a color wheel to select the colors, and then generates a CSS file). You can still edit the CSS directly if you'd like, but it'll do any colorization work for you. I'd also suggest that we avoid putting template links into mm_cfg.py settings, rather use a predefined path like mailman currently does. A theme switcher probably doesn't make sense in Mailman, but being able to change a the look and feel just by updating a CSS file would be a big plus (no restarting mailman). It would be easy enough to define a structure that would allow for CSS files for a given list to live in a particular directory.
Finally I'd like to suggest we avoid using JavaScript until we absolutely have to (a color picker would require it, other ideas might as well), since there isn't any JS in the code base at the moment, and its introduction will add complexity. Also, we'll probably want to find a good library to work with to help set coding standards and allow for some AJAX calls for some elements.
Aaron