Re: Wer nutzt noch Fax und für was?

[Andreas Kohlbach]

On Fri, 11 Nov 2022 20:24:25 +0100, Arno Welzel wrote:
>
> Andreas Kohlbach, 2022-11-07 06:47:
>
>> Man muss beim Brief immer noch zum Briefkasten, und ggf. eine feuchte
>> Zunge haben und das Abschlabbern lieben.
>
> Oder das Porto einfach als Code auf den Briefumschlag schreiben:
>
> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>

Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt sie
dagegen). Was für ein Müll.

So geht (in lynx) CTRL-g nicht mal zum Abbrechen. Ich muss den Browser
beenden.

Kann das mal jemand mit seinem Textbrowser verifizieren?

X'post F'up de.comm.software.browser.misc.
--
Andreas

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 12.11.2022 um 06:27:04:

> On Fri, 11 Nov 2022 20:24:25 +0100, Arno Welzel wrote:

>> Oder das Porto einfach als Code auf den Briefumschlag schreiben:
>>
>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>

> Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
> Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt sie
> dagegen). Was für ein Müll.

Sorry, aber in meinen Augen ist es kein Zeichen von Müll, wenn eine Webseite
in einem Textbrowser nicht funktioniert. Textbrowser spielen eine so
untergeordnete Rolle, dass ich es nachvollziehen kann, dass ein Entwickler die
nicht auch noch berücksichtigen will. Er hat schon genug damit zu tun, die
Seite auf allen möglichen Geräten vom Uralt-Smartphone bis zum 4K-32-Zöller
gut aussehen zu lassen.

> So geht (in lynx) CTRL-g nicht mal zum Abbrechen. Ich muss den Browser
> beenden.
>
> Kann das mal jemand mit seinem Textbrowser verifizieren?

Bin gespannt, wer hier überhaupt einen Textbrowser nutzt. Warum tut man sich
sowas überhaupt an?

Gruß

Michael

[Michael Landenberger]

"Michael Landenberger" schrieb am 12.11.2022 um 09:47:40:

> Bin gespannt, wer hier überhaupt einen Textbrowser nutzt. Warum tut man sich
> sowas überhaupt an?

Nachtrag: der von Arno gepostete Link ist für mobile Geräte gedacht, speziell
für Smartphones. Die Frage muss also lauten: wer nutzt auf einem *Smartphone*
einen Textbrowser? Ich vermute mal, niemand.

Gruß

Michael

[Axel Berger]

Michael Landenberger wrote:
> Sorry, aber in meinen Augen ist es kein Zeichen von Müll, wenn eine Webseite
> in einem Textbrowser nicht funktioniert.

Doch, ist es, eindeutig. Andreas hat nicht moniert er könne mit dem
Inhalt nichts anfangen und graphische Darstellungen nicht erkennen,
sondern Fehlfunktionen der Browser. (Sollte auch nicht passieren, Fehler
gehören abgefangen.)
Das ist eindeutig fehlerhafter, nicht normgerechter, invalider Code, der
von der aufgeblasenen Fehlerkorrektur- und Ratefunktion anderer Browser
abgefangen wird.

Übrigens ist genau dieser Versuch, aus eindeutig kaputtem invaliden
Seitencode noch etwas herauszulesen, das Haupteinfallstor für
Schädlinge.

> Bin gespannt, wer hier überhaupt einen Textbrowser nutzt. Warum tut man sich
> sowas überhaupt an?

Texte kann man vorlesen, Bilder nicht.


--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

[Diedrich Ehlerding]

Andreas Kohlbach meinte:

>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
>
> Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
> Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt
> sie dagegen). Was für ein Müll.
>
> So geht (in lynx) CTRL-g nicht mal zum Abbrechen. Ich muss den Browser
> beenden.
>
> Kann das mal jemand mit seinem Textbrowser verifizieren?

Geht hier mit lynx auch nicht. lynx-2.8.9~dev.16-bp153.1.17.x86_64
"lynx https://www.deutschepost.de/de/m/mobile-briefmarke.htm" bleibt
stehen im Zustanbd "http-Request gesendet, warte auf Antwort". ^g tut
nichts, ^c beendet lynx. w3m bleibt ebenfalls stehen mit
"www.deutschepost.de contacted. Waiting for reply...". Auch wget hängt,
curl sagt:
diedrich@diedrich:~> curl https://www.deutschepost.de/de/m/mobile-briefmarke.html
<!DOCTYPE html> <html> <head> <meta http-equiv="refresh"
content="0;URL=/de/toolbar/errorpages/fehlermeldung.html" />
<title>Not Found</title> </head> <body> <h2>404- Not Found</h2>
</body>

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Michael Landenberger]

"Axel Berger" schrieb am 12.11.2022 um 10:20:33:

> Das ist eindeutig fehlerhafter, nicht normgerechter, invalider Code, der
> von der aufgeblasenen Fehlerkorrektur- und Ratefunktion anderer Browser
> abgefangen wird.

Eindeutig nicht normgerecht? Hast du den Code der Seite analysiert?

> Texte kann man vorlesen, Bilder nicht.

Es gibt auch grafische Browser, die Texte vorlesen können. Aber speziell beim
OP glaube ich nicht, dass er auf die Vorlesefunktion angewiesen ist.

Gruß

Michael

[Michael Landenberger]

"Diedrich Ehlerding" schrieb am 12.11.2022 um 10:50:01:

> Geht hier mit lynx auch nicht. lynx-2.8.9~dev.16-bp153.1.17.x86_64
> "lynx https://www.deutschepost.de/de/m/mobile-briefmarke.htm" bleibt
> stehen im Zustanbd "http-Request gesendet, warte auf Antwort". ^g tut
> nichts, ^c beendet lynx. w3m bleibt ebenfalls stehen mit
> "www.deutschepost.de contacted. Waiting for reply...". Auch wget hängt,
> curl sagt:
> diedrich@diedrich:~> curl
> https://www.deutschepost.de/de/m/mobile-briefmarke.html
> <!DOCTYPE html> <html> <head> <meta http-equiv="refresh"
> content="0;URL=/de/toolbar/errorpages/fehlermeldung.html" />
> <title>Not Found</title> </head> <body> <h2>404- Not Found</h2>
> </body>

Hört sich weder nach einem Fehler im Seiten-Code, noch nach einem Fehler in
lynx an. Vielmehr tippe ich auf einen Serverfehler, vielleicht im Zusammenhang
mit einem User-Agent-String, aus dem das Skript auf dem Server auf einen
Browser schließt, den es nicht unterstützen will. Es versucht dann, Inhalte
auszuliefern, die es seinerseits nicht findet.

Grafische Browser wie Chrome und Firefox (jeweils Desktop- und Android-Version
getestet) sowie Edge zeigen die Seite einwandfrei an. Zusätzlich haben diese
Browser im Gegensatz zu Textbrowsern auch keine Probleme damit, das animierte
Erklär-SVG und das Erklärvideo wiederzugeben.

Gruß

Michael

[Franklin Schiftan]

*.htm bringt hier auch mit einem graphischen Browser ein 'not found'

*.html funktioniert aber einwandfrei.

> Michael

.... und tschüss

Franklin

[Franklin Schiftan]

Am 2022-11-12 um 09:50 schrieb Michael Landenberger:
> "Michael Landenberger" schrieb am 12.11.2022 um 09:47:40:
>
>> Bin gespannt, wer hier überhaupt einen Textbrowser nutzt. Warum tut man sich
>> sowas überhaupt an?
>
> Nachtrag: der von Arno gepostete Link ist für mobile Geräte gedacht, speziell
> für Smartphones.

Wie kommst Du darauf?

[Axel Berger]

Franklin Schiftan wrote:
> Wie kommst Du darauf?

> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
^^^

[Dennis Grevenstein]

In de.alt.folklore.computer Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>
> ACK. Die Klempner der DHL- und artverwandten Seiten testen ihren Code
> gerade mal gegen den jeweils neuesten Web-Browser, nur nicht zuviel. Und
> sie binden einige Datenschnüffler ein.
>
> Falls man eine Mail an DHL schreibt und man tatsächlich eine Antwort
> erhalten sollte, dann ist die Email sicher in HTML-only.
>
> Die haben Neuland nicht verstanden. Hermes kann das erheblich besser.

Ich habe den Verdacht, das ist Absicht, damit bloss keine
Mensch-zu-Mensch Interaktion stattfinden muss, die am Ende
vielleicht noch Geld kostet.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser
gate. All those moments will be lost in time, like tears in rain."

[Franklin Schiftan]

Am 2022-11-12 um 12:53 schrieb Axel Berger:
> Franklin Schiftan wrote:
>> Wie kommst Du darauf?
>
>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
> ^^^
>

Oh, danke, das habe ich doch glatt übersehen (und wusste ehrlich gesagt
auch nicht, dass das darüber gesteuert wird - aber nun bin ich wieder
ein wenig schlauer ...).

.... und tschüss

Franklin

[Diedrich Ehlerding]

Michael Landenberger meinte:

> Hört sich weder nach einem Fehler im Seiten-Code, noch nach einem
> Fehler in lynx an. Vielmehr tippe ich auf einen Serverfehler,
> vielleicht im Zusammenhang mit einem User-Agent-String, aus dem das
> Skript auf dem Server auf einen Browser schließt, den es nicht
> unterstützen will.

Ja, ich vermute da auch eine User-Agent-Weiche auf dem Server. Man
müsste sich ansehen, was lynx und w3m und wget bekommen - curl bekommt
ja eine Fehlermeldung ("404 Not found"). Eigentlich hätte da aber die
Seite "Fehlermeldung.html" angezeigt werden sollen, aber die gibts wohl
nicht.

lynx bleibt auch stehen, wenn ich die URL aus dem "refresh" direkt
eingebe, und curl zeigt dasselbe an wie bei der ursprünglichen Frage.
Ich vermute also, dass lynx in dieser refresh-Schleife gefangen ist und
immer wieder dasselbe anzeigen soll. In der Tat zeigt strace auf den
lynx-Prozess eine endlose Schleife:

select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=100000}) = 0 (Timeout)
select(1, [0], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=100000}) = 0 (Timeout)
select(1, [0], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=100000}) = 0 (Timeout)
select(1, [0], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)

[Andreas Kohlbach]

On Sat, 12 Nov 2022 10:20:33 +0100, Axel Berger wrote:
>
> Michael Landenberger wrote:
>> Sorry, aber in meinen Augen ist es kein Zeichen von Müll, wenn eine Webseite
>> in einem Textbrowser nicht funktioniert.
>
> Doch, ist es, eindeutig. Andreas hat nicht moniert er könne mit dem
> Inhalt nichts anfangen und graphische Darstellungen nicht erkennen,
> sondern Fehlfunktionen der Browser. (Sollte auch nicht passieren, Fehler
> gehören abgefangen.)
> Das ist eindeutig fehlerhafter, nicht normgerechter, invalider Code, der
> von der aufgeblasenen Fehlerkorrektur- und Ratefunktion anderer Browser
> abgefangen wird.

Ja, ich sehe auch lynx hier als Schuldigen. Selbst falls die Seite
schludrig "programmiert" wurde.

[...]

>> Bin gespannt, wer hier überhaupt einen Textbrowser nutzt. Warum tut man sich
>> sowas überhaupt an?

Auch Leute, die (heute) schwache Hardware haben. Viele der heutigen
Webseiten lasten die CPU mehr als 100% aus und betrinken sich am
[knappen] RAM.

Auch wenn mein "neuer" Rechner relativ gut mit aufgeblasenen Seiten
klarkommt, habe ich kein Einsehen damit, warum ich Geld ausgeben soll,
nur um heutige Webseiten sehen zu können, die zudem mit Werbung
überfrachtet sind, die wohl im Wesentlichen zur Verschwendung von
Leistung des Computers beitragen.

Ich gebe kein Geld aus, um Werbung sehen zu dürfen.
--
Andreas

[Andreas Kohlbach]

On Sat, 12 Nov 2022 11:43:20 +0100, Michael Landenberger wrote:
>
> "Diedrich Ehlerding" schrieb am 12.11.2022 um 10:50:01:
>
>> Geht hier mit lynx auch nicht. lynx-2.8.9~dev.16-bp153.1.17.x86_64
>> "lynx https://www.deutschepost.de/de/m/mobile-briefmarke.htm" bleibt
>> stehen im Zustanbd "http-Request gesendet, warte auf Antwort". ^g tut
>> nichts, ^c beendet lynx. w3m bleibt ebenfalls stehen mit
>> "www.deutschepost.de contacted. Waiting for reply...". Auch wget hängt,
>> curl sagt:
>> diedrich@diedrich:~> curl
>> https://www.deutschepost.de/de/m/mobile-briefmarke.html
>> <!DOCTYPE html> <html> <head> <meta http-equiv="refresh"
>> content="0;URL=/de/toolbar/errorpages/fehlermeldung.html" />
>> <title>Not Found</title> </head> <body> <h2>404- Not Found</h2>
>> </body>
>
> Hört sich weder nach einem Fehler im Seiten-Code, noch nach einem Fehler in
> lynx an. Vielmehr tippe ich auf einen Serverfehler, vielleicht im Zusammenhang
> mit einem User-Agent-String, aus dem das Skript auf dem Server auf einen
> Browser schließt, den es nicht unterstützen will. Es versucht dann, Inhalte
> auszuliefern, die es seinerseits nicht findet.

