Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does email development have to suck? – Explaining all the 's and 's

dodov.dev

Post reply on HN
Print view View original

151–160 of 183 posts

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#151

Post by BarbaryCoast »

hifix wrote: post #136

It's HN, so I'm not surprised by the old "just send text" argument that always gets wheeled out when this topic come up, but for those not in a terminal all day there are valid reasons to format HTML emails (that don't include marketing). We send out HTML emails and reports to our users that make use of progress bars, lists, photos, colours etc and they love them. They can get quick full updates on their business wit…

I am a "just send text" guy. But you are correct; users like HTML and no one, like the author of this blog post, even remember that Internet messages are all plain 7-bit ASCII. I don't mind the HTML as much as I mind the Javascript inside them, or the web bugs that are included. Those are privacy and security issues.

So I've adapted to the reality that "email client" is now a web page on a service somewhere, and "email message" is another web page. I don't have to like it, I don't have to use it, but raging against it is a waste of everyone's time.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#152

Post by JimDabell »

anthk wrote: post #148
JimDabell wrote: post #51

Earlier quoted context omitted.

The ability to use formats other than plain text have been a standard part of email since 1992: https://datatracker.ietf.org/doc/html/rfc1341 HTML email is not merely an HTML file sent by email – it is the email.

No, is not, MIME it's like a bundled blob adjointed to a text message.

That’s not what MIME is at all. Please read the RFC.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#153

Post by tacone »

cypressious wrote: post #90

Last time I had to deal with emails, I've used https://mjml.io/ and was very happy with it. You can version the templates, compile them as part of your build pipeline and it seems to do produce very _adequate_ HTML full of tables that looks good on all clients that we tested.

Doesn't seem to be able to automatically embed images as data urls though. That would be very very nice. Or perhaps it does and I just missed it myself?

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#154

Post by shkkmo »

thiht wrote: post #76
JohnFen wrote: post #3

> An email is essentially just an HTML document, like a web page, except it's visualized in an email client, rather than a web browser. However, both are capable of rendering, which is the process of turning HTML code into text, rectangles, and images, i.e. the visualization of the content. No, it is not. An email is a text document. That document might be HTML, but it doesn't have to be. And if such email is sent to…

Once again the stereotypical HN comment of « no this is all wrong, my way is right » For all communications that matter today, email is HTML. No one cares that JohnFen choses to not render them as HTML.

> No one cares that JohnFen choses to not render them as HTML.

Many people care. If you aren't including a plain text version of your email, you aren't following email best practices.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#155

Post by 7952 »

dsr_ wrote: post #52
epolanski wrote: post #31

Earlier quoted context omitted.

There's no chance a business today can work with plain text documents at scale. Virtually all email clients support html since a decade and the expectations user have todays have changed. To put it differently, it looks unprofessional.

There is nothing in the average internal email that requires HTML, much less CSS. There is nothing in the average external email that requires HTML or CSS. There is no useful content in any email that requires JavaScript. "looks unprofessional" is cultural, and of the same significance as green vs blue text bubbles in your SMS messaging system.

Why stop at just supporting the yhe average email though? Tables/embedded images/hyperlinks can be very useful for communication. I can send them without having to worry about platforms/software/SharePoint etc. It is by far the most reliable way of sending a simple, interoperable document we have. And you can easily refer back to it later. There is no good reason not to use html for communication between actual people.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#156

Post by xrd »

The solution is to use maizzle. It's awesome and has a dev mode where you can preview emails as you write them. It's all tailwind and a great authoring experience.

Then, use html-to-text from npm to convert that into text.

Then, every email sending service allows you to send text and html based emails. Regardless of the end user preference, it just works.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#157

Post by shkkmo »

JimDabell wrote: post #51
JohnFen wrote: post #9

Earlier quoted context omitted.

That may be the case, but that still doesn't make HTML a part of email itself. It's using email to send/receive HTML.

The ability to use formats other than plain text have been a standard part of email since 1992: https://datatracker.ietf.org/doc/html/rfc1341 HTML email is not merely an HTML file sent by email – it is the email.

> HTML email is not merely an HTML file sent by email – it is the email.

I'm not sure if the semantic distinction makes sense. An attached file in an email is the also the email. Both HTML, images, and other content types are all sent in the same manner in the body of the email.

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#159

Post by bitwize »

JohnFen wrote: post #3

> An email is essentially just an HTML document, like a web page, except it's visualized in an email client, rather than a web browser. However, both are capable of rendering, which is the process of turning HTML code into text, rectangles, and images, i.e. the visualization of the content. No, it is not. An email is a text document. That document might be HTML, but it doesn't have to be. And if such email is sent to…

> No, it is not. An email is a text document.

"Why don't you use a mail client from this century." --the IT guy at a former job of mine

Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s

#160

Post by JimDabell »

shkkmo wrote: post #157
JimDabell wrote: post #51

Earlier quoted context omitted.

The ability to use formats other than plain text have been a standard part of email since 1992: https://datatracker.ietf.org/doc/html/rfc1341 HTML email is not merely an HTML file sent by email – it is the email.

> HTML email is not merely an HTML file sent by email – it is the email. I'm not sure if the semantic distinction makes sense. An attached file in an email is the also the email. Both HTML, images, and other content types are all sent in the same manner in the body of the email.

> Both HTML, images, and other content types are all sent in the same manner in the body of the email.

This is not the case. In the case of an attachment, the message body is multipart/mixed, where one part is the actual message the sender typed and other parts are the attachments. In the case of an HTML email, the message body is multipart/alternative, where the parts are two or more representations of the actual message typed by the user.

If what you were saying were true, you wouldn’t be able to send an HTML document as an attachment to an email without it being interpreted as the message typed by the user. There is a clear difference between an attachment and the message itself; HTML email is the message itself, not an attachment.

Post reply on HN