On Wed, 30 Oct 2019 16:29:31 -0500 Derek Martin <inva...@pizzashack.org> wrote:
> On Wed, Oct 30, 2019 at 11:29:31AM +0000, John Long wrote: > > > I don’t think this is about right and wrong, and not only because > > > there is no objectivity. multipart/alternative is an accepted > > > standard, and so is HTML. You might not like how things have > > > developed, and neither do I, but that doesn’t make it wrong. > > > > HTML is for web pages. It is wrong for email, yes. > > This is just not a supportable position based on anything logical or > evicence-based. HTML in e-mail has been a de-facto standard for about > as long as most people have been using e-mail (admittedly, much less > true for the folks on this list). It has almost universal adoption of > native support in almost every e-mail client of note. Even alpine can > now display HTML mail as plain text natively. Mutt is the only > laggard in this regard that I am aware of. 1. Commonly done != standard. There are standards for things like MIME, POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards that say that HTML email is a thing. SPAM is by far the biggest part of email traffic. Do we say that SPAM is a standard? 2. Mutt hasn't had HTML support and people still chose it. I believe they chose it for simplicity and lightness and being able to run on a console. > A majority of e-mail users PREFER HTML mail. I don't think there is any proof, given 99% of the world uses Microsoft Windows and is non-technical, that this supports the idea anybody knows what peoples' email preferences are. It's much more likely and from my experience, people just use whatever they get. Outhouse is "the standard" in that regard, everybody has it, and the default is HTML email... I suppose this means a majority of PC users prefer Windows? We know the reality is the vast majority of people get it on every piece of Intel hardware they buy, don't know anything else exists, etc. > So I think the notion that HTML mail is wrong is just wrong-headed. I > certainly have no issue if you want to say you hate it, and I would > sympathize. But when you say it's wrong... I think you have no leg to > stand on. Likewise, I think trying to bring proofs from usage statistics that things that just happened (and are mostly targeted at making SPAM and commercial emails "better") are "standards" isn't compelling. > > Lots of Microsoft crap seems like an "accepted standard" > > This has turned out to be remarkably difficult to prove, but I don't > think HTML mail was invented by Microsoft, or predominated by it. > AFAICT MS didn't even support HTML in e-mail until 1998, and I'm > pretty positive Netscape Mail supported it in its first version, > released the same year. I think you are probably right. I was just trying to remember the history as I read your note. At any rate, Microsoft is certainly the biggest offender. > > Simplicity and constantly adding new features that are inessential > > are at odds with each other. > > This is true and should be considered, but not to the point of leaving > the application functionally incomplete. Yes, but people have been adopting and using mutt even when they knew from the beginning it didn't support HTML. There are already enough GUI clients that support HTML, why join the fray? > > I think it's pretty clear the people who use mutt prefer simplicity > > or they would have chosen something else. > > I think this is totally crazy. Mutt is anything but simple, from the > user point of view. It is a beast to configure with a monstrous > learning curve. Part of what gives it that is the requirement to > configure how to handle even things like HTML mail, which today pretty > much no one would exclude from the idea of what is essential e-mail > functionality. Everyone, that is, except a subset of Mutt users. =8^) There are several kinds of simplicity. One is in the UI. Once you set up mutt you don't have to do anything. When you use it you don't need to use a mouse or click buttons or go through pages of UI settings. It's clear what mutt does and doesn't do. It can run on the console without X. For those reasons I consider it simple. /jl
