Why does email development have to suck? – Explaining all the 's and 's
1–10 of 183 posts
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#2When 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 something you can relate to…
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#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 me, the HTML is never rendered because I don't allow it.
The only time I get HTML through email is when it's spam or commercial email, and screw them. Sometimes a real person will neglect to turn HTML off in their mail client, but even then, they aren't really using HTML or are using it for trivial things, so not allowing HTML only makes the garbage email hard to read.
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#4I am involved in ebook production, so I can somewhat sympathize, in that ebook reading systems tend to be way behind browsers in what code they support.
On the other hand, complex html in emails is mainly for the benefit of the businesses sending you the email, for their commercial purposes, i.e., mostly spam. It rarely has anything to do with communicating useful content to the receiver. If the email is too complex for the client, maybe it shouldn't be in the email.
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#5> 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…
I assume your preferred browser is lynx, or maybe you just pipe curl into emacs?
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#6> 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…
I assume your preferred browser is lynx, or maybe you just pipe curl into emacs?
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.
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#7I 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 is no third option.
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#8> 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…
I assume your preferred browser is lynx, or maybe you just pipe curl into emacs?
Umm, no? I don't understand your point...
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#9Earlier quoted context omitted.
I assume your preferred browser is lynx, or maybe you just pipe curl into emacs?
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.
Re: Why does email development have to suck? – Explaining all the <tr>'s and <td>'s
#10I 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…
Perhaps that is your response, but it’s not true of everybody. I’ve done a lot of experiments with different types of email, and beautiful emails always get significantly better response rates.