format=flowed: the little standard that couldnʼt quite make it

This is the seventeenth post in the 2016 FastMail Advent Calendar. Stay tuned for another post tomorrow.

---

In its earliest days, email was an entirely text based affair. There was no bold or italic, no headings, no fonts; just text.

Even more than that, the text itself had particular constraints. The email standard says that lines should be no longer than 78 characters, though things like quoted printable do allow logical lines longer than this. Historically however, emails were hard wrapped (that is, a line break was inserted) after at most every 78 characters, usually at a word boundary.

Additionally, there were conventions on what should be done with text from previous emails when you replied to them, namely that each line you included should be “quoted” with a > prefix, so you end up with levels like this:

> > How about dinner?
> Sounds great. Where?
How about Il Solito Posto?

This works fine for short lines, but when you have blocks of longer text and multiple replies back and forth, prefixing > at the start of each reply line can push it to longer than 78 characters, which then gets wrapped again. Repeated a number of times, this can result in a mess of randomly wrapped and quoted lines, colloquially known as “embarrassing line wrap”.

A while back, there was an interesting attempt to fix this known as format=flowed. The standard itself is sort of neat, in that it applies a logical quoting construct in a backwards compatible manner to text emails. A receiver without format=flowed support sees a normal email and can reply as normal, though they may end up with embarrassing line wrap, but a format=flowed aware receiver will correctly re-wrap the further quoted sections when you reply, to ensure the lines are shorter than 78 characters but without the messy wrapping.

This was one of those standards we were always interested in implementing, but it never got high enough up the priority list.

Unfortunately, having had a look again, I donʼt think itʼs likely weʼll ever do it, for a couple of reasons:

1. Very little else supports it when sending. None of the major webmail providers and neither of the big email clients, Outlook or macOS Mail, support it. I believe recent versions of Thunderbird disable it by default as well. So if you send text emails back and forth with any other system that doesnʼt support it, they immediately end up with “embarrassing line wrap” that canʼt be fixed, mostly defeating the point of format=flowed.
2. The biggest users of text-only emails are IT tech people who post to mailing lists and the like. As noted in common mailing list etiquette guides, you should disable format=flowed to avoid any software patches getting broken, defeating the main potential userbase for this feature.
3. The original backlash against HTML email “bloat” is mostly gone these days. The vast majority of users donʼt care about size since email quotas are much, much larger these days, and they just want their email to work like a word processor, so they can insert different fonts, colours, images, etc. HTML email uses the HTML <blockquote> construct to create reply structures, which correctly re-flows any text within it.

On top of that, there are two significant implementation issues to deal with:

1. To implement it well, you need to create an editor that supports semantic blockquoting, but nothing else. This is probably doable in Squire (the HTML editor we wrote for our webmail), but it would still be a significant extra development and maintenance requirement.
2. You really want to be able to fix up existing emails with “embarrassing line wrap” because of all the other systems out there that donʼt support format=flowed. This might just be possible by hacking into Text::Autoformat to unwrap long lines. However itʼs not quite as easy as that, Text::Autoformat does lots of other nice things for email type text, like indenting trailing text in long numbered lists, etc. format=flowed doesnʼt support that at all. It might be doable by giving Text::Autoformat a very large line length, but Iʼm sure there are lots of nasty edge cases.

Put together, all of these things make format=flowed a standard that doesnʼt feel worth implementing any more. In some respects thatʼs a real pity, but in others, itʼs just another sign that things have moved on. In yet another area, HTML has mostly won, and there are only a couple of places (mostly technical communities) where people still use text only emails.