[Mailman-Developers] Styling patch

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 8, 2007, at 9:16 AM, Aaron Crosman wrote:

> 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.

I'm not so sure.  I feel very uncomfortable making /any/ non-bug-fix  
changes to 2.1, perhaps even limiting them to critical bug fixes that  
address security or reliability issues.  Better (IMO) to fairly  
quickly get a conservative 2.2 out sooner, along the lines I  
described in an earlier message.

> 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.

For MM3.0, we should use the 80/20 rule.  IOW what /out of the box/  
will give most people the best value without complicating the code,  
or our security or reliability story?  Keep in mind use cases like  
cPanel where people will not have shell access.  In that case,  
allowing for CSS editing t-t-w seems like a reasonably powerful and  
safe trade-off.  More intensive web page editing, I'm not so sure.   
The other thing to keep in mind is that MM3.0 will be modular enough  
that people could build more extensive integrations with true content  
management systems or t-t-w editing environments.

> 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.

Our basic design requirement here has been that JS is okay in the  
default u/i as long as the usability degrades gracefully when it is  
not enabled (either because the site disables it or the browser has).

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRkCR53EjvBPtnXfVAQKgcQP9HpB9BLbBHYoe4aMGINZCL5iO1whYIQKg
uS1G3cGMOjYyBkt5jc7a5N9/jKkmrLU8BJ++yBZXBzvxFEbOn3rlSatpnvQ9Kh6+
cXrQJhpqhJgVYuNpNQSu/RjGVTYYMCOghzKigxjLcpgs+m2n7Wizkly4PsObPR6j
vzq/gP+5YmA=
=7nhD
-----END PGP SIGNATURE-----