I'm glad to see that support for RFC 3676 (format=flowed) has been put
into TODO.[1] I want to write down some ideas and questions about the
implementation public-inbox might have.
First I would like to state my position for format=flowed: It enables
plain text emails to be reflowed by readers' email clients according to
their preferences, which
1) enables reader softwares to reflow text to fit the display region
not suitable for the convention of 72 characters per line, the most
common beneficiary would be mobile phone users, and
2) enables proper quoting behaviour for deeply nested text (irrelevant
for pure archiver like public-inbox).
These problems are known as "embarrassing line wrap" in RFC 3676 and
can be solved by format=flowed it proposed. Whether the text should be
fluid is a matter of personal opinion. To me, the presence of
format=flowed in Content-Type signifies sender's intent to make it
flow. Thus it should preferably be honoured during presentation by the
reader software.
I have done a quick survey on current mailing list archivers' support
for f=f. Services that supports it include:
Archiver software: MHonArc, Hypermail, (less notably) Apache Pony Mail
Archive website: mail-archive.com (proprietary archiver?), spinics.net (mhonarc)
These services simply remove the soft line breaks (<space> followed by
CRLF). Browsers will do the typesetting as usual.
(For the sake of completeness, <space> need not be space, but
configurable by the DelSp parameter in RFC 3676)
f=f allows archivers to convert text quoted with leading < into
HTML <blockquote>, removing the leading angle bracket. This approach
should be preferred since it preserves the semantic meaning in
generated HTML, which also helps accessibility. Nesting relationship
seems to be customarily presented with a solid bar on the left (thick
left border). mail-archive.com and mhonarc behave as such. hypermail
seems to only unwrap ordinary texts, leaving quoted part with <, and
apply a different color to differentiate nesting levels using things
like class="quotelev2".
Services that don't support f=f include:
Archiver software: Pipermail (GNU Mailman 2), HyperKitty (GNU Mailman 3), (less
notably) ietf mailarch
Archive website: groups.google.com, marc.info, narkive.com, (less notably)
markmail.org
These services appear to simply ignore f=f. They might or might not
strip the trailing <space> from generated HTML. Whether those spaces
are visible to users (when selecting or copying text) depends on their
CSS styles (white-space) and HTML white space collapsing rules.
Therefore, current f=f archiver implementations behave similarly, and
I think public-inbox should follow that model by letting client
browsers to reflow the text. This makes the mailing list archive (at
least f=f enabled mails) much more readable to phone users (which
makes up the majority of Internet users currently). A little CSS tweaks
should make an f=f mail doesn't look out of place in a thread with
adjacent fixed mails.
If the implementation for format=flowed will proceed, I have some
additional thoughts for the look and feel of public-inbox.
The current public-inbox website, like traditional plain text email,
is modelled after a fixed display region. It uses hard linebreaks to
keep line width at about 68 characters. <meta name="viewport"> is not
declared in <head>. Using preformatted text, as discussed in the
beginning, is personal design taste of the developer. However, I
consider this to be an opportunity to consider whether the website
should be made more responsive, by ditching <pre> in help texts and
use styles like max-width to maintain a reasonable line width.
[1] https://public-inbox.org/meta/[email protected]/
