"Woodrick, Ed" <firstname.lastname@example.org> wrote:
> I don't mind intelligent responses. But I hate ones like this.
Very nice. Trust me, this thread isn't winning any prizes so far. I have
been managing lists for a loooong time, so you might show some respect.
> HTML and
> Digests have nothing to do with each other.
One might wish this were so, but HTML is a distinct MIME type for describing
documents, while Digests conflate messages into one omnibus, so MIME types
like HTML become a problem.
> The problem is that
> your digest
> process doesn't understand HTML If it did, there would be no problem.
And the problem with this, O connoisseur of "intelligent responses," is that
the "digest process" isn't _mine_, it resides on the Majordomo server
machine (in this case Greatcircle.com, but in the cases of the lists run by
members here, many other machines worldwide). Majordomo in its present form
simply doesn't understand or handle HTML and binary stuff in a useful way
come Digest time.
We can imagine several ways to do it, with multiparts and so on, and the
programming folks over at majordomo-workers discuss this every week, but (a)
it's a big controversy because nobody is quite sure whether members really
want to get a basket of individually-openable attachments instead of their
friendly old text Digests; and (b) regardless of how that issue gets
decided, the _existing_ Majordomo installations -- the ones that
List-Managers members are here to discuss running, remember? -- mostly don't
do any of these future things. HTML and binary attachments just look like
HASH in Digests from real-world servers.
Every list administrator on a list that has a Digest form should make sure
she or he receives both the Digest and individual messages, so as to be
aware of potential problems.
And I urge list admins not to accept the lazy, blinkered logic of the "get a
real MUA" people who want to blame readers first. Our responsibility is to
serve our readers - to make it as easy as possible for as many people as
possible to enjoy the core content of the lists we offer. Where that
content is logically text-based, as is true for most lists, we should
standardize around text until widely available list processors offering a
CHOICE of more enriched formats, for interested readers, is available.