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-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 990B51F626 for ; Mon, 13 Feb 2023 10:59:30 +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=Jfa+vRW3; dkim-atps=neutral Received: by mail-ej1-x629.google.com with SMTP id jg8so30839145ejc.6 for ; Mon, 13 Feb 2023 02:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=8DXHq3tjfYxLnHF0MQbIb6p3HHd0Bi1kLA/uupyhMgM=; b=Jfa+vRW3S92A11AV+F8y2ZWNlkAO+3T98oVxVhQH6Cd18tZofsKRi6ETp6zE5oGcks ypB/T/1tHGCcdogrn8ZlN1VwLM24+kEDTOjRe+pKQkx/jc0+YrsSo98Zc/gnhyDv5eL8 ijIZxYqj3/4rQIoznmNzozr6HzU9tCEimFXTgyUEKE7j9uS4cCeowG6CvGAOoSZH9Crd d47RFcotTqTlyeAFdMSKa1FYo4xzVdhO3yATE7TjxdPfbNqXwIA1JUDS94I2WGbdivKp nvsszHEYsNm8XPqM3pgfXZnhhHnAS8xvOn2V0eVxQZczSvoqCjenU1IR0ieNFpiLd5OF dBLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8DXHq3tjfYxLnHF0MQbIb6p3HHd0Bi1kLA/uupyhMgM=; b=R4IrtdsTiKhtvcBydTGhVDAME46bwQIdD1aWnOVMw3fhKEUw2uRl3/TLCltsuwC06W 9t7IMaBgeqU4Lk5MrjbwfW4G3h7SQA+AWEyGCpclcLFsLlUTV61iNlZqE6Itu7mYIxNZ EPsNRjVAAjD302p1jMQvtBYUqqoKOUkhrQIxSjux0noQv/jutGXyVaTjQaSYM8xzKIBg V1sPL4rdNqwX0xFWYwRwnWC2qVD4L/1c5A6nonjGZPxaHlZxAIET1DMRkTSAaJVcHK7n 6OJu+foGpr/Pow0520c/wHFd/MXmJyQw7ASzCRkctF1YU1fRwySej9g82VrMPQIzROmL UMWQ== X-Gm-Message-State: AO0yUKUP5dcQRmCpjDtXMKVVeTq0/ynD+EBWSQ8xahgbOofu7hCzhNLt Q4PiFlD+DL/uJHGGoUFSwWtiEhpLtt8= X-Google-Smtp-Source: AK7set/aurgKTqCBGylGE8vVQG6+fTmQ/kRUj76g2FdfMuAPf/ePmnrm5kIwAV1YjQaS5QXsL3LmRw== X-Received: by 2002:a17:907:7212:b0:8ac:8f3c:7f65 with SMTP id dr18-20020a170907721200b008ac8f3c7f65mr18075072ejc.48.1676285968322; Mon, 13 Feb 2023 02:59:28 -0800 (PST) Received: from m (dzcj40yf1208bw4dvw5vy-3.rev.dnainternet.fi. [2001:14ba:a08f:8f00:95b7:b819:6071:9662]) by smtp.gmail.com with ESMTPSA id c20-20020a50f614000000b004ac089bb600sm4587881edn.0.2023.02.13.02.59.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Feb 2023 02:59:27 -0800 (PST) Date: Mon, 13 Feb 2023 12:59:25 +0200 From: Charles Zhang To: meta@public-inbox.org Subject: Considerations about format=flowed support and web page responsiveness Message-ID: <20230213105925.6zccabv3yldniqam@m> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline List-Id: I'm glad to see that support for RFC 3676 (format=flowed) has been put into TODO.[1] I want to write down some ideas and questions about the implementation public-inbox might have. First I would like to state my position for format=flowed: It enables plain text emails to be reflowed by readers' email clients according to their preferences, which 1) enables reader softwares to reflow text to fit the display region not suitable for the convention of 72 characters per line, the most common beneficiary would be mobile phone users, and 2) enables proper quoting behaviour for deeply nested text (irrelevant for pure archiver like public-inbox). 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. I have done a quick survey on current mailing list archivers' support for f=f. Services that supports it include: Archiver software: MHonArc, Hypermail, (less notably) Apache Pony Mail Archive website: mail-archive.com (proprietary archiver?), spinics.net (mhonarc) These services simply remove the soft line breaks ( followed by CRLF). Browsers will do the typesetting as usual. (For the sake of completeness, need not be space, but configurable by the DelSp parameter in RFC 3676) 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". Services that don't support f=f include: Archiver software: Pipermail (GNU Mailman 2), HyperKitty (GNU Mailman 3), (less notably) ietf mailarch Archive website: groups.google.com, marc.info, narkive.com, (less notably) markmail.org These services appear to simply ignore f=f. They might or might not strip the trailing from generated HTML. Whether those spaces are visible to users (when selecting or copying text) depends on their CSS styles (white-space) and HTML white space collapsing rules. 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. 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.

[1] https://public-inbox.org/meta/20220901185829.30117-1-e@80x24.org/