Hacker News Reader

Comment by jve | Hacker News Reader

> Rich text features desirable for end users include things like inline images, bold or italicized text, and so on. However, the tradeoff isn't worth it. Images can simply be attached to your email, and you can employ things like asterisks, /slashes/, _underscores_, or UPPERCASE for emphasis.

Well, why bother writing his own post in rich text then? He has headings, bold, links, grey font at the bottom, image.

Don't get me wrong - for high security systems/environments, plaintext is way to go. For everyday life use cases I prefer html. Although with Markdown rendered text I would be pretty happy. And enough for author to cover his post sans the green/red boxes and grey text.

View on HN

The page footer might interest you. It directly answers your question.

Quoting

  "But if plaintext is so good, why is this page written in HTML?" 
  This is a reference document, not an email, you twit.

Fair. I like that minimal formatting there anyway.

But often I have to communicate via email, report on complex issues, etc. It is nice to have some headings, tables, images in there.

Agreed. As much as I like plain text email personally, having inline images etc. is really helpful sometimes.

The key is sometimes. Plain text by default, rich text when required.

Software that would strip all html out of emails for security would be handy

Before MIME was common, people used to insert uuencoded data within the email message. IIRC, certain email clients would display the decoded content inline with the surrounding text.

Why not use MS Word or some other tool designed for writing documents then ?

But emails can be reference documents too! In fact I would argue most work emails that are longer than a few lines are a reference document of some sort.

Then you are better off using some format that can stand alone as a file such as PDF. If it is a reference document that is intended to be edited on an ongoing basis it is better to use something like a wiki. Having to root around in your email to find a reference document is pretty inefficient and annoying.

All of the reasons given against HTML emails hold at least equally well against PDF: it's a vector for phishing and tracking, ripe with client vulnerabilities, less accessible and not displayable on a terminal. For me as a reader having to read both an E-Mail and the attached PDF is also annoying, and many people will simply skip reading the PDF.

> For me as a reader having to read both an E-Mail and the attached PDF is also annoying, and many people will simply skip reading the PDF.

See also embedding (e.g.) a JPEG in a Word document and then attaching that Word document to an e-mail.

I've seen so many Word or PPT documents with a single hyperlink in them, uploaded to SharePoint with filenames like "process_manual_2013_v3.2.doc"...

Ugh.

Just ran across this: an HTML e-mail that is only a link (i.e., HTML <head> refresh):

* https://old.reddit.com/r/sysadmin/comments/ch83sz/why_the_he...

If you have an employee generating phishing and tracking reference PDFs in your organization then you really have a personnel problem.

We send syntax highlighted code all the time via email at my job. I hope you're not suggesting we should use PDF instead?

And no, creating snippets on a wiki is also an extra unnecessary step. Email is just easier and faster.

Syntax highlighted code can hardly be considered a "reference document".

For the life of me I can’t remember the syntax for a particular thing I do in the JavaScript console at work. Someone showed me the trick in an email about seven years ago and about once a month I need to do this thing so I search my inbox for the email so I can remember the syntax.

It might be "easier and faster" to send an email than to, for instance, upload to a dedicated snippet manager, but literally everything after than that is slower and more difficult.

why not let people syntax highlight the way they want? some people dislike syntax highlighting, some like high contrast highlighting, some like blue-tinted highlighting, etc. why do you get to decide for everyone what colour strings should be?

send the plaintext code snippet and they'll decide.

And if its a reference document it should be in source control and properly versioned - not to go all BS5750/ISO 9000 here :-)

Exactly, work mailboxes are a treasure trove of automatically-archived information. I'd argue that these days, emails form more of a "knowledge base" than any other single repository of information for most organisations.

This is very true and yet the search tools supplied with these knowledge bases are terribly inadequate. Is there a better, standalone tool out there for turning email archives, from multiple sources, into a usable database with a powerful query language?

Not sure if that's what you're looking for, but you could use notmuch[0]. Haven't used it a lot, but I think it can import an mbox? Maybe you can merge multiple mboxes together?

[0]: https://notmuchmail.org

