Hacker News Reader

Comment by AdamH12113 | Hacker News Reader

> HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place. The few advantages they offer for end-users, such as links, inline images, and bold or italic text, aren't worth the trade-off.

Inline images are a huge, huge advantage, especially for internal business communications where an email may be the only real documentation of a problem and its solution. (Or at least the only documentation that can stand on its own -- the alternative is usually a PowerPoint deck with missing information that was only given in a one-time presentation.) Being able to add a graph or a table or a schematic or a photo is important for anyone who works with non-text data. I suspect some programmers may be unaware of how unusual it is to work entirely in text.

View on HN

Maybe emails shouldn't be primary documentation. They were never designed for that, and shoehorning them into that role has ruined the entire experience.

For example, my workplace no longer allows forwarding or IMAP access because of this, so I'm forced to use the sh*tty Outlook web client, which wastes untold numbers of minutes each day waiting on the damn thing to load something. Just now it wouldn't let me open a PDF in a native client, because I guess Microsoft is so obsessed with locking us into their ecosystem. Instead I had to save it to disk first then go to the file manager to load it. (Yo, MSFT, this is why people hate you.)

I strongly agree, but good luck pushing that idea in your nearest large corporation. The lack of concern for communication and record-keeping I've seen in my career is simply appalling. Simple things like minimal proofreading are treated like pulling teeth, and heaven forbid someone rename a file so you can actually tell what's in it. At least an email is a proper written document, unlike the half-assed PowerPoint slides I usually see.

Try Davmail, bit slow, but better than nothing

I agree that there are better ways to keep things documented. Any fix communicated over email might as well include (or even better only include) a link to the actual documentation wherever it actually belongs, but that's a terrible reason to abandon IMAP and force people to use Outlook. It's so terrible a reason it's hard to imagine that was their only one. I imagine most companies are more worried about leaks or compromised email accounts than about documentation ending up saved in email only.

> [...] that's a terrible reason to abandon IMAP and force people to use Outlook. It's so terrible a reason it's hard to imagine that was their only one.

Strange... IMAP isn't the opposite of Outlook. And using IMAP-based email client keeping data locally is a better choice than to use webmail and to rely on email storage services of mail provider.

Yeah, even if outlook manages to stay online the vast majority of the time having a local backup is extremely useful. I use IMAP with Thunderbird which stores mail in MBOX format which I find very helpful for searching or pulling data from too. Having to depend on webmail would feel so limiting!

Those things you mentioned are a-ok, but including a photo in the email signature really bugs me. There are times when I want to look for emails with an attachment, but often the company logo in the signature causes false hits.

What really bothers me is when someone copy and pastes something they've written in MS Word into their email and turning the email into HTML without even noticing. What's even worse is when people bump up the font size of the entire email body because they think since their email client has a small default font size it must be the same for everyone else, I've seen tech CTO's do this to, sometimes you wonder what the technical chops for a position like that really is.

One nasty thing that Word does in this situation is to effectively convert any included jpegs into pngs. That cute little pic you included as a header is now 800k when it hits the email list.

Yeah, rich-text copy and paste is pretty awful. The default in almost all cases should be "paste without formatting", but instead you have to go out of your way to exclude formatting.

I was so happy when I figured that chrome based browsers now have a "Paste as plain text" functionality. I receive technical problem descriptions in (of course) HTML email formats, and copy pasting them into the archive systems web interface (which ofc is also rich text based) always was a PITA.

This has been bugging me more and more recently - the assumption that if I've copied a few words from one app then pasted it into another it means I want to preserve all the formatting is wrong 99% of the time, yet there are now popular web-based apps (Confluence being one example from memory) that don't even support "paste as plain text". Actually what I typically want is "smart paste" which implies preserving changes in the formatting, and supporting e.g. hyperlinks etc., but ignoring whatever formatting attributes happened to be active at the beginning of the selection. But I'd rather lose support for rich text paste entirely over the situation we have now.

Agreed. I typically copy whatever text and paste it in the address bar and copy it again to lose the formatting. It also loses any line breaks but still worth it.

I keep a simple text editor open to accomplish that with. You keep line breaks that way.

That's my usual trick too but it's a terrible hack. Windows in general (I don't think MacOS is better) is crying out for more sophisticated built-in clipboard support, including supporting multiple active items (3's probably sufficient), and better conversion/formatting options (even to the point of automatic OCR etc.).

Ctrl+shift+v works most places to paste without formatting.

You can send a plain text with attachments? That's how I used to do it (1996-2022)

I think the keyword there is "inline."

Many e-mail clients display the photos attached to plain text e-mail messages as "inline", you do not need a HTML message for that.

So how do I put text between them?

For that I think you have to use text/html so that you can reference the inline image's Content-ID. The rest of the 'HTML' could be plaintext of course, just needed for the <img>. You could also have related text/plain and text/html only for wherever you need the image - but support of that is probably even patchier than inline attachments.

Send your formatted document with embedded images as an attachment.

You could even send it as an HTML document, and if your email client supports it, it could display the document right in the client!

While this is something that I do not remember using, because I typically attach all the pictures at the end of the message, all the e-mail clients that I have used have 2 menu options while composing a plain text message: "Insert file" and "Attach file".

I believe that "Insert file" should insert a picture in the middle of the plain text, unlike "Attach file".

Images can just be added as attachments however, they don't have to be inline. Many GUI mailbrowsers can display them as previews. If for some reason they are absolutely required to be inline of text, its easier on the recipient of the message, if the document is composed as a separate file (pdf or whatever), and sent as attachment.

I remember that it was possible to insert inline images in a plain text email by adding a uuencoded block in the middle of the message. MIME also had inline attachments, but those typically show up at the end of the message.

In pouring over the relevant RFCs fairly recently in order to implement my own client, I learnt (though didn't implement - raised a not implement exception, and I've yet to receive exceptional mail) that you don't actually need HTML for inline images.

Tl;dr a multipart message can include an image with an inline 'content disposition'. It's intended that clients show it inline, but I suspect many don't. Like I said I haven't received any yet anyway, so it's probably not that consequential.

Another quirk I'm aware of, by implementing my client quite unforgivingly, is that many emails are structured with the attachments only 'tied' to one alternative, often the text/plain media type, so if you interpret the parsed tree structure of alternatives/attachments literally, the HTML-formatted message might refer to an attachment (I mean a PDF say, not an embedded image) that's actually only available on the plaintext version. Having never encountered this before, I'm pretty sure other clients (like Gmail, Fastmail) present all found attachments alongside whichever alternative is viewed, not taking the actual email too literally (as I presently do).

Reply on news.ycombinator.com