On 2010-02-17 11:15 AM, Mark Sapiro wrote: >> 3. When replying to a message, preserve the message subject *and* all of >> the individual message references so that replying to messages from >> the HTML digests doesn't break threading - basically so it looks as >> if it was replied to individually and separately, not from the list >> digest.
> Current Mailman MIME format digests do this if the user's MUA supports > it. Ok, I switched to MIME digest for the users list for a better understanding of what is supposed to be happening. Currently, the MIME digest is a plain text message, and I don't see any way to reply to an individual message, much less preserve the message subject I'm replying to - unless you mean I'm supposed to actually open the message I want to reply to in a separate window, then click Reply? If so, that's not what I'm talking about... the title of this feature request is 'Interactive HTML Digests'... meaning, I'm asking for a 3rd choice for the option: 'When receiving digests, which format is default?' [ ] Plain [ ] MIME [ ] Interactive HTML Where the HTML digest supports (as many as possible of) the features described in my request... Note: in general, I don't like HTML email, but for digests, if what I'm describing can be even partly accomplished, I think it would be a 'good use' of HTML email... >> Also - I use Thunderbird, and when I click Yahoos 'Reply to Group', it >> does 2 things wrong, but I don't know if MM could do anything about this >> or if it would be a Thunderbird issue: > There's an inherent difficulty in what you propose. I suspect it is > the reason why quoting doesn't work with TBird and Yahoo digests. > > Your points 1 and 2 imply that the digest must be a single HTML part. Correct... > Thus, a reply of some sort button is really a mailto: link which in > Yahoo's case, probably has a query fragment with "Subject=..." and > could additionally have query fragments for "In-Reply-To=..." and > "References=...". This mechanism could also support "fixed" quoting of > the entire message with a "body=..." fragment, but quoting selected > text would require some kind of scripting. > > My point is that MUAs aren't web browsers, and all this would depend > heavily on on features that are not supported uniformly if at all in > MUAs. I'd be happy to attach one of Yahoos digests if you or anyone else was inclined to take a peek at just what it does... Most MUAs can render HTML email messages fine. Of course, I understand they aren't 'browsers', so whatever code that was used would have to be an extremely limited subset that should work in most email clients capable of rendering HTML emails. >> 1) it uses the email clients 'default account' instead of the account >> the user is in - so, if you just type something and click 'Send', >> it is sent from the wrong account and will bounce since the email >> address for that account is not a list/group member, and > This is a TBird issue. I know, but I guess I should have said '... if it would be *strictly* a TB issue ...'... The bigger question is, is there anything sane that MM3 could do to work around such limitations using HTML code in most/all mail clients if an interactive HTML version of the digests was implemented? >> 2) Thunderbird's new 'Quote only selected text' doesn't work - in fact, >> *nothing* is quoted. This issue is not as big as the first one, >> since it can be worked around by simply copying the highlighted >> text (more often than not I select text to quote rather than >> quoting the whole thing) then 'pasting as quote'. Two more steps - >> not that big a deal, but hey, if it can be coded to use the Clients >> features, all the better. > Works for me with Tbird 3.0.1 and Mailman MIME digests and "Reply" or > "Reply All". "Reply List" is not offerred for a reply to a message > from the MIME digest, because there is no List-Post: header in the > individual message parts I'm curious why? If I had received the message individually, there would have been, so why not include them in messages in the digest? > My personal feeling is that if things can be done in a way that works > reasonably in MUAs that don't support the features, then it might be > feasable, but if something works with one MUA and is a disaster in > another, it is better not done. I hope you aren't suggesting that Mailman should limit its features to the 'least common denominator'... I don't see anything wrong with *optionally* supporting advanced features of modern mail clients. > Certainly, this kind of HTML digest would have to be optional. But of course... and absolutely not the default. -- Charles _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org 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