[Nachtrag]

Es ist vermutlich einzig und allein der User-Agent.

| ~$ wget --spider --user-agent="Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
| https://www.deutschepost.de/de/m/mobile-briefmarke.html
| Spider mode enabled. Check if remote file exists.
| --2022-11-12 21:00:57--
| Resolving www.deutschepost.de (www.deutschepost.de)... 104.107.13.110, 2600:140a:a000:49c::4213, 2600:140a:a000:498::4213
| Connecting to www.deutschepost.de (www.deutschepost.de)|104.107.13.110|:443... connected.
| HTTP request sent, awaiting response... 200 OK
| Length: unspecified [text/html]

Ich hatte es auch mit "Googlebot" versucht, mit dem es interessanterweise
nicht funktioniert.
--
Andreas

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 13.11.2022 um 01:53:34:

> On Sat, 12 Nov 2022 10:20:33 +0100, Axel Berger wrote:

>> Das ist eindeutig fehlerhafter, nicht normgerechter, invalider Code, der
>> von der aufgeblasenen Fehlerkorrektur- und Ratefunktion anderer Browser
>> abgefangen wird.

> Ja, ich sehe auch lynx hier als Schuldigen.

Axel meint den Code der Seite, nicht den von lynx.

>>> Bin gespannt, wer hier überhaupt einen Textbrowser nutzt. Warum tut man
>>> sich sowas überhaupt an?

> Auch Leute, die (heute) schwache Hardware haben. Viele der heutigen
> Webseiten lasten die CPU mehr als 100% aus und betrinken sich am
> [knappen] RAM.

Heutige Webseiten lasten CPUs von 1995 vielleicht voll aus, aber nicht CPUs
aus diesem Jahrtausend. Mein schwächster Rechner ist einer mit Pentium J2900
(einer Atom-CPU), der zeigt die Seite und die meisten anderen einwandfrei und
in akzeptabler Geschwindigkeit an. Die CPU wird dabei nur während des
Renderings beansprucht, wenn das einmal erledigt ist, dreht sie Däumchen. Und
das obwohl der Pentium J2900 nur einen Bruchteil der Leistung meines Brot-
und Butter-Rechners (AMD Ryzen 5 3600x) liefert:
<https://www.cpubenchmark.net/compare/2173vs3494/Intel-Pentium-J2900-vs-AMD-Ryzen-5-3600X>

> Auch wenn mein "neuer" Rechner relativ gut mit aufgeblasenen Seiten
> klarkommt, habe ich kein Einsehen damit, warum ich Geld ausgeben soll,
> nur um heutige Webseiten sehen zu können, die zudem mit Werbung
> überfrachtet sind, die wohl im Wesentlichen zur Verschwendung von
> Leistung des Computers beitragen.

Werbeblocker existieren. Aber vermutlich nicht für lynx.

> Ich gebe kein Geld aus, um Werbung sehen zu dürfen.

Ich auch nicht. Ich sehe trotzdem keine.

Gruß

Michael

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 13.11.2022 um 01:58:10:

> Aber in lynx dient CTRL-g zum Abbrechen des Ladens/Renderns der aktuellen
> URL. Das funktioniert nicht.

Bei anderen scheint das funktioniert zu haben.

> Also auch Fehler in lynx.

Oder eine zu (alters-)schwache CPU, die lynx so auslastet, dass sie nicht
zusätzlich noch Benutzereingaben verarbeiten kann.

Gruß

Michael

[Axel Berger]

Michael Landenberger wrote:
> Heutige Webseiten lasten CPUs von 1995 vielleicht voll aus, aber
> nicht CPUs aus diesem Jahrtausend.

Nach spätestens drei Jahren soll man bekanntlich sowieso alles
wegschmeißen. Es gibt aber auch andere Gründe. Tablets für unverkleinrte
A4-Seiten sind selten. Ich fand eines von Trekstor, bei dem schon vor
dem Kauf etliche Kundenkritiken die schwache Rechenleistung monierten.
Ich nutze es vor allem zum Lesen von PDF und Zeitungsseiten und Bloat
wird dort sehr spürbar.

[Arno Welzel]

Andreas Kohlbach, 2022-11-12 06:27:

> On Fri, 11 Nov 2022 20:24:25 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach, 2022-11-07 06:47:
>>
>>> Man muss beim Brief immer noch zum Briefkasten, und ggf. eine feuchte
>>> Zunge haben und das Abschlabbern lieben.
>>
>> Oder das Porto einfach als Code auf den Briefumschlag schreiben:
>>
>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
>
> Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
> Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt sie
> dagegen). Was für ein Müll.

Lynx und w3m wird von der Zielgruppe der Post mutmasslich so gut wie gar
nicht genutzt und erst recht nicht getestet mangels Bedarf. Wozu auch
etwas testen, was dann von 0,000000001% aller Nutzer verwendet wird?

> So geht (in lynx) CTRL-g nicht mal zum Abbrechen. Ich muss den Browser
> beenden.

Hier bleibt Lynx beim Verbindungsaufbau hängen, genauso wie wget oder
curl. Ich vermute, die haben irgendeine kaputte Firewall, die derlei
Anfragen als Angriff einstuft.


--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Ralf Kiefer, 2022-11-12 14:42:

> Andreas Kohlbach wrote:
>
>> Hätte ich gerne angeschaut, aber was für eine Scheißseite.
>

> ACK. Die Klempner der DHL- und artverwandten Seiten testen ihren Code
> gerade mal gegen den jeweils neuesten Web-Browser, nur nicht zuviel. Und
> sie binden einige Datenschnüffler ein.
>
> Falls man eine Mail an DHL schreibt und man tatsächlich eine Antwort
> erhalten sollte, dann ist die Email sicher in HTML-only.
>
> Die haben Neuland nicht verstanden. Hermes kann das erheblich besser.

Hermes bekommt dafür den eigentlichen Dienst der Postzustellung nicht
hin. Wenn mir jemand etwas via Hermes schicken will, kann ich davon
ausgehen, dass es in 3 von 4 Fällen nicht ankommt.

[Axel Berger]

Arno Welzel wrote:
> Wozu auch
> etwas testen, was dann von 0,000000001% aller Nutzer verwendet wird?

Es ist vollkommen unötig, irgendwas zu testen oder gar zu "unterstützen"
wie in den Popup Fehlermeldungen immer steht. die einzige Pflicht des
Autors ist sauberer, korrekter, valider und fehlerfreier Code. Was
Browser daraus machen, ist dann alein deren Problem.

Leider haben heute alle Browser riesige aufgeblähte Programmteile für
den Versuch, auch aus dem größten invaliden Müll noch die Intention des
Autors zu erraten. Sowas muß dann natürlich im Einzelfall und mit allen
getestet werden.

Warum es einfacher sein soll, mit Riesenaufwand auszuprobieren, welche
Fehler noch toleriert werden, anstatt gleich fehlerfrei zu schreiben,
verstehe ich nicht. Validatoren existieren von Anfang an, sind eine
große Hilfe und der erste Schritt jeder Fehlersuche.

[Axel Berger]

Arno Welzel wrote:
> Wenn mir jemand etwas via Hermes schicken will, kann ich davon

> ausgehen, dass es in 3 von 4 Fällen nicht ankommt.

Das hängt natürlich sehr vom lokalen Zusteller vor Ort ab. Meine
Erfahrungen sind vor und nach dem Umzug durchgehend anders. Hilft dir
natürlich gar nichts. Ich glaube übrigens fest an die Wirkung eines
gelegentlichen Trinkgeldes.

[Markus Elsken]

Moin!

Am 13.11.22 um 15:38 schrieb Arno Welzel:

> Hermes bekommt dafür den eigentlichen Dienst der Postzustellung nicht
> hin. Wenn mir jemand etwas via Hermes schicken will, kann ich davon
> ausgehen, dass es in 3 von 4 Fällen nicht ankommt.

Hängt vom Zusteller vor Ort ab. Mit den aktuellen hier habe ich gerade
Glück, aber der vorherige war eine Katastrophe. Der Gipfel war ein vor
die Haustür (!) gestelltes Paket samt Fälschung der Unterschrift eines
Nachbarn, der zu dem Zeitpunkt im Urlaub war. Gab einigen Ärger und wir
bekamen einen neuen Zusteller.
Das mit dem Paket einfach irgendwo von der Strasse gut sichtbar (!)
abzustellen und das als zugestellt zu betrachten haben auch schon Amazon
und DPD geschafft, letzterer war dann für den Verlust eines 2500,-€
Paketes verantwortlich. Gab einigen Trubel, zum Glück hatte der Fahrer
gleich das Geständnis in den Briefkasten geworfen "Paket in
Garageneinfahrt". Keine Abstellerlaubnis, Pech gehabt.

mfg Markus

[Arno Welzel]

Axel Berger, 2022-11-13 16:03:

> Arno Welzel wrote:
>> Wozu auch
>> etwas testen, was dann von 0,000000001% aller Nutzer verwendet wird?
>
> Es ist vollkommen unötig, irgendwas zu testen oder gar zu "unterstützen"

Falsch.

> Leider haben heute alle Browser riesige aufgeblähte Programmteile für
> den Versuch, auch aus dem größten invaliden Müll noch die Intention des
> Autors zu erraten. Sowas muß dann natürlich im Einzelfall und mit allen
> getestet werden.

Ob ein Browser das vorgesehene Ergebnis liefert, sollte man schon testen
- zumindest mit den Browsern, von denen man bei der Zielgruppe ausgehen
kann.

> Warum es einfacher sein soll, mit Riesenaufwand auszuprobieren, welche
> Fehler noch toleriert werden, anstatt gleich fehlerfrei zu schreiben,
> verstehe ich nicht. Validatoren existieren von Anfang an, sind eine
> große Hilfe und der erste Schritt jeder Fehlersuche.

Auch fehlerfreies HTML wird *nicht* überall korrekt dargestellt. Ohne
Tests geht es nicht, wenn man das nicht nur als Hobby-Bastler privat
machen will.

[Michael Landenberger]

"Axel Berger" schrieb am 13.11.2022 um 12:16:42:

> Michael Landenberger wrote:

>> Heutige Webseiten lasten CPUs von 1995 vielleicht voll aus, aber
>> nicht CPUs aus diesem Jahrtausend.

> Nach spätestens drei Jahren soll man bekanntlich sowieso alles
> wegschmeißen.

Gegen diese "Regel" verstoße ich unablässig und mit zunehmender Freude.

> Es gibt aber auch andere Gründe. Tablets für unverkleinrte
> A4-Seiten sind selten.

Stört mich nicht. Ich brauche kein Tablet. Als ich mich mal für eine Reise
nach Tablets umgesehen und dabei alle möglichen Geräte vom Billig-Tablet bis
zum iPad Pro ausprobiert habe, wurde es am Ende ein kleines, handliches
Notebook. Es ist ein gewaltiger Ergonomievorteil, wenn Display, Tastatur und
"Maus" (hier: Touchpad) separate Komponenten sind, anstatt dass das Display
allein alle diese Aufgaben übernimmt (und jeweils die eine Funktion den
anderen Platz wegnimmt). Außerdem ist es der Ergonomie sehr zuträglich, dass
es das Scharnier zwischen Display und Tastatur erlaubt, das Display stufenlos
und unabhängig von der Standfläche in jedem beliebigen Winkel zu neigen.
Apropos Standfläche: ein Notebook kann man hinstellen und muss es nicht die
ganze Zeit in der Hand halten. Das macht den Nachteil des etwas höheren
Gewichts mehr als wett. Weiterhin empfand ich es als Vorteil, dass das
Notebook mit allen möglichen Anschlüssen ausgestattet war, die einem Tablet in
der Regel fehlen, wie z. B. HDMI, diverse USB-3-Schnittstellen oder auch
Gigabit-Ethernet. War mir alles schon sehr von Nutzen.

Bleib mir weg mit Tablets. Bedienungskonzepte, die allein auf ein
(Touch-)Display als Ein- und Ausgabegerät setzen, haben vielleicht bei
Smartphones ihre Berechtigung, aber bei allem, was größer ist, sind sie fehl
am Platze.

Gruß

Michael

[Michael Landenberger]

"Axel Berger" schrieb am 13.11.2022 um 16:03:15:

> Warum es einfacher sein soll, mit Riesenaufwand auszuprobieren, welche
> Fehler noch toleriert werden, anstatt gleich fehlerfrei zu schreiben,

Nochmal die Frage, denn du hast sie bisher nicht beantwortet: woher weißt du,
dass der Code der Post-Seite fehlerhaft ist? Hast du ihn genau unter die Lupe
genommen?

> Validatoren existieren von Anfang an, sind eine
> große Hilfe und der erste Schritt jeder Fehlersuche.

