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
can come up in technical discussions among tech-savvy persons such as here
on kde-core-devel. (We are not "most people".) Keep in mind that code is
usually displayed using a monospace font, too, and that e-mails on KDE
mailing lists are likely to contain code snippets.
I see no technical advantage in using a proportional font by default, only
drawbacks. (And for those who want it, a JavaScript-heavy interface such as
HyperKitty could make it switchable with one click and/or keypress. E.g.,
in KNode, you just push the X button on your keyboard to switch instantly.
Wheeras Trojitá just always uses a monospace font for plaintext (non-HTML)
e-mail.)
And finally, HyperKitty is largely unusable without
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.
Such browsers are used in various accessibility-related contexts, as well
as in emergency situations. E.g., what if KDE Plasma fails to start up for
you, you are stuck in text mode, and you are looking for a solution on KDE
mailing lists using lynx?
And the JavaScript-heavy stuff does not just require any JavaScript, but
tends to require a very recent browser, refusing to work even on maintained
LTS branches of browsers, such as QtWebEngine LTS (which is public and FOSS
unlike the rest of Qt LTS). Some websites have already started breaking on
QtWebEngine 5.15 LTS, e.g.:
* the Nextcloud PDF viewer:
https://github.com/nextcloud/files_pdfviewer/issues/684
* Discourse:
https://forum.manjaro.org/t/new-version-of-discourse-dropped-support-for-qtwebengine-5-15-lts/132543
The reasons why they stopped working are pretty spurious in both cases:
Nextcloud could trivially (a one-line change) switch to the "legacy" branch
of PDF.js which is compatible with many more browsers than the default
build (and I also blame PDF.js for not making the "legacy" build the
default, the current default build is only suitable for bundling in, e.g.,
Firefox and NOT for the web!), and the stricter browser check in Discourse
appears to be entirely unnecessary (since it works when I adblock the
browser-detection script).
If the same were to happen with HyperKitty, that would be a particularly
serious issue for KDE mailing lists because Falkon is the official KDE
browser and currently stuck on QtWebEngine 5.15 LTS. (Moving to Qt 6 will
be needed to get a newer Chromium again, unless someone makes, e.g.,
QtWebEngine 6.2 LTS work with Qt 5 somehow.)
I do not see how or why it is unreasonable to expect something that has
worked without JavaScript for decades to keep working without JavaScript.
There are things for which it may be necessary, but displaying static
mailing list archives is not.
Broken links sound like a showstopper to me. […]
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
