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