Eine fehlende Eignung für Textbrowser ist kein Fehler, insbesondere nicht bei
Seiten, deren Bedienkonzept auf eine grafische Oberfläche ausgelegt ist. Es
wird auch niemand Programme wie Photoshop, Corel Draw oder den VLC Player als
fehlerhaft ansehen, nur weil sie in einem Konsolenfenster nicht laufen.

Gruß

Michael

[Marc Olschok]

In de.comm.software.browser.misc Andreas Kohlbach <a...@spamfence.net> wrote:
> On Fri, 11 Nov 2022 20:24:25 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach, 2022-11-07 06:47:
>>
>>> Man muss beim Brief immer noch zum Briefkasten, und ggf. eine feuchte
>>> Zunge haben und das Abschlabbern lieben.
>>
>> Oder das Porto einfach als Code auf den Briefumschlag schreiben:
>>
>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
>
> Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
> Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt sie
> dagegen). Was für ein Müll.
>

> So geht (in lynx) CTRL-g nicht mal zum Abbrechen. Ich muss den Browser
> beenden.
>

> Kann das mal jemand mit seinem Textbrowser verifizieren?

Ich bekomme bereits bein Aufruf von https://www.deutschepost.de/ nach
dem Verbindungsaufbau gar keinen Response (probiert mit lynx, w3m, wget).
Mit Midori unter Android wird mir die Seite
https://www.deutschepost.de/en/home.html ausgeliefert.
Direkter Aufruf dieser Seite mit obigen drei Textbrowsern ergibt
ebenfalls keinen Response.

Unprofessioneller Scheißdreck. Die Generation Klickibunti ruiniert das
Web weiterhin.

--
M.O.

[Axel Berger]

Arno Welzel wrote:
> Auch fehlerfreies HTML wird *nicht* überall korrekt dargestellt.

Zugegeben, in etlichen meinr Seiten sind noch die Workarounds für IE5
drin. Aber gibt es wirklich heute noch Browser, die korrekten, validen
und fehlerfreien Code nicht zeigen? Kann ich mir schwer vorstellen.
Damit meine ich natürlich nicht irgendwo angekündigte Features, die
vielleicht mal nächstes Jahr in die Betaphase gehen könnten.

[Axel Berger]

Michael Landenberger wrote:
> Stört mich nicht. Ich brauche kein Tablet.

Schön für Dich. Entweder Du kannst Dir dutzende Fachzeitschriften im Abo
auf Papier leisten oder Du liest nicht. Für mich war es eine Erlösung,
als es die großen Tablets nach vielen Jahren Wartens endlich gab.

[Arno Welzel]

Axel Berger, 2022-11-13 22:40:

> Arno Welzel wrote:
>> Auch fehlerfreies HTML wird *nicht* überall korrekt dargestellt.
>
> Zugegeben, in etlichen meinr Seiten sind noch die Workarounds für IE5
> drin. Aber gibt es wirklich heute noch Browser, die korrekten, validen
> und fehlerfreien Code nicht zeigen? Kann ich mir schwer vorstellen.

Es geht nicht um "nicht zeigen" sondern *korrekt* zeigen. Und ja, ich
habe schon erlebt, dass völlig korrektes HTML samt korrektem CSS mit
Vivaldi und Chrome wie erwartet angezeigt wurde und bei Firefox nicht.
Und ja, das war ein Bug von Firefox, der bald behoben war, aber es war
halt auch ein Beispiel, warum man eben testen muss.

Auch erinnere ich mich daran, dass bei <select>-Elementen Firefox unter
Windows recht eigenwillig damit war, Farben für <optgroup> auszuwählen,
was auch zu seltsamen Effekten führen konnte, wenn man eigentlich eine
einheitlich Gestaltung per CSS vorgesehen hat. Die Lösung war dann, eine
minimal abweichende Farbe für <optgroup> festzulegen, damit Firefox sich
auch genötigt sah, die Vorgabe zu beachten und nicht einfach irgendeine
eigene Logik anzuwenden:

<https://bugzilla.mozilla.org/show_bug.cgi?id=1394491>

In meinem Fall habe ich dann für <optgroup> die Regel "background-color:
#fffffe;" eingetragen, damit der Hintergrund wirklich weiß erscheint
(die minimale Abweichung beim Blau-Anteil ist optisch nicht wahrnembar)
und nicht das, was Firefox gerade glaubt, anzeigen zu müssen, weil die
Farbe nicht anders ist, als bei den <option>-Elementen.

[Arno Welzel]

Marc Olschok, 2022-11-13 21:04:

> In de.comm.software.browser.misc Andreas Kohlbach <a...@spamfence.net> wrote:

[...]

> Ich bekomme bereits bein Aufruf von https://www.deutschepost.de/ nach
> dem Verbindungsaufbau gar keinen Response (probiert mit lynx, w3m, wget).
> Mit Midori unter Android wird mir die Seite
> https://www.deutschepost.de/en/home.html ausgeliefert.
> Direkter Aufruf dieser Seite mit obigen drei Textbrowsern ergibt
> ebenfalls keinen Response.
>
> Unprofessioneller Scheißdreck. Die Generation Klickibunti ruiniert das
> Web weiterhin.

Das Web *ist* "klickibunti", schon sehr lange und nicht erst seit HTML5.

[Andreas Kohlbach]

On Sun, 13 Nov 2022 15:37:45 +0100, Arno Welzel wrote:
>
> Andreas Kohlbach, 2022-11-12 06:27:

>
>>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
>>
>> Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
>> Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt sie
>> dagegen). Was für ein Müll.
>
> Lynx und w3m wird von der Zielgruppe der Post mutmasslich so gut wie gar
> nicht genutzt und erst recht nicht getestet mangels Bedarf. Wozu auch
> etwas testen, was dann von 0,000000001% aller Nutzer verwendet wird?

Dann könnten die Entwickler den Support gleich einstellen.

Deine Zahl halte ich btw. für zu weit hergeholt.

>> So geht (in lynx) CTRL-g nicht mal zum Abbrechen. Ich muss den Browser
>> beenden.
>
> Hier bleibt Lynx beim Verbindungsaufbau hängen, genauso wie wget oder
> curl. Ich vermute, die haben irgendeine kaputte Firewall, die derlei
> Anfragen als Angriff einstuft.

Mittlerweile habe ich herausgefunden, dass es am User-Agenten liegt. Gebe
ich lynx einen anderen vor, kann man besagte Seite gut lesen.

Hmm, wenn wget oder curl auch hängen bleiben, hat lynx doch keine
Schuld. Entweder dann alle, oder keiner, falls das Hängenbleiben das
richtige Verhalten bei der offenbar kaputten Antwort des Webservers ist.
--
Andreas

[Michael Landenberger]

"Axel Berger" schrieb am 13.11.2022 um 22:42:41:

> Michael Landenberger wrote:

>> Stört mich nicht. Ich brauche kein Tablet.

> Schön für Dich. Entweder Du kannst Dir dutzende Fachzeitschriften im Abo
> auf Papier leisten oder Du liest nicht.

Wie kommst du darauf? Ich lese sehr wohl. Auf besagtem Laptop. Oder auf dem
Smartphone (ideal in Bus oder Bahn).

Davon abgesehen, sind digitale Abos nicht nennenswert billiger als die für
Zeitschriften auf Papier, jedenfalls bei den Zeitschriften, die ich regelmäßig
lese.

Gruß

Michael

[Arno Welzel]

Andreas Kohlbach, 2022-11-14 07:09:

> On Sun, 13 Nov 2022 09:04:02 +0100, Michael Landenberger wrote:
[...]

>> Axel meint den Code der Seite, nicht den von lynx.
>

> Ich hatte Axel verstanden, dass er auch lynx die Schuld gibt. Browser
> sollten (heute) nicht mehr abstürzen oder hängenbleiben, egal was man
> ihnen vorwirft.

Das tut Lynx auch nicht. Er versucht nur eine Verbindung aufzubauen und
bekommt sie nicht. Solange nicht klar ist, ob die Verbindung möglich ist
oder nicht, kann man Lynx halt nicht anderweitig benutzen sondern nur
mit Ctrl+C beenden.

[Arno Welzel]

Andreas Kohlbach, 2022-11-14 07:22:

> On Sun, 13 Nov 2022 15:37:45 +0100, Arno Welzel wrote:
>>
>> Andreas Kohlbach, 2022-11-12 06:27:
>>
>>>> <https://www.deutschepost.de/de/m/mobile-briefmarke.html>
>>>
>>> Hätte ich gerne angeschaut, aber was für eine Scheißseite. Beide meine
>>> Textbrowser lynx und w3m frieren beim Aufruf ein (im GUI-Browser lädt sie
>>> dagegen). Was für ein Müll.
>>
>> Lynx und w3m wird von der Zielgruppe der Post mutmasslich so gut wie gar
>> nicht genutzt und erst recht nicht getestet mangels Bedarf. Wozu auch
>> etwas testen, was dann von 0,000000001% aller Nutzer verwendet wird?
>
> Dann könnten die Entwickler den Support gleich einstellen.
>
> Deine Zahl halte ich btw. für zu weit hergeholt.

Selbst wenn es viele Größenordungen mehr sind und z.B. 0,01% betreffen
würde, würde sich niemand die Arbeit machen.

Und 0,01% ist bei Lynx vermutlich immer noch viel zu hoch geschätzt.

[Arno Welzel]

Andreas Kohlbach, 2022-11-14 07:24:

> On Mon, 14 Nov 2022 02:04:37 +0100, Arno Welzel wrote:
[...]

>> Das Web *ist* "klickibunti", schon sehr lange und nicht erst seit HTML5.
>

> Trotzdem haben lynx und andere textbasierte Clients kein Problem
> damit. Davon abgesehen, dass lynx nichts Verwertbares anzeigt. Was aber
> nicht lynx' Schuld ist - der kann nur Text.

Eben - das Web ist nicht nur Text und das war von Anfang an so. Nur weil
man *auch* Textdokumente damit publizieren kann, bedeutet nicht, dass
Websites generell mit textbasierten Browsern benutzbar sein müssen.
Wichtiger ist, dass Dinge, die für Barrierefreiheit und Zugänglichkweit
wichtig sind, auch benutzt werden - z.B. alternative Texte bei Bildern
oder korrekte Semantik, damit ein Screenreader auch die Navigation etc.
korrekt wiedergeben kann.

[Axel Berger]

Michael Landenberger wrote:
> Ich lese sehr wohl. [...] Oder auf dem

> Smartphone (ideal in Bus oder Bahn).

Für Twitter reicht das, für A4-PDF nicht.

> Davon abgesehen, sind digitale Abos nicht nennenswert billiger als die für
> Zeitschriften auf Papier,

Für Studenten mit Zugang über die Hochschulbibliothek schon.

[Axel Berger]

Arno Welzel wrote:
> Selbst wenn es viele Größenordungen mehr sind und z.B. 0,01% betreffen
> würde, würde sich niemand die Arbeit machen.

Muß man einen neu gebauten Straßenabschnitt bei der Bauabnahme mit
sämtlichen noch zugelassenen Fahrzeugtypen testen und hast Du jemals ein
Schild gesehen "diese Straße unterstützt nur Autos der Marken ..."?

Sportwagen bleiben auf schlammigen Feldwegen stecken, Textbrowser zeigen
keine Bilder und Rechner ohne Lautsprecher spielen keine Audios ab, aber
das ist etwas anderes.

[Arno Welzel]

Axel Berger, 2022-11-14 13:44:

> Arno Welzel wrote:
>> Selbst wenn es viele Größenordungen mehr sind und z.B. 0,01% betreffen
>> würde, würde sich niemand die Arbeit machen.
>
> Muß man einen neu gebauten Straßenabschnitt bei der Bauabnahme mit
> sämtlichen noch zugelassenen Fahrzeugtypen testen und hast Du jemals ein
> Schild gesehen "diese Straße unterstützt nur Autos der Marken ..."?

Nein, aber es gibt Straßen, die man nicht mit allen Autos befahren darf,
z.B. Autobahnen, auf denen man mit einem Traktor nicht fahren darf,
selbst wenn er für den Straßenverkehr generell zugelassen ist.

Aber was hat dieser unsinnige Vergleich mit der Frage zu tun, ob ein
Anbieter auch Nutzer von textbasierten Browsern berücksichtigen sollte?

> Sportwagen bleiben auf schlammigen Feldwegen stecken, Textbrowser zeigen
> keine Bilder und Rechner ohne Lautsprecher spielen keine Audios ab, aber
> das ist etwas anderes.

Nein, es ist genau das selbe. Auf einem Feldweg muss niemand damit
rechnen, dass man dort mit Sportwagen herumfährt und entsprechnd wird
der Feldweg auch nicht so angelegt, dass das problemlos möglich wäre.

Und ein Musik-Streaming-Anbieter wird in der Regel keine textliche
Beschreibung oder Liedtexte aller Inhalte anbieten, nur weil es auch
Menschen gibt, deren Endgeräte die Musik nicht akustisch abspielen können.

[Axel Berger]

Arno Welzel wrote:
> Aber was hat dieser unsinnige Vergleich mit der Frage zu tun, ob ein

