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
