Proportional fonts are very pleasant for reading, but not as easy to write text in (if you want to do some custom layout), in which case a markup language is getting used.
That probably means that we shift email from a tool to write to a tool to read.
Of course, if most of what is transmitted by email is web services notifications and files to access over IMAP elsewhere, we get to read write much less in proportion.
While people who do not care about how email works or are implemented enjoy highlighting the keywords of their sentence, people interested into the email stack (and eventually trying to make it not so tall) will keep enjoying the relative simplicity of SMTP + IMAP + SPF + DKIM + DMARC + TLS + STARTTLS + RFC3522 + MIME + Quoted-Printable over SMTP + IMAP + SPF + DKIM + DMARC + TLS + STARTTLS + RFC3522 + MIME + Quoted-Printable + XML + HTML + CSS.
Ooh! Don’t forget format=flowed, my favorite email feature that every MUA documents as The Right Way to fix things but that doesn’t actually work with Outlook, Gmail, Fastmail, or many others.
Or maybe everyone loves seeing emails like
Owen, why are your emails always fucked up?
I think this is a fair idea but really it deserves
more thought.
Frobulating this widget may have unintended
consequences.
Instead we should consider an approach
that avoids unneeded frobulation; instead lets
quux
On September 10th, your cow orker orked:
> why don’t you just frobulate all the impacted
widgets
I adore format=flowed. It solves one of the four major problems well. (I’m not facetious — one out of four is much better than zero IMO, even if haters tend to pick on it being less than four.)
I really like gmail’s HTML email. Parsing and rendering that is so much more pleasant than text/plain HTML. It has CSS classes for quotes and signatures, and the tables use HTML table syntax, so making the content readable on a narrowish phone screen is trivial.
Try rendering that ASCII ribbon table nicely on a phone screen that’s wide enough for five words… it’s a three-column, table, right? Or two? Can the text in each table cell be wrapped so the table will fit onscreen?
IMO that page is misleading in part, because it presents a bad practice that some follow, as the only potential way it can be done.
In multiple points, it says some clients/users/assistive technologies can’t process HTML email, and suggests that for this reason HTML email should be verboten, instead of the more practical, and common practice of sending the message content in two media types: text/plain, and text/html.
I was really confused about what was supposed to complete that sentence. After trying “John Carmack” and “admin@gmail.com” I finally figured it out by putting in “google” and getting an unrelated result:
@font-face in CSS allows to include your own fonts inside an email.
Of course, the really obvious guesses in this category of “bold”, “italics”, and “colors” don’t give any results either. I’m really questioning the primary presentation of this information. It seems to be much more suited to list format like on the features page.
It’s pretty much the same as [caniuse.com] (https://caniuse.com/) - website for frontend developers which lists browser compatibility for various CSS/Js features. Except this is not compatibility with browsers but email clients.
Be right back, making shouldiemail.com, which will just return “no” for everything except plaintext.
On a serious note, I actually find myself in the position of making a new protocol that has some similarity with email in this regard, including all the problems of rich text. I’m planning on making a new HTML-like language that’s almost purely semantic, and encouraging useragents to render it however they like, but I fear it could devolve straight into HTML5 garbage eventually.
I’ve been participating on the Geminimailing list (it’s a protocol somewhat between gopher and HTTP with mandatory TLS) and I swear, over half the messages on the mailing list have been about formatting text.
Cut tags, for spoilers and content warnings and digressions and whatnot (and in HTML, this even requires javascript)
If you can target Safari 6, Firefox 49, and Chrome 12, and you’re not worried about IE/Edge, the <details> element will give you this without any JavaScript.
For 1, I use an extra indentation.
For 2, I use references [1].
For 3, I'd use a custom markup.
Note:
| This is an example of custom markup that does
| not clash with the '>' of quoting someone and
| looks like what it is: a note.
But it looks like what you want is sending a
formatted document.
[PDF]
lacks semantics and extracting data out of them
is a large pain.
[HTML]
is a never-ending growing tower that makes
communication every day more complex (I don't
imagine HTML-based SMS!).
[Markdown]
is a sweet spot between HTML and plain text, but
will not get formatted by any mail client I know
(without extension / forking the code and doing it
yourself).
[Plain text]
can present everything with some extra creativity
and/or manual typesetting, or text typesetters can
help making it easier.
[Other]
there might be many more formats that works just
fine, but might really not be supported by mail
clients in use.
_____
[1]: Like this, or maybe [attachment:1]
Extra indentation assumes everything is monospace and hard-wrapped, which won’t be the case. :-/
I just remembered something for cut tags, though: On Usenet, people would use rot13 to that effect! It doesn’t help with collapsing particularly long pieces, but that’s something the client can help with anyhow.
I did not know about rot13. Fun ad-hoc implementation of spoiler !
About hard wrapping, I remember sending a plain text calendar to my boss for telling when I would be available (easier this way than a list of ~20 date ranges), and he received it on an iPad with variable width with auto-wrapping.
HTML email is a really big mess security wise. The fact that such a page exists highlights a problem in itself: Nobody really knows what HTML mails really are and what features they’re supposed to support.
If there was a reasonable concept behind HTML mail there would be a standard defining exactly which subset of HTML is allowed within mails. There is no such thing. The simple question “How to I process an HTML mail so it’s safe to display in a webmail frontend?” has no clear answer. Unsurprisingly pretty much all webmail frontends suffer from XSS all the time.
I read it as suggesting I use a mail client with support for as few advertising features as possible. They just need to update it with results from alpine or mutt…
Just because you can, doesn’t mean you should!
And against proportional fonts, too? ;-)
Proportional fonts are very pleasant for reading, but not as easy to write text in (if you want to do some custom layout), in which case a markup language is getting used.
That probably means that we shift email from a tool to write to a tool to read.
Of course, if most of what is transmitted by email is web services notifications and files to access over IMAP elsewhere, we get to read write much less in proportion.
While people who do not care about how email works or are implemented enjoy highlighting the keywords of their
sentence, people interested into the email stack (and eventually trying to make it not so tall) will keep enjoying the relative simplicity of SMTP + IMAP + SPF + DKIM + DMARC + TLS + STARTTLS + RFC3522 + MIME + Quoted-Printable over SMTP + IMAP + SPF + DKIM + DMARC + TLS + STARTTLS + RFC3522 + MIME + Quoted-Printable + XML + HTML + CSS.Ooh! Don’t forget format=flowed, my favorite email feature that every MUA documents as The Right Way to fix things but that doesn’t actually work with Outlook, Gmail, Fastmail, or many others.
Or maybe everyone loves seeing emails like
Misplaced newlines…
Here is some explanation helpful to me from that email-litterate company: https://fastmail.blog/2016/12/17/format-flowed/
I adore format=flowed. It solves one of the four major problems well. (I’m not facetious — one out of four is much better than zero IMO, even if haters tend to pick on it being less than four.)
I really like gmail’s HTML email. Parsing and rendering that is so much more pleasant than text/plain HTML. It has CSS classes for quotes and signatures, and the tables use HTML table syntax, so making the content readable on a narrowish phone screen is trivial.
Try rendering that ASCII ribbon table nicely on a phone screen that’s wide enough for five words… it’s a three-column, table, right? Or two? Can the text in each table cell be wrapped so the table will fit onscreen?
IMO that page is misleading in part, because it presents a bad practice that some follow, as the only potential way it can be done.
In multiple points, it says some clients/users/assistive technologies can’t process HTML email, and suggests that for this reason HTML email should be verboten, instead of the more practical, and common practice of sending the message content in two media types: text/plain, and text/html.
I was really confused about what was supposed to complete that sentence. After trying “John Carmack” and “admin@gmail.com” I finally figured it out by putting in “google” and getting an unrelated result:
Of course, the really obvious guesses in this category of “bold”, “italics”, and “colors” don’t give any results either. I’m really questioning the primary presentation of this information. It seems to be much more suited to list format like on the features page.
I still have no idea what this site is all about.
It’s pretty much the same as [caniuse.com] (https://caniuse.com/) - website for frontend developers which lists browser compatibility for various CSS/Js features. Except this is not compatibility with browsers but email clients.
[Comment removed by author]
I spent like 2-3 minutes on there before giving up… Still lost.
I spent like 2 minutes thinking about it and then finally guessing it might be about which HTML/CSS features are understood by email clients.
But only because I had to spend hours to do this, years ago.
It’s really, really badly communicated
Probably the introduction should instead be submitted https://www.caniemail.com/news/2019-09-09-introducing-caniemail/
Can I use table? No results found.
Be right back, making shouldiemail.com, which will just return “no” for everything except plaintext.
On a serious note, I actually find myself in the position of making a new protocol that has some similarity with email in this regard, including all the problems of rich text. I’m planning on making a new HTML-like language that’s almost purely semantic, and encouraging useragents to render it however they like, but I fear it could devolve straight into HTML5 garbage eventually.
I’ve been participating on the Gemini mailing list (it’s a protocol somewhat between gopher and HTTP with mandatory TLS) and I swear, over half the messages on the mailing list have been about formatting text.
There are basically three things I want to be able to do that plaintext does not support:
Maybe tabular data too? But those are the big ones.
If you can target Safari 6, Firefox 49, and Chrome 12, and you’re not worried about IE/Edge, the
<details>element will give you this without any JavaScript.Ah, nice!
Extra indentation assumes everything is monospace and hard-wrapped, which won’t be the case. :-/
I just remembered something for cut tags, though: On Usenet, people would use rot13 to that effect! It doesn’t help with collapsing particularly long pieces, but that’s something the client can help with anyhow.
I did not know about rot13. Fun ad-hoc implementation of spoiler !
About hard wrapping, I remember sending a plain text calendar to my boss for telling when I would be available (easier this way than a list of ~20 date ranges), and he received it on an iPad with variable width with auto-wrapping.
Unreadable !
I thought I’d never be hired after that…
This was an example of what plain text email can look like, and it looks not so terrible to me.
Of course, I am biased as I prefer plain email text over HTML.
HTML email is a really big mess security wise. The fact that such a page exists highlights a problem in itself: Nobody really knows what HTML mails really are and what features they’re supposed to support.
If there was a reasonable concept behind HTML mail there would be a standard defining exactly which subset of HTML is allowed within mails. There is no such thing. The simple question “How to I process an HTML mail so it’s safe to display in a webmail frontend?” has no clear answer. Unsurprisingly pretty much all webmail frontends suffer from XSS all the time.
I expanded on this a bit back when efail was found: https://blog.hboeck.de/archives/894-Efail-HTML-Mails-have-no-Security-Concept-and-are-to-blame.html
I read it as suggesting I use a mail client with support for as few advertising features as possible. They just need to update it with results from alpine or mutt…