> Anbieter auch Nutzer von textbasierten Browsern berücksichtigen sollte?

Muß er nach dem Standard. Nicht einmal eine völlig leere Seite darf es
sein, sondern es müssen irgendwelche Alt-Texte geliefert werden. Und
schon gar nicht darf man Besucher ohne Fehlermeldung in eine
Endlosschleife schicken.

> Und ein Musik-Streaming-Anbieter wird in der Regel keine textliche
> Beschreibung oder Liedtexte aller Inhalte anbieten,

Richtig. Mindestens aber einen Alt-Text der Art "hier sollte was zu
hören sein."

[Diedrich Ehlerding]

Arno Welzel meinte:

> Solange nicht klar ist, ob die Verbindung möglich ist
> oder nicht, kann man Lynx halt nicht anderweitig benutzen sondern nur
> mit Ctrl+C beenden.

Wann ist lynx denn klar, dass er keine Verbindung bekommt? Bei der in
Rede stehenden Adrese bleibt lynx für Stunden stehen; da sollte
jegliches ZTeitfenster für einen Verbindungsaufbau lange abgelaufen
sein.
>
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Arno Welzel]

Diedrich Ehlerding, 2022-11-15 07:43:

> Arno Welzel meinte:
>
>> Solange nicht klar ist, ob die Verbindung möglich ist
>> oder nicht, kann man Lynx halt nicht anderweitig benutzen sondern nur
>> mit Ctrl+C beenden.
>
> Wann ist lynx denn klar, dass er keine Verbindung bekommt? Bei der in
> Rede stehenden Adrese bleibt lynx für Stunden stehen; da sollte
> jegliches ZTeitfenster für einen Verbindungsaufbau lange abgelaufen
> sein.

Vermutlich gibt es keins.

[Arno Welzel]

Axel Berger, 2022-11-14 19:40:

> Arno Welzel wrote:
>> Aber was hat dieser unsinnige Vergleich mit der Frage zu tun, ob ein
>> Anbieter auch Nutzer von textbasierten Browsern berücksichtigen sollte?
>
> Muß er nach dem Standard. Nicht einmal eine völlig leere Seite darf es
> sein, sondern es müssen irgendwelche Alt-Texte geliefert werden. Und
> schon gar nicht darf man Besucher ohne Fehlermeldung in eine
> Endlosschleife schicken.

Welche Standard schreibt das konkret vor? Und was sind "irgendwelche
Alt-Texte" für eine Website insgesamt?

>> Und ein Musik-Streaming-Anbieter wird in der Regel keine textliche
>> Beschreibung oder Liedtexte aller Inhalte anbieten,
>
> Richtig. Mindestens aber einen Alt-Text der Art "hier sollte was zu
> hören sein."

Alt-Text bei Musik? Ich kenne das nur <img>.

[Frank Miller]

Arno Welzel wrote:
> Diedrich Ehlerding, 2022-11-15 07:43:
>
>> Arno Welzel meinte:
>>
>>> Solange nicht klar ist, ob die Verbindung möglich ist
>>> oder nicht, kann man Lynx halt nicht anderweitig benutzen sondern nur
>>> mit Ctrl+C beenden.
>>
>> Wann ist lynx denn klar, dass er keine Verbindung bekommt?

Fünf Minuten

> Vermutlich gibt es keins.

Meine Fresse - immer diese leeren Spekulationen. Habt ihr alle keinen Browser
mit irgendeiner Suchmaschine und labert ausschließlich im Usenet?
https://lynx.invisible-island.net/release/lynx_help/body.html#READ_TIMEOUT

READ_TIMEOUT – Timeouts
Description
Specifies (in seconds) read-timeout. Default value is rather huge.
Default value READ_TIMEOUT:18000

[Michael Landenberger]

"Frank Miller" schrieb am 15.11.2022 um 11:22:37:

> https://lynx.invisible-island.net/release/lynx_help/body.html#READ_TIMEOUT
>
> READ_TIMEOUT – Timeouts
> Description
> Specifies (in seconds) read-timeout. Default value is rather huge.
> Default value READ_TIMEOUT:18000

5 Stunden. Der Wert scheint aus einer Zeit zu stammen, als
Internetverbindungen noch mit V.32-Modems aufgebaut wurden. Man könnte auf den
Gedanken kommen, dass auch Textbrowser ein Relikt aus dieser Zeit sein könnten
;-)

Gruß

Michael

[Frank Miller]

Ah, meh! Stunden und nicht Minuten. Ich kann nicht mal richtig rechnen...

[Axel Berger]

Arno Welzel wrote:
> Und was sind "irgendwelche

> Alt-Texte" für eine Website insgesamt?

Wieso "insgesamt"? Ganz leer wird sie ja nicht sein sondern irgendwelche
als Text nicht darstellbare graphische Elemente enthalten.

> Alt-Text bei Musik? Ich kenne das nur <img>.

"Musik" wäre eine Datei zum Download. Teil der Seite ist in der Regel
ein irgendwie gearteter Player, kaum ganz ohne Graphik.

[Arno Welzel]

Frank Miller, 2022-11-15 11:22:

> Arno Welzel wrote:
>> Diedrich Ehlerding, 2022-11-15 07:43:
>>
>>> Arno Welzel meinte:
>>>
>>>> Solange nicht klar ist, ob die Verbindung möglich ist
>>>> oder nicht, kann man Lynx halt nicht anderweitig benutzen sondern nur
>>>> mit Ctrl+C beenden.
>>>
>>> Wann ist lynx denn klar, dass er keine Verbindung bekommt?
>
> Fünf Minuten
>
>> Vermutlich gibt es keins.
>
> Meine Fresse - immer diese leeren Spekulationen. Habt ihr alle keinen Browser
> mit irgendeiner Suchmaschine und labert ausschließlich im Usenet?

Nein, das war die logische Schlusfolgerung aus dieser Aussage in
<02pb4jx...@diedrich.ddnssec.de>:

"Bei der in Rede stehenden Adrese bleibt lynx für Stunden stehen; da
sollte jegliches ZTeitfenster für einen Verbindungsaufbau lange
abgelaufen sein."

> https://lynx.invisible-island.net/release/lynx_help/body.html#READ_TIMEOUT
>
> READ_TIMEOUT – Timeouts
> Description
> Specifies (in seconds) read-timeout. Default value is rather huge.
> Default value READ_TIMEOUT:18000

18000 Sekunden sind aber nicht nur fünf Minuten sondern fünf Stunden,
eben "rather huge" ;-).

[Arno Welzel]

Axel Berger, 2022-11-15 11:43:

> Arno Welzel wrote:
>> Und was sind "irgendwelche
>> Alt-Texte" für eine Website insgesamt?
>
> Wieso "insgesamt"? Ganz leer wird sie ja nicht sein sondern irgendwelche
> als Text nicht darstellbare graphische Elemente enthalten.

Und welcher Standard schreibt vor, dass man dafür Texte haben *muss*?
Ja, es ist wünschenswert im Sinne der Barrierefreiheit, dass Bilder, die
*statt* Text verwendet werden, auch alt-Attribute mit Beschreibungen
haben. Aber auf welchen *Standard* beziehst Du Dich hier? WCAG?

Abgesehen davon ist die Seite
<https://www.deutschepost.de/de/m/mobile-briefmarke.html> von DHL ist ja
als Text darstellbar. Man kann sie nur nicht mit Lynx laden ohne
Anpassung des User-Agent, weil die Firewall oder der Server die
Verbindung verhindert.

>> Alt-Text bei Musik? Ich kenne das nur <img>.
>
> "Musik" wäre eine Datei zum Download. Teil der Seite ist in der Regel
> ein irgendwie gearteter Player, kaum ganz ohne Graphik.

Und der Player soll dann als Text den Liedtext enthalten, weil es
Menschen gibt, die die Audiowiedergabe nicht nutzen können? Der Hinweis
"hier kann man das Lied XY hören" ist ja nicht wirklich hilfreich, wenn
es keine Audiowiedegabe gibt.

[Axel Berger]

Arno Welzel wrote:
> Der Hinweis

> "hier kann man das Lied XY hören" ist ja nicht wirklich hilfreich, wenn
> es keine Audiowiedegabe gibt.

Doch ist er. Im Gegensatz zu einer leeren Seite oder einer
Endlosschleife hat man eine klare Aussage und weiß genau, was los ist.

[Andreas Kohlbach]

On Tue, 15 Nov 2022 07:43:44 +0100, Diedrich Ehlerding wrote:
>
> Arno Welzel meinte:
>
>> Solange nicht klar ist, ob die Verbindung möglich ist
>> oder nicht, kann man Lynx halt nicht anderweitig benutzen sondern nur
>> mit Ctrl+C beenden.
>
> Wann ist lynx denn klar, dass er keine Verbindung bekommt? Bei der in
> Rede stehenden Adrese bleibt lynx für Stunden stehen; da sollte
> jegliches ZTeitfenster für einen Verbindungsaufbau lange abgelaufen
> sein.

Er sollte vielleicht selbst einen Timeout auslösen. Der Default schient
fünf Minuten zu sein. Aber er hängt auch danach. Wie erwähnt sollte
CTRL-g abbrechen, was auch immer er gerade tut. Normal geht das auch.
--
Andreas

[Marc Olschok]

Da magst Du recht haben. Es ist bereits weitgehend ruiniert.
Das obige Beispiel ist aber schon extrem, wenn man bedenkt, dass etwa
mit einem anderen Namen für den User Agent

lynx -useragent=midori https://www.deutschepost.de/en/home.html

die Seiten problemlos angezeigt werden und man z.B. auch die
Portoinformation bekommt.

Das bedeutet, dass irgendjemand sich die Mühe gemacht hat, ohne Not
bestimmte Browser auszusperren.

--
M.O.

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 16.11.2022 um 23:18:52:

> On Wed, 16 Nov 2022 15:03:45 -0000 (UTC), Marc Olschok wrote:

>> Das bedeutet, dass irgendjemand sich die Mühe gemacht hat, ohne Not
>> bestimmte Browser auszusperren.

> Vielleicht gibt es im benutzten CRM ein Modul, was das macht?

Du meinst sicher CMS.

Gruß

Michael

[Arno Welzel]

Axel Berger, 2022-11-15 20:44:

> Arno Welzel wrote:
>> Der Hinweis
>> "hier kann man das Lied XY hören" ist ja nicht wirklich hilfreich, wenn
>> es keine Audiowiedegabe gibt.
>
> Doch ist er. Im Gegensatz zu einer leeren Seite oder einer
> Endlosschleife hat man eine klare Aussage und weiß genau, was los ist.

Welche "Endlosschleife"?

[Mike Grantz]

On 12.11.2022 06:27, Andreas Kohlbach wrote:

[Subject]

Bundesministerium der Verteidigung und die Bundeswehr.

Fax: +49 30 1824-22228

Fax: +49 30 886228-2065

Und noch ein paar mehr:
https://www.bundeswehr.de/resource/blob/148968/e1d116badceb205d8392f3aa9d35e541/20191211-download-telefonverzeichnis-infoa-data.pdf

Früher zumindest auch bei der dezentralen Versorgung. Nachfrage,
Angebot, Bestellung. Zack zack zack. Und man hatte sofort etwas in der
Hand, was man abheften konnte.

Ob sich da heutzutage was geändert hat, weiss ich nicht.

Für die zentrale Beschaffung hat man Disketten per 5-10 Tonner zum
Hauptlager transportiert. Obwohl die Bundeswehr ein eigenes,
abgeschottetes Telefonnetz hat/hatte, hat man es nicht per Modem
übertragen, obwohl die Möglichkeit vorgesehen war.

Der LKW muss ja eh zum Lager.

Ob sich da heutzutage was geändert hat, weiss ich auch nicht.

Sicherheitstechnisch war es zumindest eine gute Lösung.

[Mike Grantz]

On 13.11.2022 21:04, Marc Olschok wrote:

> Unprofessioneller Scheißdreck. Die Generation Klickibunti ruiniert das
> Web weiterhin.

Ja! Meine Sourcecodevorleserin kommt gar nicht mehr hinterher.
Scheissdreck das!

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 18.11.2022 um 02:57:43:

> On Thu, 17 Nov 2022 08:52:55 +0100, Michael Landenberger wrote:

>>> Vielleicht gibt es im benutzten CRM ein Modul, was das macht?

>> Du meinst sicher CMS.

> Vermutlich. Ich arbeite nur selten mit diesen.

CRM = Customer Relations Management. CMS = Content Management System.
Letzteres hilft beim Aufbau von Websites enorm. Gäbe es sowas nicht, müsste
man für jede Website das Rad neu erfinden.

