Live data from Hacker News

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

dodov.dev

51–60 of 183 posts

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

#51
post #9
post #6

Earlier quoted context omitted.

I use mutt and unfortunately in the corporate world you can't just ignore HTML or even HTML only mails. I pipe them to elinks, works 99.9% of the time easily.

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.

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

#52

I don't understand the insistence on building "beautiful" emails. I'm not the kind of person to insist on text-only e-mail, but I do think it's ridiculous to spend lots of time and money making e-mails that look like fully-fledged Web documents. Either your message does have some useful information for the reader, in which case say that and then get out of my way, or it doesn't , in which case you're a spammer. There…

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.

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

#54
post #2

When I first got introduced to email development, I remember I wanted to throw myself off a cliff. I couldn't believe how nonsensical everything was. I kept track of everything in a little text document, which I've now turned into a post. If you happen to be starting out with emails, I hope this can get you up to speed with exactly how everything is fucked. And if you're an Outlook survivor, I hope you'll find someth…

If you were thinking more clearly, you would want to throw whoever asked for "email development" off a cliff.

People choose the wrong targets for violence.

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

#55

Earlier quoted context omitted.

Is transactional email spam?

Well, that depends. Is it something I need to see? Did I proactively ask for it, or did I neglect to opt out? Etc, etc. If you are having to measure response rate, and it doesn't involve an emergency alert or some such, it is probably spam.

Transactional mail is not marketing mail.

It's typically a notification in response to an action you initiated on some web application.

https://postmarkapp.com/blog/what-is-transactional-email-and...

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

#56
post #52

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.

This is an absurdly wrong, yet characteristically HN take.

Transactional mail typically requires some hyperlink for the average user.

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

#57
post #46
post #33

Earlier quoted context omitted.

Virus scanners and other tools like google will fetch any urls in emails to check their target. So having a direct unsubscribe action behind GET of a link breaks your email list as Gmail will unsubscribe everyone

Is this why they always have a confirm button? That's been a pet-peeve annoyance of mine.

It’s a basic part of HTTP. If you follow a link, that’s a GET request. GET requests are supposed to be safe. A user may not have initiated the action if it’s a GET. If you want something that implies “yes, the user made an intentional choice to take action”, then use another verb, like POST.

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

#58

How do I make gmail automatically scan every incoming email for "unsubscribe" links and click them?

You can't get the end result by automation alone but you could automate half of it. 1) Use AppScript from google to find those. 2) Save all the links. 3) Go through them manually (because each service will want you to confirm you did not click by mistake).

Alternatively, make a filter that applies a label and skips inbox. Occasionally, open the label, select all, and Report Spam.

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

#59

Text. Just use damn text. Nobody wants to look at your logo. Why biz people have to ruin everything.

Ironically, plain text emails actually do better for us - the problem is that plaintext emails are often more likely to be caught up by spam filters.

The data I've seen suggests the opposite?
Post reply on HN