Am Montag, 6. Februar 2023 02:28:19 CET schrieb Neal Gompa:
> Most people expect normal proportional fonts when reading mail, not
> monospaced text. Even my email client doesn't show email in monospaced
> text by default.

But using a proportional font breaks:
* complex indentation, as I had already mentioned,
* nicely aligned text tables,
* ASCII art drawings,
making mails using any of those display incorrectly. All those constructs=20
can come up in technical discussions among tech-savvy persons such as here=20=

on kde-core-devel. (We are not "most people".) Keep in mind that code is=20
usually displayed using a monospace font, too, and that e-mails on KDE=20
mailing lists are likely to contain code snippets.

I see no technical advantage in using a proportional font by default, only=20=

drawbacks. (And for those who want it, a JavaScript-heavy interface such as=20=

HyperKitty could make it switchable with one click and/or keypress. E.g.,=20
in KNode, you just push the X button on your keyboard to switch instantly.=20=

Wheeras Trojit=C3=A1 just always uses a monospace font for plaintext (non-HTM=
L)=20
e-mail.)

>> And finally, HyperKitty is largely unusable without=20
>> JavaScript. If you turn
>> off JavaScript, significant portions of the interface just do not work,
>> whereas Pipermail was completely free from client-side code. This is a
>> regression in browser compatibility and in accessibility. HyperKitty also
>> uses cookies, Pipermail does not.
>
> This is an unreasonable demand. Most of the internet does not function
> without JavaScript today.

Most of the Internet is broken, so let us break our site too?

There are browsers that by design do not handle JavaScript, such as lynx.=20
Such browsers are used in various accessibility-related contexts, as well=20
as in emergency situations. E.g., what if KDE Plasma fails to start up for=20=

you, you are stuck in text mode, and you are looking for a solution on KDE=20=

mailing lists using lynx?

And the JavaScript-heavy stuff does not just require any JavaScript, but=20
tends to require a very recent browser, refusing to work even on maintained=20=

LTS branches of browsers, such as QtWebEngine LTS (which is public and FOSS=20=

unlike the rest of Qt LTS). Some websites have already started breaking on=20=

QtWebEngine 5.15 LTS, e.g.:
* the Nextcloud PDF viewer:=20
https://github.com/nextcloud/files_pdfviewer/issues/684
* Discourse:=20
https://forum.manjaro.org/t/new-version-of-discourse-dropped-support-for-qtwe=
bengine-5-15-lts/132543

The reasons why they stopped working are pretty spurious in both cases:=20
Nextcloud could trivially (a one-line change) switch to the "legacy" branch=20=

of PDF.js which is compatible with many more browsers than the default=20
build (and I also blame PDF.js for not making the "legacy" build the=20
default, the current default build is only suitable for bundling in, e.g.,=20=

Firefox and NOT for the web!), and the stricter browser check in Discourse=20=

appears to be entirely unnecessary (since it works when I adblock the=20
browser-detection script).

If the same were to happen with HyperKitty, that would be a particularly=20
serious issue for KDE mailing lists because Falkon is the official KDE=20
browser and currently stuck on QtWebEngine 5.15 LTS. (Moving to Qt 6 will=20
be needed to get a newer Chromium again, unless someone makes, e.g.,=20
QtWebEngine 6.2 LTS work with Qt 5 somehow.)

I do not see how or why it is unreasonable to expect something that has=20
worked without JavaScript for decades to keep working without JavaScript.=20
There are things for which it may be necessary, but displaying static=20
mailing list archives is not.

>> Broken links sound like a showstopper to me. [=E2=80=A6]
>
> openSUSE developed a way to map legacy discussions on mlmmj to
> HyperKitty, while Fedora just retained the old Pipemail static pages.
> Either works.

So either solution would need to be implemented on KDE mailing lists too.

        Kevin Kofler