Was das "ohne Not aussperren" betrifft: glücklicherweise haben sich die
gängigen Browser in der Unterstützung von Standards sehr aneinander
angenähert, so dass nur noch wenige "Hacks" notwendig sind, um eine Seite auf
allen gängigen Browsern mehr oder weniger gleich aussehen zu lassen (im
Idealfall übernimmt die Anpassung das CMS, so dass sich der
Seitenprogrammierer gar nicht mehr darum kümmern muss). Speziell Textbrowser
unterstützen aber vergleichsweise viele Standards nicht, vor allem im Bereich
der Anzeige von Grafiken. Dass jemand solche Browser aussperrt oder zumindest
bei der Programmierung der Seite (oder des CMS) keinerlei Rücksicht auf sie
nimmt, kann ich nachvollziehen (BTW: auch auf viele grafische Browser wie z.
B. ältere Versionen des IE oder Netscape nimmt kaum noch jemand Rücksicht).
Alle sind froh, dass die Zeiten der unsäglichen IE-Hacks und anderen
Gefrickels endlich der Vergangenheit angehören. Das Aussperren bestimmter
Browser geschieht daher nicht "ohne Not", sondern aus purer Notwehr. Niemand
möchte wie Sisyphos enden.

Gruß

Michael

[Marc Olschok]

On Fri, 18 Nov 2022 08:58:37 Michael Landenberger wrote:
> "Andreas Kohlbach" schrieb am 18.11.2022 um 02:57:43:
>
>> On Thu, 17 Nov 2022 08:52:55 +0100, Michael Landenberger wrote:
>
>>>> Vielleicht gibt es im benutzten CRM ein Modul, was das macht?
>
>>> Du meinst sicher CMS.
>
>> Vermutlich. Ich arbeite nur selten mit diesen.
>
> CRM = Customer Relations Management. CMS = Content Management System.
> Letzteres hilft beim Aufbau von Websites enorm. Gäbe es sowas nicht, müsste
> man für jede Website das Rad neu erfinden.

(Ich hatte schon gedacht, es sei Content Removal Management gemeint :-)

>
> Was das "ohne Not aussperren" betrifft: glücklicherweise haben sich die
> gängigen Browser in der Unterstützung von Standards sehr aneinander
> angenähert, so dass nur noch wenige "Hacks" notwendig sind, um eine Seite auf
> allen gängigen Browsern mehr oder weniger gleich aussehen zu lassen (im
> Idealfall übernimmt die Anpassung das CMS, so dass sich der
> Seitenprogrammierer gar nicht mehr darum kümmern muss). Speziell Textbrowser
> unterstützen aber vergleichsweise viele Standards nicht, vor allem im Bereich
> der Anzeige von Grafiken. Dass jemand solche Browser aussperrt oder zumindest
> bei der Programmierung der Seite (oder des CMS) keinerlei Rücksicht auf sie
> nimmt, kann ich nachvollziehen (BTW: auch auf viele grafische Browser wie z.
> B. ältere Versionen des IE oder Netscape nimmt kaum noch jemand Rücksicht).
> Alle sind froh, dass die Zeiten der unsäglichen IE-Hacks und anderen
> Gefrickels endlich der Vergangenheit angehören. Das Aussperren bestimmter
> Browser geschieht daher nicht "ohne Not", sondern aus purer Notwehr. Niemand
> möchte wie Sisyphos enden.

Es besteht ein fundamentaler Unterschied zwischen "keine Rücksicht nehmen"
und "aktiv aussperren".

