[Mailman-Developers] Styling patch

[Aaron Crosman]

On 5/6/07 5:00 AM, "Stephen J. Turnbull" <stephen at 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