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=-4.2 required=3.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 86DA21F626; Tue, 14 Feb 2023 07:35:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org; s=selector1; t=1676360156; bh=bdRlIr15nG6x10QHV+va2txO0JovD4iJDMaf/j6TSMg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X1hL8kZ3u+kw8pirghy2dxixR/sCGH/beFAFIGDBZ3ZP7zWvPpbGrB6FP1ym0V2P0 DmHa0bQrxHjDM8CWpii0GcckDoq/J8b4+L+3HreO802hvM2wKmCLOJlrDsGCV0Vk2r +9jT8hCz8RVb7LDq+QSsPGaMs4lne1XN9dLXSoU0= Date: Tue, 14 Feb 2023 07:35:56 +0000 From: Eric Wong To: Charles Zhang Cc: meta@public-inbox.org Subject: Re: Considerations about format=flowed support and web page responsiveness Message-ID: <20230214073556.M451504@dcvr> References: <20230213105925.6zccabv3yldniqam@m> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230213105925.6zccabv3yldniqam@m> List-Id: Charles Zhang wrote: 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) > f=f allows archivers to convert text quoted with leading < into HTML >
, 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".
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). > 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 instead of 
 for f=f messages
(since  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.  is not declared in
> . 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
> 
 in help texts and use styles like max-width to maintain a reasonable
> line width.

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 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/