-----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----- _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
