There's been no interest in the email community for defining a "for email" profile of HTML and multipart/related (or WPACK). Why is that? -- https://LarryMasinter.net https://interlisp.org > -----Original Message----- > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of tom petch > Sent: Monday, March 1, 2021 9:25 AM > To: Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx>; Keith Moore > <moore@xxxxxxxxxxxxxxxxxxxx> > Cc: IETF Discussion Mailing List <ietf@xxxxxxxx> > Subject: Re: HTML for email > > On 01/03/2021 14:22, Phillip Hallam-Baker wrote: > > Yes HTML is a disaster for email. But so is plaintext wrapped at 66 > > characters by the server because people didn't know better. > > > > The reasons HTML is a disaster are > > > > 1) There is no standard for HTML in email. > > 2) HTML has been turned into a presentation format. > > 3) Email messages used annotations for a decade before HTML which > > doesn't support them > > 4) The SMTP email infrastructure does not provide a viable means of > > knowing what formats are accepted by a recipient so there is no way to fix > this. > > And breaks privacy. I find it ironic that the IETF seems to devote forests to > combating a slight possibility of privacy being impaired, something that I see > bordering on an obsession, but actively supports HTML e-mail which drives a > coach and horses through privacy. > > I now find web mail servers which will not let me view e-mail in plain text > (which I assume is because they want to harvest as much personal data from > me as possible). > > Tom Petch > > > > One painful side effect of 1 and 2 is that messages come with embedded > > font size specifiers which is beyond stupid. The sender has no idea > > what device I am reading something on. But Gmail will happily chose > > font size settings that are frequently stupid. I have no control over that as a > user. > > > > But the last point is the most important because the difficulty of > > fixing the SMTP infrastructure has become greater than the difficulty > > of replacing it with something fit for purpose. > > > > Of course the world is not going to move to something new overnight. > > But I do have a plan. > > > > > > > > > > On Mon, Mar 1, 2021 at 12:06 AM Keith Moore > > <moore@xxxxxxxxxxxxxxxxxxxx> > > wrote: > > > >> On 2/27/21 10:00 PM, John Levine wrote: > >> > >>> Indeed, but that was many decades ago. There are some ways in which > >>> the IETF is cutting edge, some in which we are amusingly backward. > >>> Most of the people I deal with can send an e-mail that says "I > >>> highlighted the changes in yellow" and all of their correspondents > >>> see the yellow text. Try that here. Remember that MIME was invented > >>> in the IETF and HTML down the virtual hall from here, both about 30 > years ago. > >> Ok, but to be fair: HTML is a disaster for email. Way back in the > >> mid-1990s most of us thought it would work out ok, and more likely to > >> succeed than text/richtext. But we didn't really take the time to > >> understand the nature of the problem in either case. It's hard to > >> write a good html editor for email, especially one that handles > >> inline replies properly, and every single HTML editor for email I know of > >> botches this. Accidentally delete the line or invisible space before > >> or after a change in format and it's likely to completely mess up > >> your formatting, say by merging one correspondent's text with > >> another. HTML doesn't handle annotations well either because (gasp) > >> text messages are not naturally hierarchical like HTML (and its *ML > predecessors) expect > >> them to be. HTML hasn't exactly been a stable target either, and > >> there's lots of variation among MUAs regarding which features are > >> supported. It's hard to send an email message that looks more-or-less > >> the same to every recipient. > >> > >> (And, IMO unfortunately, a lot of MUAs take liberties with > >> presentation of email messages, which only exacerbates the above > >> problems.) > >> > >> At the same time HTML is so widely deployed that it's very hard to > >> deploy something that works better. > >> > >> The specific behavior you cite above is actually due to a failure of > >> standardization, because the vast majority of Big Corporate environments > >> have settled on 1 of about 2 email products overall. Highlighting text > >> in yellow doesn't work as well in IETF because IETF participants are > >> (fortunately) still more diverse than Big Corporate employees. > >> > >> Keith > >> > >> > >> > >
