5 ms·
The only advice on HTML in e-mail should be: don't!
by tehabe 14y ago
The only advice on HTML in e-mail should be: don't!
- eli 14y agoI think you lost that battle like 15 years ago
- Paul_S 14y agoNah, if someone sends me HTML it gets parsed into plaintext and if it doesn't work I don't care what's in it. You want to send me a pretty document - feel free to send me an attachment or a link. HTML emails are always ridden with superfluous disclaimers and signatures not using the -- convention, they're a waste of time.
- eli 14y agoI got absolutely no problem with that, I just don't think you're going to win many converts.
- JoeAltmaier 14y agoUse them to send embedded screen captures at work. Could be an attachment, but then its hard to put into context.
- ldh 14y agoI sympathize, but I'd much rather somebody send me an HTML email than an attached Word document, which is the next likely candidate in most workplaces.
- mbateman 14y agoYou may have to parse HTML email, but you don't have to send it.
- brlewis 14y agoThere are valid uses. My hybrid photo-sharing/blogging service lets you send an email update with thumbnails inline, so you can tell family/friends about your latest doings without making them click a link out. http://ourdoings.com/ http://ourdoings.com/ I suppose you could generalize this by saying HTML email is useful when you have images that are informational, not just decorative.
- shabble 14y agoat the least you can be sending multipart/alternative to include both a text/plain and html body, so you don't have the horrible situation of people getting html source dumped at them. Most webmail clients these days support 'rich content' to a reasonable degree, but a lot of people still have old desktop clients that'll just give up and throw it all at them. That said, maintaining 2 templates or deciding exactly how to handle the formatting of the text version can be a hassle. I'm curious how others have handled this problem.
- tomwalsham 14y agoSending HTML-only email is still a large spam flag, even at major ISPs, independent of the concerns about client compatibility. At PostageApp our solution to the problem is a templating engine where you can write your HTML/CSS separately and we inline it at run time to ensure client compatibility. We then provide a separate Plaintext tab with an 'import from html' function which does most of the work for you for managing dual formats.