[Mailman-Developers] Styling patch

[Barry Warsaw]

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

On May 6, 2007, at 5:00 AM, Stephen J. Turnbull wrote:

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

Agreed.

Andrew, when you created the modernize_21_webui branch, did you set  
it up with svnmerge?  I think it would be a good idea to  
systematically merge 2.1 branch changes into the modernize branch.

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

Agreed.  There will definitely be a 2.1.10 (Mark just committed a  
bunch of fixes), but I'm with Guido in hating two-digit point release  
numbers.

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

Would you make $list.css editable by the list admin, a la  
listinfo.html?  Does doing so open any additional security  
vulnerabilities?

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

I don't like being able to upload mm_cfg.py ttw, even if it's just to  
suck a few ui variables out of it.  If we're going to allow ttw  
updating to the css, let's just do that directly instead of going  
through Python code.

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

+1
- -Barry

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

iQCVAwUBRkCMmHEjvBPtnXfVAQIhigP/b837+mCQMIBsmS99dRDSrpeUCsDPTbL3
XlsZYiKBQVu8Xn4EFy0cklu4O/T51zoKHPJmnmVEXhcDLoMsAXlQf6wzOzekOO/P
OJZZi8VPMRTpEteHz34Sx3/4XZF53Xioqoqwn+mxtayA4cykaYjq4+yUOODup9FN
DY7SEKP1xzY=
=/F99
-----END PGP SIGNATURE-----