Terri Oda wrote, On 05/05/2007 05:24 PM:

...

It presents one big compatibility issue that will probably need to be fixed. The patch removes the colour settings (WEB_HEADER_COLOR, WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) and replaces them with CSS class declarations.

It's probably unacceptable to break the use of these settings, so there needs to be some compatibility fix. Colours could be substituted into the .css file somehow, or a 'style' attribute could be added as well as a 'class' attribute. Does anyone have suggestions for what to do?

Some thoughts with positive (+) and negative (-) notes:

Have the CSS generated by a CGI (which could then use these variables
if they're available).

• extra processing for each web request

• could lay groundwork to make it possible to change settings on a
  per-list (or per virt-domain) basis rather than site-wide.

Perhaps that part of the CSS could be included inline in the already cgi-generated html header. It will probably only be a couple of lines. If placed before inclusion of custom css then customizers can override it if they want to. (That would be very close to how it is done in Plone.)

IMHO that addresses the only minus of this solution.

Just a thought...

/Mads

A.M. Kuchling wrote:

On Sat, May 05, 2007 at 11:24:27AM -0400, Terri Oda wrote:

...

Have the CSS generated by a CGI (which could then use these variables
if they're available).

• extra processing for each web request

• could lay groundwork to make it possible to change settings on a
  per-list (or per virt-domain) basis rather than site-wide.

The extra processing may not be too bad if we set an Expires: header on the CSS output. I imagine most crawlers, well- or badly-behaved, don't crawl the stylesheet linked from HTML pages.

I do not think this is a good idea. It is better to have a CSS file that just declares the colors and then use those definitions elsewhere. Backward compatibility would involve reading the color definitions from mm_cfg, deleting them from the config, and writing them into the css file.

There are very few good reasons to put dynamic markup in CSS. Designers are very comfortable with CSS files. Having to edit a python file to set colors is very much out of their comfort zone.

It is possible to have multiple classes per element, eg class="aLegacyClass aClass". This has excellent support across browsers. Changing this list dynamically is the best way to change styles "in code".

Any time we need multiple style-states for one element, we should have multiple classes. If the set of states exceeds that which should reasonably be typed out - like the location if one is allowing dynamic dragging- then the style manipulations should be achieved by javascript that may be partially dynamically generated or better by static javascript that gets whatever server data it needs via JSON.

...

Use a "style" attribute as well as a "class" one:

We should never use the style attribute if we can at all avoid it, as there is no (easy) way for a CSS stylesheet to override the style attribute. The exception is manipulating element.style in javascript.

~ethan

On 5/6/07 5:00 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

A.M. Kuchling writes:

...

I don't think this choice would work very well; requiring a rebuild would break backward compatibility. I don't know if that breakage would be OK for Mailman 2.2 or 3, but it's surely off-limits for a 2.1 point-release.

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.

IMO, the point of doing the CSS branch off of 2.1 is so that people who want to experiment with CSS but aren't core Mailman developers can avoid working with experimental distribution code. Sorta like you don't have the plastic surgeon doing a facelift while the orthopedic guy is slicing into your knee. But hoping for a 2.1 release with CSS is just dreaming.

...

Terri Oda writes:

...

...

Use a "style" attribute as well as a "class" one:

• might make conversion from one type of settings to another easier

• just going to look inexplicable and hackish later, potentially make it more awkward to do CSS-only skins

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

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.

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

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.

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. If we don't edit the HTML content of the existing pages much, we can attach a CSS file that would allow people to do a great deal to customize their sites without needed to worry about breaking old behaviors. Ethen's ideas about how to handle dynamic setting of classes or style sheets might overcome any conflicts that might occur. Even if we didn't go that far, just linking in an empty style-sheet, or creating an option in mm_cfg.py to link your own in would help some users (the user that started the discussion on mailman-users that in turn sparked this conversation was hoping for a feature of that nature). It would leave people in a very hackish position, but at least they wouldn't have to hack the python to do what they want. Certainly adding something simple like that wouldn't cause problems for exiting 2.1 users that don't want to use it.

For 2.2 we could move to better XHTML/CSS design, which would break backward compatibility with old templates. Since it would be a more significant version change that would be acceptable to most people. At that point I think we need to remove all the current python-based settings and move them all into CSS.

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.

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.

Aaron

On Tue, May 08, 2007 at 11:06:14AM -0400, Barry Warsaw wrote:

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.

I have an idea for a proposed conservative approach for 2.1:

• Add two mm_cfg settings: CSS_FILES and JS_FILES, while are lists (alternatively, whitespace-separated strings):

  CSS_FILES = ['/css/mailman.css', '/css/custom.css'] JS_FILES = ['/js/switcher.js', '/js/foo.js']

• Make generated HTML pages contain <link rel=stylesheet> for each of the CSS files, and <script src='<js file>'> for each JS file.

• Wrap the body of Mailman-generated pages in <div id="mailman">...</div>.

That's it.

This lets people apply CSS and JS customizations to all of Mailman's pages, and the #mailman lets them include MM-specific CSS directives without breaking their existing CSS. JS files are included because people might use them for style switching. Mailman still wouldn't use any JS itself.

Possibly we could apply the portion of the patch that generates tags like <br /> instead of <br>, but since we wouldn't be adding a DOCTYPE to the pages, it wouldn't have much effect. Doing <br /> would make life easier for people including MM-generated HTML within an XHTML page, but I doubt very many people do that.

For 2.2, add:

• Restructure HTML to use semantic markup and CSS instead of tables.

• Add a DOCTYPE to the HTML output and check for validity. Hand-written HTML in list configs. might break validity; IMHO that shouldn't be our problem to fix. We might choose HTML 4.01 validity to avoid imposing XHTML correctness on such hand-written text.

• If the MM developers are OK with taking out the WEB_*_COLOR config settings, remove them with no concern for compatibility.

• Install a static mailman.css file.

Or we can do the conservative approach for 2.2 and the larger rewrite for 3.0.

--amk

...

  CSS_FILES = ['/css/mailman.css', '/css/custom.css']
  JS_FILES = ['/js/switcher.js', '/js/foo.js']

I like it too. And we can do marvels with jQuery.

-- Fil

Ethan Fremen wrote:

For pages that are "generated" rather than hand-edited, I propose we use this doctype as of 2.2:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

And with 3.0 I would like to see the following:

• All pages served as xhtml strict with Content-type: application/xhtml+xml . This is "problematic" in that you lose document.write() in javascript but beneficial in that you actually get an infoset (meaning you can mix, eg, MathML and XHTML or XHTML and SVG.) (Maybe with a little helper function that checks included JS for deprecated member access.)

• All through-the-web editing using some wysiwyg editor like Kupu, with fallback plain-text editing and handholding well-formedness checks.

• Serve non ttw pages via webdav with "source port" or "source path" if necessary.

• Deprecate CSS_FILES & JS_FILES in favor of whatever our dynamic templates say.

Now that I think about it, I think I would prefer having a HEAD_HTML variable that is a string or one-line-per-list-element variable in 2.2 that had the <link> and <style> elements written out in order to make deprecation easier, and to support all the spiffy oddness one might want to put in the head element.

~ethan

Barry Warsaw writes:

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

Yes to editable, I don't know to security vulnerabilities. View the CSS Zen Garden (better yet, get the book), and know fear. What those people manage to do without ever changing a tag is amazing!

Since CSS is intended to be purely presentational, the two threats I can see are hiding evil that they sneak in some other way, and "social engineering" via misdirection. Eg, I can image some mischief where you swap the labels of the "Cancel" and "Submit" buttons via CSS.

...

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.

Sorry, my wording was *very* imprecise. What I had in mind was that the ttw CSS generating <FORM> in HTML will give you KEY=VALUE pairs, which is what mm_cfg.py is. So the logic for generating CSS would be the same. The UIs would be completely separate. ttw would go via one or more HTML forms. The "import mm_cfg" inteface would only be available via the shell, that would not be available ttw.

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

On May 5, 2007, at 11:24 AM, Terri Oda wrote:

Have the CSS generated by a CGI (which could then use these variables if they're available).

• extra processing for each web request

• could lay groundwork to make it possible to change settings on a per-list (or per virt-domain) basis rather than site-wide.

Use a Makefile to generate the CSS once from this file (and leave note in file saying that further config is in CSS)

• processing happens once

• can't be applied easily as a patch, requires an actual rebuild to take effect

Use a "style" attribute as well as a "class" one:

• might make conversion from one type of settings to another easier

• just going to look inexplicable and hackish later, potentially make it more awkward to do CSS-only skins

Mailman trunk already has a wsgi based server of its own. It's my
intention to deploy it without the (traditional) cgi scripts. By
default Mailman would simply provide its own simple web server, but
be compatible with wsgi for alternative publishing options.

• -Barry

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

iQCVAwUBRkCASnEjvBPtnXfVAQLhXwQAk1iamo4BCATpDX0nSO1fdayzPO8pif1G dYXhy+Pmea0g5/QPrUK8Yk4lcrwCZX7Tf/ggmV2g02jVdGwD+t/ST1nz/mjwa/ws w4RM99BaR+cXRiJshUJ7DoHs//5ihC7wPKiH/mcCnhJMfhJR5kWqkpqNLpQkAcXx g12dn0NBbbE= =4XyB -----END PGP SIGNATURE-----