61–70 of 263 posts
Earlier quoted context omitted.
It's easy to say this, but can you imagine the hodge-podge of proprietary garbage we'd have to deal with if you couldn't email a simple file attachment to someone?
Email attachments are defined through MIME and don't depend at all on HTML being available as a Content-Type. We could well have had another format and attachments together.
Earlier quoted context omitted.
I'm confused. How is HTML needed to attach a file (or to open the attachment)?
MIME is needed, and with MIME, HTML is basically right there, so people are going to use it.
Earlier quoted context omitted.
MIME is needed, and with MIME, HTML is basically right there, so people are going to use it.
HTML is not needed for attachments to work. If the government for example, banned all use of HTML in emails, people could still attach (non-HTML) files to emails the same way they do now. Therefore the comment I replied to, a defense of HTML in emails, is a bogus argument.
Is there something like this for features techies might care about? Like some sort of guarantee of at-rest encryption, SMTP/IMAP/POP/etc support, end user encryption, reasonably fast search , backup/restore, etc. GNOME Evolution and Thunderbird, at least last I used it, have abysmal search speed, taking seconds to search through a local DB of a few thousand emails. So they're clearly using search tech much inferior t…
We've tried building email templates for notifications for our apps where I work, and it has typically been a pain. We have since swapped to using mjml (https://mjml.io/) to build the templates, and it's working wonders. The output seems the be the most compatible with all different devices that we've tested on.
The other tool we enjoy using is Litmus (https://litmus.com), which allows you to throw in an email template and see what it looks like on all kinds of apps and devices. Other thread here mentions https://testi.at/ as well, which we've also had success with.
All of these have been really invaluable to designing emails for our apps.
IMO, HTML was the worst thing that ever happened to email. Plain text content is the best content.
That's a completely valid opinion, and I prefer plaintext as well But at this point, it's pretty clear that most non-technical people prefer emails with fancy text and graphics. Personally, I'm just glad that email is a flexible enough medium to allow that. It's better than the alternative, where people moved to some closed, proprietary protocol behind like 20 patents that allows the same thing. Is there any other co…
And what percentage of e-mails from people / human beings have those things?
Certainly marketing e-mails have fancy formats, but I've rarely seen any person at a companies I've worked at use any kind of formatting: generally most folks hit reply and start typing with whatever the default is. Hardly any italics or bold, and forget about fixed width (for things like CLI commands in technical discussions).
Heck, even Slack messages these styles are hardly used (on my current team I use them the most since I know that Markdown so it's easy for me to throw in some **, //, or `` in my typing flow, so I can highlight hostnames, CLI commands, etc).
Earlier quoted context omitted.
HTML is not needed for attachments to work. If the government for example, banned all use of HTML in emails, people could still attach (non-HTML) files to emails the same way they do now. Therefore the comment I replied to, a defense of HTML in emails, is a bogus argument.
The point is that attachments are needed to make HTML work. If you have attachments, you have HTML emails.
They are not.
MIME headers are helpful for telling MUAs what the content (type and/or disposition) of a message is, but there's nothing from stoping mail clients from just putting "raw" HTML in the body of an e-mail message without MIME.
I wish there was something like BrowserStack but you send a test email and it shows you how it renders on tons of different email clients on various platforms. It wouldn't work for web-based email like Gmail but it would still be useful.
Best tool I've found is Testi@[1]. It's really affordable and it supports basically everything out there. * Disclaimer: Not affiliated, just a happy customer. - [1] https://testi.at/
Earlier quoted context omitted.
The point is that attachments are needed to make HTML work. If you have attachments, you have HTML emails.
> The point is that attachments are needed to make HTML work. They are not. MIME headers are helpful for telling MUAs what the content (type and/or disposition) of a message is, but there's nothing from stoping mail clients from just putting "raw" HTML in the body of an e-mail message without MIME.