Re: HTML for email (was: Re: document writing/editing tools used by IETF)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux