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