[Mailman-Developers] Styling patch

[Stephen J. Turnbull]

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.