* Considerations about format=flowed support and web page responsiveness
@ 2023-02-13 10:59 Charles Zhang
2023-02-14 7:35 ` Eric Wong
0 siblings, 1 reply; 4+ messages in thread
From: Charles Zhang @ 2023-02-13 10:59 UTC (permalink / raw)
To: meta
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/20220901185829.30117-1-e@80x24.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Considerations about format=flowed support and web page responsiveness
2023-02-13 10:59 Considerations about format=flowed support and web page responsiveness Charles Zhang
@ 2023-02-14 7:35 ` Eric Wong
2023-02-18 20:51 ` Charles Zhang
0 siblings, 1 reply; 4+ messages in thread
From: Eric Wong @ 2023-02-14 7:35 UTC (permalink / raw)
To: Charles Zhang; +Cc: meta
Charles Zhang <csalinezh@gmail.com> wrote:
<snip> thanks for the comments although we have different views.
> 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.
f=f will be supported only because it exists and MUAs (e.g.
mutt) support it; not because I want to encourage it as it
as f=f mangles code+patches while forcing more complexity into
renderers/viewers (including `git log' for commit messages)
<snip>
> 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".
<blockquote> is indistinguishable from indentation in w3m.
lynx can show a different color, but that does not work for
color-blind users, nor users on monochromatic displays.
So I'm keeping `>' prefixes since that's what local MUAs
(e.g. mutt) does. It also makes copy+paste forwarding
easier.
It's of utmost importance that users with broken graphics
drivers be able to access public-inbox instances and download
patches from the terminal (which may be required to fix their
graphics drivers).
<snip>
> 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.
While phone users make up the majority of Internet users;
I don't expect the majority of people reading code/patch
emails to be doing so on their phones.
We'll probably use <code> instead of <pre> for f=f messages
(since <tt> is deprecated :<, and we can't rely on all GUI
browsers supporting *{font-family:monospace} CSS)
> 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.
Right. Using <pre> everywhere makes it easy to get a WYSIWYG
experience for everyone, regardless of which browser they use
(or even if it's just `curl $URL | $PAGER'). I certainly don't
want to encourage the use of complex modern browsers which take
hours or even days to build.
Fwiw, I manually wrap my messages depending on how I want
the text to appear, not usually to any hard limit. I do
favor shorter lines in anticipation of quoting or indentation
(e.g. what `git log' does by default)
The goal of our HTML isn't to be an end-all, be-all UI;
but rather a way to bring a mutt-like experience to more users
(and maybe drive local MUA adoption in the process).
> [1] https://public-inbox.org/meta/20220901185829.30117-1-e@80x24.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Considerations about format=flowed support and web page responsiveness
2023-02-14 7:35 ` Eric Wong
@ 2023-02-18 20:51 ` Charles Zhang
2023-02-19 21:22 ` Eric Wong
0 siblings, 1 reply; 4+ messages in thread
From: Charles Zhang @ 2023-02-18 20:51 UTC (permalink / raw)
To: Eric Wong; +Cc: meta
On Tue, Feb 14, 2023 at 07:35:56AM +0000, Eric Wong wrote:
>f=f will be supported only because it exists and MUAs (e.g.
>mutt) support it; not because I want to encourage it
>as f=f mangles code+patches while forcing more complexity into
>renderers/viewers (including `git log' for commit messages)
I consider the incompatibility of f=f with code/patch mail is mostly
from its concept of "space-stuffing" and definition of soft line break.
If a line starts with a space, rules for space stuffing will remove
this first space. This will break space-based indentation. If a line
ends with a <space> (DelSp), it will be joined with the next line since
the soft line break is removed (leaving invisible control characters
at the end of line usually sounds like a mistake).
However, if the author considers an email to be preformatted text and
does not intend it to be reflowed, f=f should be disabled for this
email. Generally it's not encouraged to send patches as f=f, as per
the current lkml guide [2].
It does require more logic for the presentation of emails due to
additional parsing and reflowing, though reflowing logic should already
be present in most viewers. A recent implementation for f=f takes about
500 lines (incl. tests) in aerc (an email client written in golang) [3].
><blockquote> is indistinguishable from indentation in w3m.
>lynx can show a different color, but that does not work for
>color-blind users, nor users on monochromatic displays.
>So I'm keeping `>' prefixes since that's what local MUAs
>(e.g. mutt) does. It also makes copy+paste forwarding
>easier.
I consider quoted paragraphs are, nevertheless, paragraphs, and can be
flowed naturally. Thunderbird can reflow nested quotes since bug 45605
is fixed in Thunderbird 52 in 2016 [4]. I don't have experience with
other TUI email clients so can't comment on their presentation choices.
From my testing w3m can render different <blockquote> nesting levels
using different indentation, while lynx just shows purple-coloured text
for <blockquote> without indentation. Lynx's behaviour actually
contradicts their document [5].
It's unfortunate that web designers can't do much about these TUI
browsers since they don't support CSS. If clear indication for nested
texts on them is desired, I guess those > have to be kept in HTML.
>It's of utmost importance that users with broken graphics
>drivers be able to access public-inbox instances and download
>patches from the terminal (which may be required to fix their
>graphics drivers).
public-inbox makes the raw email easily available through a link.
That's what I usually use to download a patch from mailing list.
f=f won't affect this functionality.
>We'll probably use <code> instead of <pre> for f=f messages
>(since <tt> is deprecated :<, and we can't rely on all GUI
>browsers supporting *{font-family:monospace} CSS)
<tt> and <center>, <font>, etc. were deprecated together in HTML 5
since they only concern the appearance but not the semantic meaning of
an element. Things related to appearance have been designated to CSS,
to keep HTML clean for its original semantic meaning (though seldom
adhered to in modern web development). I don't expect browsers will
drop support for them. The only complaint would be from HTML validators.
I don't consider <code> to be appropriate here since it means
inline computer code. They should be plain <p> as they are normal
paragraphs. I might apply custom styles to make them sans-serif
due to personal preferences.
>Right. Using <pre> everywhere makes it easy to get a WYSIWYG
>experience for everyone, regardless of which browser they use
>(or even if it's just `curl $URL | $PAGER').
I might be trolling, but using preformatted text won't guarantee
identical representation at client side, due to possible wrapping
and truncation by a narrow-sized terminal. Feel free to ignore this
point if feel so.
>The goal of our HTML isn't to be an end-all, be-all UI;
>but rather a way to bring a mutt-like experience to more users
>(and maybe drive local MUA adoption in the process).
Speaking for myself, I'm mostly a read-only user of mailing lists.
I would like to follow some mailing list discussions more easily on a
phone browser. I expect f=f will improve the experience on phones
(though such emails are not that common). Currently the web page is
subject to automatic font size adjustment on phone browsers (called
"font boosting" for mobile Chrome. haven't tried to find the origin
of this name). For preformatted text it leads to ragged lines that are
unpleasant to read.
I still appreciate your work on public-inbox a lot. The web interface
is intuitive to use, and the search function is really helpful for
digging into the archive. Google seems to have given up on indexing
mailing list archive pages in past five years.
[2] https://www.kernel.org/doc/html/v6.1/process/email-clients.html
[3] https://git.sr.ht/~rjarry/aerc/commit/c9524d265793775e4c3e326c7191471d982c1e66
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=456053
[5] https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html#id-Quotes
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Considerations about format=flowed support and web page responsiveness
2023-02-18 20:51 ` Charles Zhang
@ 2023-02-19 21:22 ` Eric Wong
0 siblings, 0 replies; 4+ messages in thread
From: Eric Wong @ 2023-02-19 21:22 UTC (permalink / raw)
To: Charles Zhang; +Cc: meta
Charles Zhang <csalinezh@gmail.com> wrote:
> However, if the author considers an email to be preformatted text and does
> not intend it to be reflowed, f=f should be disabled for this email.
> Generally it's not encouraged to send patches as f=f, as per the current
> lkml guide [2].
Right, and most messages are not f=f nowadays. Every commit
message in a patch email is expected to be preformatted as it
ends up being viewed via `git log' in a terminal.
> On Tue, Feb 14, 2023 at 07:35:56AM +0000, Eric Wong wrote:
> > It's of utmost importance that users with broken graphics
> > drivers be able to access public-inbox instances and download
> > patches from the terminal (which may be required to fix their
> > graphics drivers).
>
> public-inbox makes the raw email easily available through a link. That's
> what I usually use to download a patch from mailing list. f=f won't affect
> this functionality.
I hope users will read a thread before deciding to download
and apply a patch, though (and not mindlessly downloading +
applying patches w/o context).
> > Right. Using <pre> everywhere makes it easy to get a WYSIWYG
> > experience for everyone, regardless of which browser they use
> > (or even if it's just `curl $URL | $PAGER').
>
> I might be trolling, but using preformatted text won't guarantee identical
> representation at client side, due to possible wrapping and truncation by a
> narrow-sized terminal. Feel free to ignore this point if feel so.
80 columns is the only width that has any sort of
standardization behind it. Keeping messages <=80 columns ought
to ensure it's OK for anybody reviewing patches because that's
the most widely-standardized width for code.
Obviously, if somebody is using a 60-column display then
they're in for a hard time working on any project.
> > The goal of our HTML isn't to be an end-all, be-all UI;
> > but rather a way to bring a mutt-like experience to more users
> > (and maybe drive local MUA adoption in the process).
>
> Speaking for myself, I'm mostly a read-only user of mailing lists. I would
> like to follow some mailing list discussions more easily on a phone browser.
> I expect f=f will improve the experience on phones (though such emails are
> not that common). Currently the web page is subject to automatic font size
> adjustment on phone browsers (called "font boosting" for mobile Chrome.
> haven't tried to find the origin of this name). For preformatted text it
> leads to ragged lines that are unpleasant to read.
Given the lack of f=f messages on mailing lists (and f=f being
actively discouraged); I doubt adding f=f to public-inbox would
make a difference to people reading messages on a phone.
Fwiw, the use of small phone displays is likely a passing phase.
I've seen some fold-out phones with larger displays, and
augmented reality glasses/contacts may become common one day.
(and I'll still carry an ancient laptop with a good keyboard)
> I still appreciate your work on public-inbox a lot. The web interface is
> intuitive to use, and the search function is really helpful for digging into
> the archive. Google seems to have given up on indexing mailing list archive
> pages in past five years.
Thanks again for the feedback. Of course, it's not in any corporation's
interest to promote things they can't monetize.
> [2] https://www.kernel.org/doc/html/v6.1/process/email-clients.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-19 21:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-13 10:59 Considerations about format=flowed support and web page responsiveness Charles Zhang
2023-02-14 7:35 ` Eric Wong
2023-02-18 20:51 ` Charles Zhang
2023-02-19 21:22 ` Eric Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).