Wenn ich (aus welchen Gründen auch immer) mit einem Textbrowser unterwegs
bin, dann ist mir klar, dass ich bestimmte Inhalte auf Webseiten nicht
oder nur unzureichend anzeigen kann. Das ist überhaupt kein Problem,
denn ich erwarte keineswegs, dass die Autoren der Webseiten nur für mich
ein "betreutes Browsen" ermöglichen. Gerade bei Textbrowsern brauchen sie
das ja eben nicht; Textbrowser brauchen keine spezielle Unterstützung.
Insofern ist das die Variante "gar keine Sonderwurst" erst einmal diejenige
mit dem geringsten Aufwand. Genau das scheinen viele "digital na(t)ives"
nicht zu begreifen, weil sie glauben, für jeden Browser irgendeine
Sonderversion ihrer Seiten anfertigen zu müssen und sich nicht mehr an
den ursprünglichen Vorteil von html ("Meine Seite -- Deine Entscheidung,
wie Du sie anzeigst") erinnern.

In den meisten Fällen habe ich auch keine Probleme damit, mir andere
Medieninhalte der Seite mit anderen Werkzeugen anzusehen, falls es
erforderlich ist. Einzige Ausnahme ist Javascript -- da wechsle ich halt
notgedrungen.

Wenn hingegen bestimmte Textbrowser ausgesperrt werden, ist das
vollkommen unsinnig, weil es gegenüber der Auslieferung des
Default-Inhaltes gar keine Arbeit spart. Der einzige Vorteil besteht
für den Besucher darin, Inkompetenz frühzeitig zu erkennen, bevor man
sich auf weitere geschäftliche Beziehungen einlässt.

v.G.
--
M.O.

[Axel Berger]

Michael Landenberger wrote:
> Gäbe es sowas nicht, müsste
> man für jede Website das Rad neu erfinden.

Nein. Templates und SSI sind bereits erfunden. Nach mehreren Jahren mit
Wordpress fasse ich garantiert kein CMS mehr an.

> so dass nur noch wenige "Hacks" notwendig sind, um eine Seite auf
> allen gängigen Browsern mehr oder weniger gleich aussehen zu lassen

Gleich Aussehen ist optional, auf den gleichen Inhalt kommt es an. Es
ist sogar das Gruindprinzop von HTML, daß der Leser und sein Browser
allein darüber bestimmen, wie diese Inhalte aussehen sollen. Sie können
dabei Vorschläge anehmen, müssen aber nicht.

Alles andere ist Vergewaltigung des Grundkonzepts und das Ergebnis so,
wie immer zu erwarten, wenn man ein ungeeignetes Werkzeug für einen
Zweck verwendet.

> (im
> Idealfall übernimmt die Anpassung das CMS, so dass sich der
> Seitenprogrammierer gar nicht mehr darum kümmern muss).

Sage Browser statt CMs und Du hast das Prinzip des Web verstanden.

> Speziell Textbrowser
> unterstützen aber vergleichsweise viele Standards nicht, vor allem im Bereich
> der Anzeige von Grafiken. Dass jemand solche Browser aussperrt oder zumindest
> bei der Programmierung der Seite (oder des CMS) keinerlei Rücksicht auf sie
> nimmt, kann ich nachvollziehen

Ja. Textbrowser zeigen keine Graphik sondern eteas der Art "hier wäre
ein bild gewesen". Der Besucher und er allein entaschiedet, ob ihm das
reicht, oder er dei Graphik downloaden oder einen anderen Browser
verwenden möchte. Ihn auszusperren ist grob unverhältnismäßig und
normwidrig.

> Alle sind froh, dass die Zeiten der unsäglichen IE-Hacks und anderen
> Gefrickels endlich der Vergangenheit angehören.

Die waren schon immer überflüssig. Korrekter, valider Code ist genau
das. Man kann, wen ein fehlerhafter Browser sehr verbreitet ist, aus
reiner Freundlichkeit Workarounds anbieten, man muß aber keienswegs.

> Browser geschieht daher nicht "ohne Not", sondern aus purer Notwehr.

Arroganz und Überheblichkeit meinst Du.

> Niemand möchte wie Sisyphos enden.

Wozu auch?

[Michael Landenberger]

"Marc Olschok" schrieb am 18.11.2022 um 16:05:59:

> Wenn hingegen bestimmte Textbrowser ausgesperrt werden, ist das
> vollkommen unsinnig, weil es gegenüber der Auslieferung des
> Default-Inhaltes gar keine Arbeit spart.

Das ist sicher richtig, aber wir wissen nicht, ob lynx im hier zur Debatte
stehenden Fall tatsächlich absichtlich ausgesperrt wurde. Vielleicht enthält
der Code der Seite etwas, mit dem lynx nicht umgehen kann. Oder es wurde vom
Entwickler des serverseitigen CMS schlicht vergessen, einen Default-Output zu
definieren, den das CMS ausliefert, wenn mit einem ihm unbekannten Browser auf
den Content zugegriffen wird. Das wäre dann zwar die Schuld des
CMS-Entwicklers,
aber speziell bei Browsern mit sehr geringen Marktanteilen kann es halt
passieren, dass sie der Entwickler gar nicht auf dem Schirm hat und sein CMS
oder die damit erstellten Seiten folglich auch nicht damit testet. Dann ist es
natürlich logisch, dass Fehler nicht auffallen und als Konsequenz auch nicht
behoben werden. Hinzu kommt fehlendes Feedback: wenn in einem populären
Browser wie Chrome, Firefox oder Edge etwas nicht funktioniert, stehen sofort
hunderte Nutzer auf der Matte und beschweren sich. Funktioniert dagegen in
einem Exoten-Browser wie lynx etwas nicht, bekommt der Seitenbetreiber das u.
U. gar nicht mit.

Gruß

Michael

[Michael Landenberger]

"Axel Berger" schrieb am 18.11.2022 um 18:12:36:

> Michael Landenberger wrote:

>> Gäbe es sowas nicht, müsste
>> man für jede Website das Rad neu erfinden.

> Nein. Templates und SSI sind bereits erfunden. Nach mehreren Jahren mit
> Wordpress fasse ich garantiert kein CMS mehr an.

Schade. Es gibt so viele Content Management Systeme, da sollte man nicht
negative Erfahrungen mit einem System auf alle anderen übertragen.

>> so dass nur noch wenige "Hacks" notwendig sind, um eine Seite auf
>> allen gängigen Browsern mehr oder weniger gleich aussehen zu lassen

> Gleich Aussehen ist optional,

Nein, das ist nicht optional. Ein gut gemachtes Layout ist zwingende
Voraussetzung für die Ergonomie einer Seite.

> auf den gleichen Inhalt kommt es an.

Diese Aussage ist schon dadurch widerlegt, dass man Kritik erntet, wenn man
Inhalte in ungeeigneter oder unergonomischer Form präsentiert. Ein Beispiel
wären überlange (oder auch zu kurze) Zeilen im Usenet. Die Zeilenlänge
beeinflusst den Inhalt in keiner Weise, aber sie beeinflusst die Lesbarkeit.
Auch ein ellenlanger Text wird schwerer lesbar, wenn er in einen einzigen
Abschnitt gequetscht wird, anstatt ihn vernünftig zu gliedern. Zu einer
vernünftigen Gliederung kann auch die Einrückung einzelner Abschnitte oder
eine mehrspaltige Darstellung gehören, selbstverständlich mit korrekt
platzierten Spalten. Auch dynamische Layouts sind sinnvoll, z. B. wenn
wichtige Navigations-Elemente nicht beim Scrollen nach oben oder unten
verschwinden, sondern unabhängig vom gewählten Textausschnitt immer am
gleichen Platz bleiben.

> Es
> ist sogar das Gruindprinzop von HTML, daß der Leser und sein Browser
> allein darüber bestimmen, wie diese Inhalte aussehen sollen.

Das war vielleicht mal zu Tim Berner-Lees Zeiten so. Wir sind aber inzwischen
bei HTML 5 und CSS 3.

> Sie können dabei Vorschläge anehmen, müssen aber nicht.

Du kannst deine Seite gerne nach diesem Prinzip aufbauen, musst dann aber
damit rechnen, dass sie kaum jemand ansieht, weil sie optisch rein gar nichts
zu bieten hat, was Appetit aufs Lesen macht. Es ist ein Fehler, das WWW als
reines Transportmedium für (Text-)Informationen zu betrachten. Es ist genauso
ein Platz für Kunst und Ästhetik, wobei zumindest ich Dinge wie Typographie,
Layout/Design und andere Elemente der Präsentation ebenfalls zu Kunstformen
zähle.

BTW: wie darf ich eigentlich <META NAME="GENERATOR" CONTENT="manually edited
KISS"> verstehen? KISS ist ein lupenreines CMS, das du offenbar für deine
Seite verwendest, obwohl du oben behauptest, kein CMS mehr anfassen zu wollen.

>> (im
>> Idealfall übernimmt die Anpassung das CMS, so dass sich der
>> Seitenprogrammierer gar nicht mehr darum kümmern muss).

> Sage Browser statt CMs und Du hast das Prinzip des Web verstanden.

Blödsinn. Der Käufer einer gedruckten Zeitschrift oder eines gedruckten Buches
hat auch nicht die Möglichkeit, das vom Verfasser vorgesehene Layout nach
seinen Vorstellungen zu ändern. Im Idealfall will er das auch nicht, denn ein
guter Redakteur macht sich Gedanken über gutes Layout und liefert von sich aus
eines aus, das keiner Änderung mehr bedarf. Gute Webseiten-Entwickler machen
exakt dasselbe.

Gruß

Michael

[Axel Berger]

Michael Landenberger wrote:
> Es gibt so viele Content Management Systeme, da sollte man nicht
> negative Erfahrungen mit einem System auf alle anderen übertragen.

Das ist sicher richtig aber hier bin ich mir sicher, daß es das
Grundprinzip betrifft. Ich bin verwöhnt von einem sehr mächtigen Editor,
an den diese PHP-Dinge nie rankommen werden und können und sie sind
Icon- und mausgetrieben wie Word und Office, das hasse ich.

Wenn ich in WP fertiges, sauberes HTML reingekippt habe, wurde das
verhunzt. Ich habe das mit Workarounds zu umgehen gelernt, aber wozu?
Endgültig das Handtuch geschmissen habe ich, als die WP-Seiten nicht
mehr durch den Validator kamen und und ich das nicht verhindern konnte.
Erleichternd kam allerdings dazu, daß in Jahren kein einziger je
kommentiert hatte, so daß ich mit statischen Seiten ncihts verlor. Sonst
hätte ich mich weitergequält.

> Ein Beispiel
> wären überlange (oder auch zu kurze) Zeilen im Usenet. Die Zeilenlänge
> beeinflusst den Inhalt in keiner Weise, aber sie beeinflusst die Lesbarkeit.
> Auch ein ellenlanger Text wird schwerer lesbar, wenn er in einen einzigen
> Abschnitt gequetscht wird, anstatt ihn vernünftig zu gliedern.

Zeilenlänge macht mein Reader. Bei Absätzen ohne Zeilenumbrüche sind sie
etwas länger, als die, die sende, aber nicht viel. Gliederung ist
Inhalt. <P> Wie die Gliederung genau aussieht ist Geschmack des Lesers.
Absatzabstand oder -einzug, Größe des Abstandes.

> kann auch die Einrückung einzelner Abschnitte oder
> eine mehrspaltige Darstellung gehören,

Einrückung ist Inhalt, Liste oder Quote. Für Spalten werde ich mich auf
meinem schmalen Smartphonenbildschirm bedanken. Als CSS-Vorschlag nehme
ich sie auf dem großen Bildschirm gern an. Smartphones gab es bei TBLs
Entwurf noch nicht, seinen Anspruch mit allem, mit jeder Bildschirmgröße
zurechtzukommen aber schon.

> z. B. wenn
> wichtige Navigations-Elemente nicht beim Scrollen nach oben oder unten
> verschwinden, sondern unabhängig vom gewählten Textausschnitt immer am
> gleichen Platz bleiben.

Besonders toll, wenn die größer sind als das vom Besucher gewählte
Fenster. Das Ärgernis gab es sehr lange vor den Minibildschirmen. Große
Monitore waren teuer. "Designer" hatten die natürlich und wer nur
640x480 besaß oder 800x600 konnte sehen wo er blieb und interessierte
nicht.

> KISS ist ein lupenreines CMS,

Echt? Kenne ich nicht. "Keep it simple, stupid." ist bestimmt älter als
das und ich vermute der Namengeber des CMS kannte es und wollte darauf
anspielen.

> Blödsinn. Der Käufer einer gedruckten Zeitschrift oder eines gedruckten Buches
> hat auch nicht die Möglichkeit, das vom Verfasser vorgesehene Layout nach
> seinen Vorstellungen zu ändern.

Eben. Deshalb gilt die alte Regel im Web, wo jeder sein Fenster beliebig
klein machen darf, kann und soll auf sowas zu verzichten:
https://www.nngroup.com/articles/pdf-unfit-for-human-consumption/
(Ich kannte bis eben nur die zwanzig Jahre ältere Fassung.)

> Gute Webseiten-Entwickler machen exakt dasselbe.

Dann schreiben sie die Fenstergröße vor. Das ist auch beim klassischen
Buch nicht immer problemfrei, ein Bildband ist eine ungeeignete
Bettlektüre.

[Jens Schüßler]

* Michael Landenberger <spamwird...@web.de> [18-11-22 17:26]:

> "Marc Olschok" schrieb am 18.11.2022 um 16:05:59:
>
>> Wenn hingegen bestimmte Textbrowser ausgesperrt werden, ist das
>> vollkommen unsinnig, weil es gegenüber der Auslieferung des
>> Default-Inhaltes gar keine Arbeit spart.
>
> Das ist sicher richtig, aber wir wissen nicht, ob lynx im hier zur Debatte
> stehenden Fall tatsächlich absichtlich ausgesperrt wurde. Vielleicht enthält
> der Code der Seite etwas, mit dem lynx nicht umgehen kann.

lynx kann mit der Seite umgehen, nur der user-agent 'lynx' triggert da
was auf der Gegenseite
lynx -useragent=lynx https://www.deutschepost.de/de/m/mobile-briefmarke.html
--> hängt sich auf
mit allen andern Strings gibt es keine Probleme, auch ein einfaches
'12345' funktioniert
lynx -useragent=lynx_ https://www.deutschepost.de/de/m/mobile-briefmarke.html
--> Zeigt die Seite an, nachdem man allen Cookies zustimmt

[Michael Landenberger]

"Axel Berger" schrieb am 18.11.2022 um 21:00:57:

> Michael Landenberger wrote:

>> z. B. wenn
>> wichtige Navigations-Elemente nicht beim Scrollen nach oben oder unten
>> verschwinden, sondern unabhängig vom gewählten Textausschnitt immer am
>> gleichen Platz bleiben.

> Besonders toll, wenn die größer sind als das vom Besucher gewählte
> Fenster.

Dann hat der Ersteller der Seite gepfuscht. Aber das Problem ist längst
gelöst: gängige CMS erzeugen automatisch responsive designs, die sich an die
Größe des Bildschirms anpassen. Notfalls wird das komplette Layout bei Bedarf
umgebaut, z. B. passend zu einem Smartphone-Display - automatisch, versteht
sich (Smartphone: Menü ist nicht dauernd sichtbar, sondern wird nur nach
Tippen auf das entsprechende Icon angezeigt. Großer Bildschirm: Menü ist immer
sichtbar, dafür wird das Menü-Icon unsichtbar)

> Das Ärgernis gab es sehr lange vor den Minibildschirmen. Große
> Monitore waren teuer. "Designer" hatten die natürlich und wer nur
> 640x480 besaß oder 800x600 konnte sehen wo er blieb und interessierte
> nicht.

Du hast aber schon mitbekommen, dass die von dir genannten Monitore seit
Jahrzehnten Elektronikschrott sind?

>> KISS ist ein lupenreines CMS,

> Echt? Kenne ich nicht.

<http://kisscms.com/>

>> Der Käufer einer gedruckten Zeitschrift oder eines gedruckten Buches
>> hat auch nicht die Möglichkeit, das vom Verfasser vorgesehene Layout nach
>> seinen Vorstellungen zu ändern.

> Eben. Deshalb gilt die alte Regel im Web, wo jeder sein Fenster beliebig
> klein machen darf, kann und soll auf sowas zu verzichten:
> https://www.nngroup.com/articles/pdf-unfit-for-human-consumption/
> (Ich kannte bis eben nur die zwanzig Jahre ältere Fassung.)

Was hat PDF mit Webseiten zu tun? PDFs sind Dokumentdateien, die man
herunterlädt und dann nach Belieben damit macht, was man will. Ich kenne keine
einzige Website, die PDFs anstatt HTML ausliefert. Und was die Usability von
PDFs betrifft: bevor ich ein 100-seitiges PDF ausdrucke, schaue ich es mir
lieber am Bildschirm an. Vorteil: ich kann einzelne Kapitel durch simples
Anklicken im Inhaltsverzeichnis anspringen, ich kann nach Stichworten suchen,
ich kann die Darstellung nach Belieben groß oder klein zoomen etc. pp. Und ich
verschwende weder Papier noch Druckertinte.

>> Gute Webseiten-Entwickler machen exakt dasselbe.

> Dann schreiben sie die Fenstergröße vor.

Nein. Du möchtest dich mit responsive design auseinandersetzen.

Gruß

Michael

[Axel Berger]

Michael Landenberger wrote:
> gängige CMS erzeugen automatisch responsive designs,

Ja. Genau wie TBL beim Ur-HTML und zwar deshalb, weil sein
Hauptkriterium war, dieselbe Seite soll *ohne* jede Anpassung auf jedem
beliebigen Endgerät jedes beliebigen Herstellers angezeigt werden.
http://www.anybrowser.org/campaign/

> Notfalls wird das komplette Layout bei Bedarf umgebaut,

Genau. Vom Endgerät. Das weiß am besten, was es ist und was es kann.

[Arno Welzel]

Michael Landenberger, 2022-11-18 08:58:

> "Andreas Kohlbach" schrieb am 18.11.2022 um 02:57:43:
>
>> On Thu, 17 Nov 2022 08:52:55 +0100, Michael Landenberger wrote:
>
>>>> Vielleicht gibt es im benutzten CRM ein Modul, was das macht?
>
>>> Du meinst sicher CMS.
>
>> Vermutlich. Ich arbeite nur selten mit diesen.
>
> CRM = Customer Relations Management. CMS = Content Management System.
> Letzteres hilft beim Aufbau von Websites enorm. Gäbe es sowas nicht, müsste
> man für jede Website das Rad neu erfinden.

Letzteres gibt es auch in einer Form, wo am Ende nur weitgehend
statisches HTML herauskommt.

[...]

> Alle sind froh, dass die Zeiten der unsäglichen IE-Hacks und anderen
> Gefrickels endlich der Vergangenheit angehören. Das Aussperren bestimmter
> Browser geschieht daher nicht "ohne Not", sondern aus purer Notwehr. Niemand
> möchte wie Sisyphos enden.

ACK. Allerdings sind je nach Komplexität der Website Tests mit aktuellen
Browsern dennoch sinnvoll, selbst wenn der Inhalt standardkonform ist.

[Arno Welzel]

Axel Berger, 2022-11-18 18:12:

> Michael Landenberger wrote:
>> Gäbe es sowas nicht, müsste
>> man für jede Website das Rad neu erfinden.
>
> Nein. Templates und SSI sind bereits erfunden. Nach mehreren Jahren mit
> Wordpress fasse ich garantiert kein CMS mehr an.

Das ist für den Hobbybereich sicher ausreichend. Für komplexere Websites
reicht das aber ganz sicher nicht.

Für ein Filmfestival habe ich u.A. auch die Programmverwaltung
entwickelt - Filme mit Titeln, Vorschaubildern, Aufführungszeiten,
Beschreibung usw. mit Ansichten nach Tagen, pro Kategorie oder
alphabetische Gesamtliste. Die Website drumherum baut auf WordPress auf,
die Filmdatenbank nutzt Custom Post Types und eigene Taxonomien und ca.
2000 Zeilen PHP-Code.

Dazu kommt noch ein System zur Einreichung von Filmen und
Veranstaltungen und eine Anwendung dazu, in der das Festival-Team die
Einreichungen bewerten und die Einreichenden per E-Mail benachrichtigen
kann.

Vorteil: das System ist auch für Leute benutzbar, die weder HTML noch
CSS kennen, sondern einfach nur die Redaktion für das Festival machen
sollen.

[Arno Welzel]

Axel Berger, 2022-11-18 21:00:

> Michael Landenberger wrote:
>> Es gibt so viele Content Management Systeme, da sollte man nicht
>> negative Erfahrungen mit einem System auf alle anderen übertragen.
>
> Das ist sicher richtig aber hier bin ich mir sicher, daß es das
> Grundprinzip betrifft. Ich bin verwöhnt von einem sehr mächtigen Editor,
> an den diese PHP-Dinge nie rankommen werden und können und sie sind
> Icon- und mausgetrieben wie Word und Office, das hasse ich.

Du kennst halt nicht viel und auch nicht viel anderes als HTML.

> Wenn ich in WP fertiges, sauberes HTML reingekippt habe, wurde das
> verhunzt. Ich habe das mit Workarounds zu umgehen gelernt, aber wozu?

In WordPress nutzt man mittlerweile kein HTML mehr.

[Axel Berger]

Arno Welzel wrote:
> In WordPress nutzt man mittlerweile kein HTML mehr.

Eben das ist das Problem. Die Seite, die der Besucher hinterher in
seinem Browser sieht, wird HTML sein und als Autor will ich das
schreiben können, wo hinterher mein Name druntersteht. HTML ist einfach
und schnell gelernt, die "anwenderfreundlichen" Eingaben und Interfaces
sind die Hölle.

[Arno Welzel]

Axel Berger, 2022-11-19 09:20:

> Michael Landenberger wrote:
>> gängige CMS erzeugen automatisch responsive designs,
>
> Ja. Genau wie TBL beim Ur-HTML und zwar deshalb, weil sein
> Hauptkriterium war, dieselbe Seite soll *ohne* jede Anpassung auf jedem
> beliebigen Endgerät jedes beliebigen Herstellers angezeigt werden.
> http://www.anybrowser.org/campaign/

Bei HTML ist die *Darstellung* komplett irrelevant. Es ging allein um
die Struktur der Inhalte. Spielereien wie <font>, <marquee> oder <blink>
wurden zurecht zugunsten von CSS schnell als obsolet erklärt.

Die spezifische Ansicht bei Browsern für grafische Oberflächen kommt
erst durch CSS zustande - und Browser arbeiten mit einem internen
Standard-Stylesheet, was man durch eigene Regeln anpassen kann.

Weiterhin arbeitet HTML mittlerweile noch stärker mit Semantik und erst
CSS entscheidet, wie die Darstellung am Ende sein soll. Und ja, ein
guter Website-Entwickler berücksichtigt dabei selbstverständlich die
Anforderungen verschiedener Endgeräte.

>> Notfalls wird das komplette Layout bei Bedarf umgebaut,
>
> Genau. Vom Endgerät. Das weiß am besten, was es ist und was es kann.

Ein gutes Design berücksichtigt ja genau das und verlangt keine feste
Ausgabebreite und auch nicht mehrspaltige Ansicht.

Bei Dir ist z.B. <http://berger-odenthal.de/random/Covid-Koeln.htm> auf
einem Smartphone nur umständlich nutzbar, weil die Grafiken nicht an die
verfügbare Ausgabebreite verkleinert und auf Wunsch in einer Lightbox
mit Vergrößerungsoption angezeigt werden, wie es auf mobilen Geräten
üblich ist, sondern man ständig herumscrollen muss.

Weiterhin legst Du für die komplette Website eine Maximalbreite fest,
die aber genau bei <http://berger-odenthal.de/random/Covid-Koeln.htm>
nicht eingehalten wird, weil die Bilder nicht reinpassen. Der Text
bleibt zwar schmaler, springt aber nach links, weil die Grafiken alles
breiter machen. Mit "gutem Design" hat das wenig zu tun. Auch eine
Tabelle mit Zahlen, wenigstens für Wochen- oder Monatswerte, wäre eine
gute Alternative, wenn jemand die Grafik nicht anzeigen kann.

[Axel Berger]

Arno Welzel wrote:
> Weiterhin legst Du für die komplette Website eine Maximalbreite fest,

> die aber genau bei <http://berger-odenthal.de/random/Covid-Koeln.htm>
> nicht eingehalten wird, weil die Bilder nicht reinpassen. Der Text
> bleibt zwar schmaler, springt aber nach links, weil die Grafiken alles
> breiter machen.

Ja, der Kompromiß mit der Bildgröße ist ein Mangel. Browser skalieren zu
schlecht, als daß mir das die bessere Alternative erschiene. Warum der
Smartphonebrowser die Bilder so massiv vergrößert bleibt mir unklar, ist
aber so.
Den zweiten Teil kann ich auf etlichen Browsern nicht nachvollziehen.
Der Text bleibt wie er sein soll und scrollt ggf. beim Bildansehen links
raus.

> und auf Wunsch in einer Lightbox

> mit Vergrößerungsoption angezeigt werden

Ja, aber wozu. Alle Smartphonebrowser, die ich gerade getestet habe,
bieten beim Klick auf's Bild Optionen mit Bordmitteln der Browsers, die
all das abdecken.

> Auch eine
> Tabelle mit Zahlen, wenigstens für Wochen- oder Monatswerte,

Mehr geht immer, viel mehr erst recht. Wie im Text erläutert sind das
primitive quick and dirty Bilder für einen ersten Eindruck, die man so,
logarithmisch skaliert, als ich anfing nirgends fand und auch jetzt
lange suchen muß. Am Anfang, als Information wichtig und nirgends
vernünftig zu bekommen war, habe die Bilder täglich erneuert. Das war
und ist reichlich Arbeit. Gegen Bezahlung kann und würde ich sehr
erheblich mehr tun.

[Marc Olschok]

Stimmt, ich hatte es auch noch mit
lynx -useragent=wackelpudding https://www.deutschepost.de/en/home.html
getestet.

Aber die Post ist nicht untätig geblieben. Sie sperrt jetzt die Anfrage von
dem bisher von mir zum testen genutzten Rechner aus, egal welcher
-useragent verwendet wird.

Von einem anderen Rechner geht es noch.

v.G.
--
M.O.

[Arno Welzel]

Axel Berger, 2022-11-19 23:39:

> Arno Welzel wrote:
>> Weiterhin legst Du für die komplette Website eine Maximalbreite fest,
>> die aber genau bei <http://berger-odenthal.de/random/Covid-Koeln.htm>
>> nicht eingehalten wird, weil die Bilder nicht reinpassen. Der Text
>> bleibt zwar schmaler, springt aber nach links, weil die Grafiken alles
>> breiter machen.
>
> Ja, der Kompromiß mit der Bildgröße ist ein Mangel. Browser skalieren zu
> schlecht, als daß mir das die bessere Alternative erschiene. Warum der
> Smartphonebrowser die Bilder so massiv vergrößert bleibt mir unklar, ist
> aber so.

*Aktuelle* Browser skalieren auch Bitmap-Grafiken sehr gut. Weiterhin
wäre SVG für solche Diagramme ohnehin besser - das kann man komplett
ohne Qualitätsverlust beliebig skalieren, siehe z.B. den Schaltplan hier:

<https://arnowelzel.de/alphaclock-alt-trifft-neu>

> Den zweiten Teil kann ich auf etlichen Browsern nicht nachvollziehen.
> Der Text bleibt wie er sein soll und scrollt ggf. beim Bildansehen links
> raus.

Eben - das "links raus scrollen" ist das Problem!

Auf <http://berger-odenthal.de> ist der Text mittig und bei
<http://berger-odenthal.de/random/Covid-Koeln.htm> ein Stück weiter
links. Sowas kann sehr irritierend sein.

>> und auf Wunsch in einer Lightbox
>> mit Vergrößerungsoption angezeigt werden
>
> Ja, aber wozu. Alle Smartphonebrowser, die ich gerade getestet habe,
> bieten beim Klick auf's Bild Optionen mit Bordmitteln der Browsers, die
> all das abdecken.

Davon spreche ich aber nicht. Ich will nicht erst lange auf ein Bild
tippen müssen, um es dann manuell in eine einem neuen Tab oder
alleinstehend zu öffnen etc..

>> Auch eine
>> Tabelle mit Zahlen, wenigstens für Wochen- oder Monatswerte,
>
> Mehr geht immer, viel mehr erst recht. Wie im Text erläutert sind das
> primitive quick and dirty Bilder für einen ersten Eindruck, die man so,
> logarithmisch skaliert, als ich anfing nirgends fand und auch jetzt
> lange suchen muß. Am Anfang, als Information wichtig und nirgends
> vernünftig zu bekommen war, habe die Bilder täglich erneuert. Das war
> und ist reichlich Arbeit. Gegen Bezahlung kann und würde ich sehr
> erheblich mehr tun.

Wenn es reichlich Arbeit ist, hätte ich das gleich anders gemacht und
z.B. per Script generieren lassen. Passende Bibliotheken für Diagramme
in Browsern existieren:

<https://www.chartjs.org/>

Freilich müsste man dazu die Scheuklappe "JavaScript = böse" ablegen.

[Arno Welzel]

Axel Berger, 2022-11-19 18:14:

> Arno Welzel wrote:
>> In WordPress nutzt man mittlerweile kein HTML mehr.
>
> Eben das ist das Problem. Die Seite, die der Besucher hinterher in
> seinem Browser sieht, wird HTML sein und als Autor will ich das
> schreiben können, wo hinterher mein Name druntersteht. HTML ist einfach
> und schnell gelernt, die "anwenderfreundlichen" Eingaben und Interfaces
> sind die Hölle.

Gutenberg funktioniert mittlerweile sehr gut und schnell und für andere
Anwendungen finde ich Markdown in Kombination mit MkDocs *deutlich*
sinnvoller als HTML.

[Axel Berger]

Arno Welzel wrote:
> *Aktuelle* Browser skalieren auch Bitmap-Grafiken sehr gut.

Ich habe gerade mal ein mir von früher bekanntes Negativbeispiel
aufgerufen, in dem ein Bild mit echten 320*432 auf 234*320 skaliert
wird. Ich finde, man sieht es sehr deutlich. Für Deine Forderung habe
ich nicht einen meiner bevorzugten Browser gewählt sondern den aktuellen
Chrome.

> und bei
> <http://berger-odenthal.de/random/Covid-Koeln.htm> ein Stück weiter

> links. Sowas kann sehr irritierend sein.

Stimmt. Je nach Schrift- und Fenstergröße weitet das in Pixel
spezifizierte Bild die in em definierte Vorgabe für die Breite des Body
auf. Die Schrift ist dann nicht zentriert, aber sie behält eine für
optimales, müheloses Bildschirmlesen angenehme Zeilenlänge und wird
nicht unzumutbar in die Länge gezogen. Das ist weit wichtiger. Es hat
einen Grund, warum alles Gedruckte ab ca. A5 in Spalten gesetzt wird.

> hätte ich das gleich anders gemacht

Hast Du aber nicht. Ich habe, zunächst rein für mich selbst, ein
Spreadsheet angelegt und mir Daten in einer sonst nicht zu findenden
sinnvollen Form, i.e. halblogarithmisch, anzeigen lassen. Schönheit war
mir für den Zweck überflüssig. Für andere, die es interssiert, biete ich
diese Bilder an, wie im Text gesagt als reinen, schnellen Screenshot.
Wem das nicht reicht, der kann sich gern aus den öffentlich verfügbaren
Daten eine eigene Tabelle anlegen und selbst über mehr als zwei Jahre
täglich pflegen. Wer Forderungen stellt, der möge mir eine angemessene
Bezahlung bieten. Dafür bekommt er dann gern alles genau so, wie er es
will.

Alle anderen bekommen, was schon fertig da ist und was mir für meine
Zwecke ausreicht.

> Freilich müsste man dazu die Scheuklappe "JavaScript = böse" ablegen.

Genau. Unter dem Druck der Wirtschaft hat das BSI seine Texte dazu
inzwischen gut versteckt. Sie sind aber noch da:

"Wie die Java-Applets kommen auch die in JavaScript geschriebenen
Aktiven Inhalte mehr oder weniger ungefragt auf Ihren Rechner. An der
angezeigten Webseite ist nicht erkennbar, was sich so alles dahinter
verbirgt. Hierdurch entsteht für den Anwender ein unüberschaubares
Risiko. Schließlich sind auch bei JavaScript Fehler in der
Implementierung nicht ausgeschlossen."
https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Updates-Browser-Open-Source-Software/Der-Browser/Gefahren-und-Risiken/gefahren-und-risiken_node.html

Den früher sehr expliziten Satz "wir empfehlen dringend alle aktiven
Inhalte abzuschalten" finde ich heute nicht mehr, nur noch implizit.
Aber wie sonst sollte man das hier verstehen?

"Die Grundeinstellung eines Browsers im Auslieferungszustand erlaubt
meist die Ausführung von unbekannten Programmen, die in die
Informationsangebote der Server-Betreiber eingebunden sind. Derartige
Programme werden als aktive Inhalte bezeichnet und werden meist mit den
Programmiersprachen Java, JavaScript oder ActiveX erstellt. Der
Betreiber der Internetseite könnte die Inhalte damit so programmieren,
dass Daten auf Ihrem Rechner gelesen oder sogar beschädigt werden."
https://www.bsi.bund.de/SharedDocs/Glossareintraege/DE/A/Aktive_Inhalte.html

[Arno Welzel]

Axel Berger, 2022-11-20 17:15:

> Arno Welzel wrote:
>> *Aktuelle* Browser skalieren auch Bitmap-Grafiken sehr gut.
>
> Ich habe gerade mal ein mir von früher bekanntes Negativbeispiel
> aufgerufen, in dem ein Bild mit echten 320*432 auf 234*320 skaliert
> wird. Ich finde, man sieht es sehr deutlich. Für Deine Forderung habe
> ich nicht einen meiner bevorzugten Browser gewählt sondern den aktuellen
> Chrome.

Nun ja - was erwartest Du als "Qualität", wenn lediglich 320 Pixel auf
234 reduziert werden? Das schafft auch ein Grafikprogramm nicht besser.

Was ich meinte: aktuelle Browser skalieren mit bilinearer Filterung,
weshalb man Bitmap-Grafiken durchaus auch mit relativer Größenangabe wie

max-width:100%;
height:auto;

einbinden kann, ohne, dass die Darstellung komplett unbrauchbar ist. Ja,
es hängt natürlich auch vom Bild ab und je höher die Originalauflösung
des Bilds, desto besser das skalierte Ergebnis.

[...]

>> hätte ich das gleich anders gemacht
>
> Hast Du aber nicht. Ich habe, zunächst rein für mich selbst, ein
> Spreadsheet angelegt und mir Daten in einer sonst nicht zu findenden
> sinnvollen Form, i.e. halblogarithmisch, anzeigen lassen. Schönheit war
> mir für den Zweck überflüssig. Für andere, die es interssiert, biete ich
> diese Bilder an, wie im Text gesagt als reinen, schnellen Screenshot.
> Wem das nicht reicht, der kann sich gern aus den öffentlich verfügbaren
> Daten eine eigene Tabelle anlegen und selbst über mehr als zwei Jahre
> täglich pflegen. Wer Forderungen stellt, der möge mir eine angemessene
> Bezahlung bieten. Dafür bekommt er dann gern alles genau so, wie er es
> will.

Dann solltest Du aber hier nicht darüber sprechen, was gutes oder
schlechtees HTML ist, wenn Du Inhalte so anbietest.

Und die Aussage "Wer Forderungen stellt, der möge mir eine angemessene
Bezahlung bieten." darfst Du dann gerne auch auf alle Anderen anwenden.
Wenn Dir eine Website nicht gefällt, dann bezahle die Anbieter dafür, es
besser zu machen! Ansonsten sei einfach still!

[...]

>> Freilich müsste man dazu die Scheuklappe "JavaScript = böse" ablegen.
>
> Genau. Unter dem Druck der Wirtschaft hat das BSI seine Texte dazu
> inzwischen gut versteckt. Sie sind aber noch da:
>
> "Wie die Java-Applets kommen auch die in JavaScript geschriebenen
> Aktiven Inhalte mehr oder weniger ungefragt auf Ihren Rechner. An der
> angezeigten Webseite ist nicht erkennbar, was sich so alles dahinter
> verbirgt. Hierdurch entsteht für den Anwender ein unüberschaubares
> Risiko. Schließlich sind auch bei JavaScript Fehler in der
> Implementierung nicht ausgeschlossen."
> https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Updates-Browser-Open-Source-Software/Der-Browser/Gefahren-und-Risiken/gefahren-und-risiken_node.html

Das BSI schreibt viel. Die haben bis vor nicht all zu langer Zeit auch
noch empfohlen, dass man Passwörter zwangsweise regelmäßig ändern muss,
um sicher sein zu können. Von diesem Irrweg ist das NIST schon vor
Jahren abgerückt und das BSI hat mittlerweile auch nachgezogen.

> Den früher sehr expliziten Satz "wir empfehlen dringend alle aktiven
> Inhalte abzuschalten" finde ich heute nicht mehr, nur noch implizit.
> Aber wie sonst sollte man das hier verstehen?

Man sollte es so verstehen, wie es da steht: Fehler gibt es überall.

Die wesentlichen Einfallstore für JavaScript gibt es alle nicht mehr:

1) Plugins auf Basis der Netscape-Plugin-API