I looked into that a few times, just haven't had the patience to get through the setup process. Maybe I'll get it done this time. There goes my afternoon :)

7 hours later: Now I remember why I never got it running, it's an impossible task to accomplish.

https://www.fwdeveryone.com

No query language yet, but you can export the cleaned up email threads and then query them however you want.

I was keeping an eye on this in the hope that someone had a good answer for it. What features would you consider adequate for this kind of email search? At the moment I just have everything in Thunderbird and it does a passable full-text search on a ~5gb mailbox but I haven't experimented with anything fancier.

email is a terrible place to keep reference documents.

"where's the information on that?" "oh, you should have it in your email somewhere. I think I got one a few months ago about it"

no. just. no. If you care _at all_ about your reference documents you get them out of email ASAP.

And that's ignoring that anyone can delete old emails and thus not have what you considered a reference doc but they just considered old mail. Or that the server could loose your emails and no-one has they synced locally these days.

> email is a terrible place to keep reference documents.

Newsgroups are better in that regard. You can reference the message using the message-id value. A lot of newsgroups would have FAQS posted every 30 days or so. A reference document that's periodically updated could be sent the same way.

Isn't this what Slack is trying to do for the workplace? A messaging system that provides reference history?

If your emails are reference documents then I would argue that you're using email wrong.

ha! and i really love the design of this site- just the right amount of design & css styling to elegantly communicate the message..

That's pretty much a non-sequitur. HTML is better in email as well as "reference documents" according to the opinions of many. You don't like thing. Okay.

RFC 822 is plaintext. That's a reference document. Don't see why HTML would be an argument for a reference document. In fact, tex is a good format for reference documents, it diff's well and can produce .ps/.pdf outputs among others.

The very last clause in that sentence answers a question that I hadn't even thought to ask.

I thought it was very odd for what is essentially a marketing post.

Am I crazy for using email to send memos? Those serve as reference documents too, while creating a papertrail.

Email is supposed to be easy to quote, just like you’ve used a block quote in your comment. I assume it’s obvious that rich text is difficult to quote, but a quick explanation is that the invisible formatting characters used to represent rich text behave inconsistently when re-contextualized for a quote.

> "Email is supposed to be easy to quote"

Since when? I have never heard anyone say this in my entire life. I want emails to look good. So I guess people are different and we can't draw a simple conclusion about what people want from email?

I’m not sure what you’re saying here. Is it that you’ve never heard of the concept of quoting a passage of an email? Or are you saying “sure people do that, but it doesn’t matter if it’s easy”?

Or perhaps the parent commenter is part of the lost generation of email users that never properly used quoted replies in email conversations. And this is not necessarily an comment on the age of the parent commenter, but rather about what email programs were common at the time. I blame Outlook mainly for this, but Gmail hasn’t done much to help here either.

The use of quotes in replies is also part of the article and is definitely a better way to go with bottom replies than the current default of top replies.

He means that he’s never heard of it as a “supposed to be”, or rather, a core feature/reason to use email.

Which is my experience as well — it happens to be easy to quote.

The real quoting that email supports, the reply w/ embedded copy of replied email, is unaffected by html/plaintext choice.

Exactly.

> it’s obvious that rich text is difficult to quote

I don't see how. It's just the same as plain text.

It would be easy if there were a single accepted way to quote in rich text. (Seriously, the block quote tag has been around for eternity!) I don't think it works well in plain text either.

HTML has a hierarchical structure.

<div class="quote"> quoted content </div>

It's far better than trying to keep count of how many ">" are in play, and deal with the vagaries of soft linebreaks and hard linebreaks and wrapping of plaintext.

Ok, but then your email client should be smart enough that if, for example, you quote two bullet points from a list it doesn't quote them as

    <div class="quote">
      <li>Second</li>
      <li>Third</li>
    </div>

Without the surrounding `<ul>`. Luckily Thunderbird is smart enough to do this. I don't know about other clients.

You can use markdown with https://markdown-here.com/. It allows composing emails in markdown and sending email as multipart message with plain text markdown plus rendered html. Discussed in https://news.ycombinator.com/item?id=15646425

Reply on news.ycombinator.com