From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 93F231F626 for ; Sat, 18 Feb 2023 20:51:55 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=MRDXNWaY; dkim-atps=neutral Received: by mail-lf1-x12b.google.com with SMTP id s7so1604566lfc.11 for ; Sat, 18 Feb 2023 12:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=dGgJC0o6EqGqrJAaOKAE79a3L/SL+UfkrwCzAcZ+sU0=; b=MRDXNWaYoM1VC06hr5OyCf2HK3frgqlzMYlMC2+McVV1xKeQGUyjATuV73aNcVE1Jk vt7aKGOpD7EMkvEcQi+fpgPagHHgFTNBmxrMnioNI1baBycAvVeCUI72ES/VYyK3YRLV rlWDPXiNvkug/MD1wusE562Z5/PvrpxfGOBIobkbNh8GGFqScGPZhIVOidTioV/HDN7r 5rmg1kxSqr63ZSxh6o6kThuU1ciSqYGzXDtHgx8wLziIsOrIjT/VPfOW6YomwhhK6abI svyRpFCRbaJwwNLFeyCD5NkTvfk8lPjLAwW5lkiCIvE11rFo5jUmcPnFvaoiWTql1V5t OWyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dGgJC0o6EqGqrJAaOKAE79a3L/SL+UfkrwCzAcZ+sU0=; b=yP+BWBKGvU94v56jMgfVm+kKTf5gtCI/e891NS4Q+DyJYH9Jd1DzoL5RvUHx8cS2fH xHlfvHdfmQOEItZpNS77B8htUQe3Fcgc5RTzm1HmPY+3CGjmpiQEJ+36GR1c4xHWnD4l MDrY3ycD1HSw+Gz205clGqxPxOj+X+CTR6oGTz4Mv/b19Jk7vHvKNym+8VdcclWTnLi0 qtK5Xv4ZvFM0R4epgyO63mXREzmnsP5l6hSOD2YSE84rk3Xht5SfHOd5crQSqfyrRYST yDI+81WT2V1/DQkrrLLpjP+Wj14AnBMC2hL8x7rmjeCMSPZBI3Y9nnFv8dALdBzgdzcQ sT/Q== X-Gm-Message-State: AO0yUKUf4EQevtadP5bsgBMFSh9EgLy4oSX89c+pq/UM5rkJeHUr9dh1 GUlUKXJko6Pr1OG4z7RynBCaBzHILN0= X-Google-Smtp-Source: AK7set8PF71yt28VYTPxsAFed5LM8VwoyH0WyhJAcvMeCdNdkRVjH+/2DZQPqIg/gYD+p6CXkXnRtg== X-Received: by 2002:ac2:5a19:0:b0:4b5:9845:c8a9 with SMTP id q25-20020ac25a19000000b004b59845c8a9mr45723lfn.47.1676753513341; Sat, 18 Feb 2023 12:51:53 -0800 (PST) Received: from m (dzcj40yydw5j8-pnb3-tt-3.rev.dnainternet.fi. [2001:14ba:a08f:8f00:396:4fcf:b161:bfe1]) by smtp.gmail.com with ESMTPSA id j2-20020a19f502000000b004db3dc10189sm1067013lfb.292.2023.02.18.12.51.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Feb 2023 12:51:52 -0800 (PST) Date: Sat, 18 Feb 2023 22:51:50 +0200 From: Charles Zhang To: Eric Wong Cc: meta@public-inbox.org Subject: Re: Considerations about format=flowed support and web page responsiveness Message-ID: <20230218205150.txwve6shp6ddqfff@m> References: <20230213105925.6zccabv3yldniqam@m> <20230214073556.M451504@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <20230214073556.M451504@dcvr> List-Id: 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 (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]. >
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
nesting levels using different indentation, while lynx just shows purple-coloured text for
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 instead of 
 for f=f messages
>(since  is deprecated :<, and we can't rely on all GUI
>browsers supporting *{font-family:monospace} CSS)

 and 
, , 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  to be appropriate here since it means 
inline computer code. They should be plain 
 as they are normal 
paragraphs. I might apply custom styles to make them sans-serif 
due to personal preferences.

>Right.  Using 
 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