2) Java-Applets

3) ActiveX

4) Flash

Ohne diese Elemente kann JavaScript nicht mehr wirklich viel schädliche
Dinge ausrichten. Faktisch bleibt nur noch XSS übrig, was aber primär
Websites betrifft, die dadurch angreifbar sein können, wenn die Anbieter
geschlampt haben.

> "Die Grundeinstellung eines Browsers im Auslieferungszustand erlaubt
> meist die Ausführung von unbekannten Programmen, die in die
> Informationsangebote der Server-Betreiber eingebunden sind. Derartige
> Programme werden als aktive Inhalte bezeichnet und werden meist mit den
> Programmiersprachen Java, JavaScript oder ActiveX erstellt. Der
> Betreiber der Internetseite könnte die Inhalte damit so programmieren,
> dass Daten auf Ihrem Rechner gelesen oder sogar beschädigt werden."
> https://www.bsi.bund.de/SharedDocs/Glossareintraege/DE/A/Aktive_Inhalte.html

Das ist komplett veraltet.

Java-Apples gibt es schon lange nicht mehr und ActiveX ebenso wenig!

Siehe dazu auch:

<https://www.oracle.com/java/technologies/javase/9-deprecated-features.html>

Und ActiveX wurde mit dem Internet Explorer beerdigt - Edge basiert auf
Chromium und unterstützt kein ActiveX.

