RE: HTML for email

[Larry Masinter <[e-mail]>]

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 <[e-mail]> On Behalf Of tom petch
> Sent: Monday, March 1, 2021 9:25 AM
> To: Phillip Hallam-Baker <[e-mail]>; Keith Moore
> <[e-mail]>
> Cc: IETF Discussion Mailing List <[e-mail]>
> 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
> > <[e-mail]>
> > 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
> >>
> >>
> >>
> >