[MlMt] forwarding HTML emails

[Bill Cole]

On 17 Jan 2018, at 15:21, Tracy Valleau wrote:

> HTML email is a few headers and HTML content. It is not any more 
> complex than a web page, basically.

Yes. And to embed a full HTML page in another requires the use of 
features like FRAME or IFRAME, both of which have limited support in 
MUAs for good reasons.

The alternative is what TBird does: put a full-blown WYSIWYG(ish) HTML 
renderer and HTML editor/composer into the MUA, import the original 
HTML, figure out how to tack on a reasonable rendering of headers above 
the original body with your own styling that doesn't collide with the 
original message's styling, construct a visual separator to give the 
user a safe place to add comment above that and if the user decides to 
do any sort of internal edits on the original message, hope that your 
editor/composer can properly parse and restructure whatever the 
editor/composer of the original HTML provided without botching it.

> The issue is that when forwarding, MM strips out all the HTML code. 
> Try viewing the source of an HTML email and you'll see what I mean.

Looks to me like inline forwarding just forwards the raw HTML of a 
HTML-only message, making it a total wreck. Probably something about my 
settings...

> My point is that the original source is IN the email,  else I'd not 
> see it all prettified, eh? So it's there.

And MM doesn't actually do the rendering of the HTML. That's all done by 
WebKit.

> Why not "just" forward ALL that original source? The head, the tables, 
> the divs, the body... That way  the recipient would see what I see.

"Redirect" does just that.

If you want something like what fully HTML-aware MUAs do (i.e. a 
rendered original message including a pretty form of the useful headers, 
a separator, and an area for you to add your commentary) you need a full 
HTML editor/composer. MM has no such thing. It generates de novo HTML by 
way of a Markdown interpreter, it passes along unmodified HTML by 
redirection or attachment of an HTML message, never modifying the HTML.

> I can understand not doing it for "political" reasons ("all email 
> should be text"). What I don't understand is why it isn't an option. 
> Mail can do it; Outlook can do it; Thunderbird can do it; PostBox can 
> do it...
>
> As a programmer with over 40 years of experience, I -can- understand 
> boxing one's self in to a point at which integrating the capability is 
> a huge amount of work. That would be a legitimate reason for not 
> offering it (albeit unfortunate.)

My understanding (I hope Benny will correct me if I'm wrong) is that 
adding this to MM would require a lot of work because the HTML 
capabilities MM has are largely outsourced to the OS and the embedded 
Markdown interpreter.

> But from a USER perspective, not being able to "just forward" HTML 
> email is odd, and from a recipient's standpoint... well in my 4 
> decades, I've -never- received an email that said "to see the html 
> version, click on the attachment."

That's a recipient MUA issue. Both MM and TBird render attached messages 
inline, as does GMail webmail. Apple Mail shows an attachment, iCloud 
webmail shows no hint of anything unless you download the message (i.e. 
shoddy...) It's been a long time since I've used Outlook, but to the 
best of my recollection it also shows attached emails inline.

My point is that I don't see how this is a serious problem. Different 
MUAs always have rendered and always will render anything more complex 
than plain pure-ASCII text with lines shorter than 64 characters in 
different ways. They've always done "inline" forwarding in variant ways.