On 2010-02-23 4:52 AM, Stephen J. Turnbull wrote: > Tanstaafl writes: >> Stephen J. Turnbull wrote: >>> "Simple" HTML simply doesn't lend itself to "encapsulating" >>> structured documents, except with devices like frames.
>> All I mean by 'simple' is simple enough that most mail clients >> capable of rendering HTML email won't have a problem with it, and >> the fact is, most can render fairly complex HTML. > My turn to *sigh*. I *know* what you mean. I am telling you that in > my opinion it will require quite a bit of effort to write a program > (or Mailman function) to create HTML that does the job for a wide > enough selection of MUAs. You also seem to be missing the fact that I've already said I didn't expect (hoped? maybe) that *all* of these features would be implementable, and certainly not immediately. I didn't actually come out and say it, but what I was asking for was just the framework... So how about this... 1. Create the new Digest format, but only add the very-most-basic features that can easily be added... like, for example, make the messages in the message summary hyperlinks that scroll down to the message, and add 'back to top' links at the top/bottom of each message. If some basic Reply mailto links could be added that maybe simply grabbed the subject, that would be a bonus, but not necessary. Maybe it would also be possible to mimic the google 'threaded' digest feature, where each thread is grouped in the digest (based on the date of the first post), *but* only the first post of the thread has an entry in the message summary at the top, with a [##] in parenthesis denoting how many messages exist for that thread. This keeps the message summary much shorter and more manageable, especially for high volume lists. Also, maybe peeking at the message source for one of the Yahoo and Google Digests could make this easier... 2. Make it template based, so as to be easily modifiable by the MM admin. This way, if some HTML magician comes along and likes the concept, they could not only easily do so, but could also easily contribute their changes to the community once they have been confirmed to work in most MUAs that render HTML emails. Obviously, there would also have to be a back-end function that manipulates the individual messages that the MM admin can also play with, but I don't see this as a real problem as long as that function only affects the hmtl digest, and doesn't mess with any other MM functions or does nothing more than read in the individual messages for manipulation for the digest. > I'm not going to work on it myself, because I don't think the benefit > (to others)/cost (to me) ratio is anywhere near high enough. That's > mostly because I see supporting this feature as an unending time sink > for the next 5 years, because HTML is just not intended to be used for > this purpose. I'd argue that HTML support in mail clients will only get better over time, making adding new features easier and more manageable... > So far, I think Mark agrees. Well, I wouldn't presume to speak for Mark, but I the more complex features, like the Reply links and not breaking threading > I'm not going to work on it myself, because I don't think the benefit > (to others)/cost (to me) ratio is anywhere near high enough. That's > mostly because I see supporting this feature as an unending time sink > for the next 5 years, because HTML is just not intended to be used > for this purpose. Well, no offense, but by that argument, we'd all still be in flintstones vehicles, because the concept of 'the wheel' was never intended to be used in an internal combustion engine - until it was. ;) -- Charles _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 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://wiki.list.org/x/QIA9