Faktisch kann *jeder* Inhalt Sicherheitslücken ausnutzen. Siehe den
GDI-Bug bei Windows:

<https://www.cvedetails.com/cve/CVE-2011-0041/>

Zu glauben, man wäre "sicher", nur weil man JavaScript nicht zulässt,
ist reichlich naiv. Weiterhin ist JavaScript mittlerweile einfach
regulärer Bestandteil von Websites, wie HTML und CSS auch.

[Axel Berger]

Arno Welzel wrote:
> Das schafft auch ein Grafikprogramm nicht besser.

Da ist meine Erfahrung eine andere.

> und je höher die Originalauflösung

> des Bilds, desto besser das skalierte Ergebnis.

Das sind dann die Seiten, bei denen man sich wundert, warum winzige
Thumbnails ewig brauchen, bis man sich die geladene Graphik mal ansieht.
Großes Kino.

> Dann solltest Du aber hier nicht darüber sprechen, was gutes oder

> schlechtees HTML ist, wenn Du Inhalte so anbietest.

Ein mäßiges bis schlechtes Bild hat mit HTML nichts zu tun, es sei denn,
es wäre von HTML (oder CSS, PHP, JS, sonstwas) so verschlechtert worden.
HTML kann nichts für Mängel der Inhalte.

> Die haben bis vor nicht all zu langer Zeit auch

> noch empfohlen, dass man Passwörter zwangsweise regelmäßig ändern muss,
> um sicher sein zu können.

Was ist daran falsch? Die meisten Passworddiebstähle sind Einbrüche auf
Firmenservern oder Phishing. Gegen beides hilft eine noch so sichere
Form und Länge des PW gar nicht, regelmäßiger Wechsel aber sehr wohl.

[Arno Welzel]

Axel Berger, 2022-11-20 21:41:

> Arno Welzel wrote:
>> Das schafft auch ein Grafikprogramm nicht besser.
>
> Da ist meine Erfahrung eine andere.

Meine nicht. 320 Pixel sind nun mal nur 320 Pixel. Da kann auch ein
Grafikprogramm keine Wunder vollbringen, wenn das auf 234 Pixel
reduziert werden soll.

>> und je höher die Originalauflösung
>> des Bilds, desto besser das skalierte Ergebnis.
>
> Das sind dann die Seiten, bei denen man sich wundert, warum winzige
> Thumbnails ewig brauchen, bis man sich die geladene Graphik mal ansieht.
> Großes Kino.

Ich rede nicht von Thumbnails, sondern Bilder, die statt 100% nur mit
80% oder 60% der Breite angezeigt werden.

[...]

>> Die haben bis vor nicht all zu langer Zeit auch
>> noch empfohlen, dass man Passwörter zwangsweise regelmäßig ändern muss,
>> um sicher sein zu können.
>
> Was ist daran falsch? Die meisten Passworddiebstähle sind Einbrüche auf

Lies selber:

<https://www.heise.de/security/meldung/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html>

> Firmenservern oder Phishing. Gegen beides hilft eine noch so sichere
> Form und Länge des PW gar nicht, regelmäßiger Wechsel aber sehr wohl.

Ein regelmäßiger Wechsel hilft exakt gar nicht gegen Phishing oder
Passwortdiebstähle! Die Passwörter sind ja trotzdem noch gültig, wenn
niemand den Diebstahl bemerkt - je nach Regelung auch mehrere Monate
lang, wenn der Diebstahl zum richtigen Zeitpunkt stattgefunden hat.

Besser als Passwortwechsel sind zusätzliche Authentifzierungsfaktoren.

[Axel Berger]

Arno Welzel wrote:
> Ich rede nicht von Thumbnails, sondern Bilder, die statt 100% nur mit
> 80% oder 60% der Breite angezeigt werden.

Dann redest Du seltsam. Ein Bild mit 125 % der angezeigten Auflöäsung
erfüllt sicher nicht die Bedingung "je höher die Auflösung" und das
Ergebnis ist mit Sicherheit schlechter als die Anzeige der echten
Auflösung. Ein Verkleinern auf die Hälfte oder weniger ist unkritisch,
es sind die krummen Werte darüber, die fast zwangsläufig Artefakte
erzeugen.

> Lies selber:

Habe ich gemacht. Sehr dünn.
"Das regelmäßige Ändern führt eher dazu, dass man schwache Passwörter
benutzt und diese beispielsweise nach einem Schema (geheim1, geheim2,
...) erzeugt."

Wie oben gesagt, bei Diebstahl gibt es keine guten und sicheren PW.

> Die Passwörter sind ja trotzdem noch gültig, wenn

> niemand den Diebstahl bemerkt - je nach Regelung auch mehrere Monate
> lang,

Nach dem was ich so mitbekomme kursieren die verkauften PW recht lange.
Der Angriff muß nicht schnell kommen. Wenn doch hast Du natürlich recht.

> Besser als Passwortwechsel sind zusätzliche Authentifzierungsfaktoren.

Das auf jeden Fall, aber ganz anderes Thema.

[Jens Schüßler]

* Andreas Kohlbach <a...@spamfence.net> [20-11-22 05:47]:

> On Sat, 19 Nov 2022 22:52:54 -0000 (UTC), Marc Olschok wrote:
>>
>> On Fri, 18 Nov 2022 21:26:31 Jens Schüßler wrote:
>>>
>>> lynx kann mit der Seite umgehen, nur der user-agent 'lynx' triggert da
>>> was auf der Gegenseite
>>> lynx -useragent=lynx https://www.deutschepost.de/de/m/mobile-briefmarke.html
>>> --> hängt sich auf
>>> mit allen andern Strings gibt es keine Probleme, auch ein einfaches
>>> '12345' funktioniert
>>> lynx -useragent=lynx_ https://www.deutschepost.de/de/m/mobile-briefmarke.html
>>> --> Zeigt die Seite an, nachdem man allen Cookies zustimmt
>>
>> Stimmt, ich hatte es auch noch mit
>> lynx -useragent=wackelpudding https://www.deutschepost.de/en/home.html
>> getestet.
>

> Dann war meine Annahme falsch, dass dort ein Default kaputt wäre, da sie
> stattdessen offenbar *gezielt* bestimmte Browser ausschließen. Man müsste
> die Post boykottieren...

Es wird die Deutsche Post sicher zum Einlenken zwingen wenn all ihre
Kunden in Hütten in der nordamerikanischen Wildnis einen Boykott
starten. Go Girl!

[Arno Welzel]

Axel Berger, 2022-11-21 01:03:

> Arno Welzel wrote:
>> Ich rede nicht von Thumbnails, sondern Bilder, die statt 100% nur mit
>> 80% oder 60% der Breite angezeigt werden.
>
> Dann redest Du seltsam. Ein Bild mit 125 % der angezeigten Auflöäsung
> erfüllt sicher nicht die Bedingung "je höher die Auflösung" und das
> Ergebnis ist mit Sicherheit schlechter als die Anzeige der echten
> Auflösung. Ein Verkleinern auf die Hälfte oder weniger ist unkritisch,
> es sind die krummen Werte darüber, die fast zwangsläufig Artefakte
> erzeugen.

Deswegen nutzt man für sowas bilineare Filterung - und das machen
eigentlich alle Browser mittlerweile.

Und wenn man Diagramme oder technische Zeichnungen veröffentlichen will,
nutzt man dafür geeignete Formate wie SVG und nicht Bitmaps.

>> Lies selber:
>
> Habe ich gemacht. Sehr dünn.
> "Das regelmäßige Ändern führt eher dazu, dass man schwache Passwörter
> benutzt und diese beispielsweise nach einem Schema (geheim1, geheim2,
> ...) erzeugt."
>
> Wie oben gesagt, bei Diebstahl gibt es keine guten und sicheren PW.

Bei Diebstahl gibt es generell *gar* *keine* Sicherheit, außer das
Passwort *sofort* zu ändern! Eine Regel, die eine Änderung pauschal alle
x Tage vorschreibt, bringt da exakt *nichts*, da bis zur Änderung das
Passwort uneingeschränkt nutzbar ist.

>> Die Passwörter sind ja trotzdem noch gültig, wenn
>> niemand den Diebstahl bemerkt - je nach Regelung auch mehrere Monate
>> lang,
>
> Nach dem was ich so mitbekomme kursieren die verkauften PW recht lange.

Ja, wenn die Opfer nicht merken, dass Passwörter von Unbefugten genutzt
werden. Sichere Systeme erkennen auch ungewöhnliche Zugriffe aus
IP-Adressbereichen, die normalerweise nie genutzt werden und fragen bei
den rechtmäßigen Nutzer auf einem zweiten Kanal nach, ob der
Anmeldeversuch legitim ist, bevor sie die Anmeldung zulassen.

[Christoph 'Mehdorn' Weber]

Hallo!

* Michael Landenberger <spamwird...@web.de>:

> Es wird auch niemand Programme wie Photoshop, Corel Draw oder
> den VLC Player als fehlerhaft ansehen, nur weil sie in einem
> Konsolenfenster nicht laufen.

Also bei "cvlc" (dem Kommandozeilen-Client von VLC) wäre es
schon sehr merkwürdig.

Christoph

--
Himmel, wie oft habe ich in Muenster schon PKW ueberholt, die Tempo 20 fahren,
weil in 20km Entfernung eine Schneeflocke gefallen war. -- Whoa! Die sind ja
auch saugefaehrlich! Besonders wenn die hochkant auf der Strasse liegen...
Nein, die Schneeflocke, nicht der PKW. (nach Roger Schwentker, Eric Schaefer)

[Arno Welzel]

Christoph 'Mehdorn' Weber, 2022-11-25 20:52:

> Hallo!
>
> * Michael Landenberger <spamwird...@web.de>:
>
>> Es wird auch niemand Programme wie Photoshop, Corel Draw oder
>> den VLC Player als fehlerhaft ansehen, nur weil sie in einem
>> Konsolenfenster nicht laufen.
>
> Also bei "cvlc" (dem Kommandozeilen-Client von VLC) wäre es
> schon sehr merkwürdig.

Von dem war auch nicht die Rede.