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

[Eric Wong <e@80x24.org>]

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