Re: Considerations about format=flowed support and web page responsiveness

[Charles Zhang <csalinezh@gmail.com>]

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