Stranger Than Usual

Konstanze: „Ick muss dich wat fragen, Ron: Wat passiert, wenn du auf das ‚Tell me more‘ klickst?“
Ron: „Das wissen alle, die das schon mal getan haben: Ein dunkler, zorniger Gott erwacht. Oder Clippy.“

Security Nightmares 2025 (bei etwa 5:36)

Der alljährliche Nextcloud-Breakdown

Ich mag ja eigentlich nextcloud. Es ist eine gute Möglichkeit, selber eine Datenhaltungssoftware zu hosten, es steht unter der AGPL, also einer freien Lizenz, die verpflichtet, den Quellcode allen Nutzern bereitzustellen, und es hat viele Funktionen und Einstellungsmöglichkeiten.

Die Einstellungsmöglichkeiten sind aber an sich schon ein Problem. Wie ich schon in „Die dreifache Hölle der Nextcloud-Konfiguration“ geschrieben habe, muss man sowohl nginx als Server kompliziert konfigurieren, dann globale PHP-Einstellungen machen und dann auch noch Einstellungen in Nextcloud selbst. Seit ein paar Versionen jetzt auch noch einen separaten Service und Docker für Plugins (wenn man Plugins haben will).

Anstatt also einfach einen kleinen Server zu starten, den ich dann mit nginx als reverse-Proxy dem Internet vorstellen kann, muss ich von Pontius nach Pilatus laufen, um alle Einstellungen zu machen. Ein Nextcloud-Server hat sogar eine Administratorseite, die auflistet, was alles falsch konfiguriert ist. Allein die Tatsache, dass so etwas notwendig ist, sagt schon viel.

Dazu kommt, dass ich immer wieder Ärger mit Updates habe. Eigentlich habe ich es mir einfach gemacht: Ich habe apt-Pakete von einer Drittpartei geladen, von jurisic.org. Damit kann ich Nextcloud einfach über den Paketmanager aktualisieren. Das Problem ist aber: Ein Major-Version-Upgrade von nextcloud geht immer nur auf die direkt nachfolgende Version. Und jurisic überspringt manchmal Versionen.

In diesem Fall hat mir das eine Menge Arbeit gemacht, manuell Updates zu fahren und danach dem Paketmanager zu erklären, dass jetzt alles in Ordnung sei und er wieder übernehmen darf. Viele graue Haare, nur um ein Update zu fahren.

Jetzt kommen natürlich die Leute, die sagen „Nimm doch einfach das Docker-Image von Nextcloud und lass es als Container laufen“. Und um ehrlich zu sein, das ist vermutlich nicht die schlechteste Idee. Ich könnte mir den ganzen PHP-Krams auf dem Server sparen, alles wäre schön gekapselt in einem Container, und meine nginx-Config würde sich auf ein Minimum beschränken.

Trotzdem müsste ich eine Menge umstellen und korrekt konfigurieren, vom Mounten des Datenverzeichnisses in den Container über die Datenbankkonfig bis hin zu den TLS-Zertifikaten. Ganz zu schweigen davon, dass ich auf dem Server bisher überhaupt keine Docker-Installation habe, die ich auch korrekt einrichten muss, ohne über Fallstricke zu fallen, die dort liegen.

Und wenn ich mir diese Mühe mache ist die Frage: gibt es nicht ein weniger komplexes Tool, das für mich dieselben Aufgaben erledigt? Ich nutze Nextcloud derzeit nur für Dateien. Was ich an Features gerne hätte, wäre:

  • Multi-User-Funktionen
  • Teilen von Dateien mit anderen usern und externen Leuten (über einen Link, mit Ablaufdatem, optional mit Passwort)
  • eine Option für Two-Factor-Authentication
  • automatisches Hochladen von Fotos und anderen Dateien von mobilen & Desktop-Clients (insbes. automatisches Hochladen von Android)
  • Dateivorschau für Verbreitete Dateiformate (insbes. Bilddateien)
  • gute Privacy-Optionen für die Nutzer
  • Bonuspunkte: Unterstützung für CalDav und CardDav

Sollte natürlich auch unter einer freien Lizenz stehen. Idealerweise halt kein PHP. Gibt es so etwas? Ich bin es satt, dass mir Nextcloud jedes Jahr einmal zusammenbricht und ich mir Stunden um die Ohren schlage, um die Probleme zu beheben.

Bilddateiformate und Bildkompression

Anmerkung: Nach der Einleitung folgt eine Anleitung, wie man kleine (von der Dateigröße), und schnell zu ladende Bilddateien erzeugt und welches Bildformat für was man verwenden sollte. TL;DR:

  • Überlegt euch, welche Auflösung eure Bilddateien haben müssen, bevor ihr sie hochladet. Denkt dabei an zu erwartende Bildschirmauflösungen der Betrachter.
  • Für am Computer erstellte Bilder, mit einfarbigen Flächen und klaren Kanten zwischen den Flächen: nutzt verlustfreie Bildformate wie PNG oder WebP (in der verlustfreien Variante).
  • Für Fotos, Zeichnungen und Bilder ohne klare Kanten oder mit unregelmäßigen Flächen: nutzt verlustbehaftete Formate wie JPEG, WebP (in der verlustbehafteten Variante) oder AVIF
  • behaltet beim runterskalieren von Bildern oder beim konvertieren in verlustbehaftete Formate immer die Originaldatei. Wenn ihr wirklich wollt, laded die Originaldatei auch hoch und verlinkt sie. Sie sollte allerdings nicht standardmäßig geladen werden
  • die meisten Websites (aber nicht alle) machen das auch schon. Manche machen es aber nicht gut.

Gestern ist mir auf der Patreon-Seite einer Künstlerin, die ich unterstütze, etwas untergekommen, was mir immer wieder gelegentlich unterkommt. Lange Ladezeiten. In diesem Fall waren große Bildateien schuldig: Es waren neun Bilder, die hauptsächlich aus einem gezeichneten Hintergrund und Text im Vordergrund bestanden. Die Bilddateien waren 8 MiB bis 13 MiB groß. Jede Datei hat einige Sekunden Ladezeit gehabt.

Nun war ich fast dran einen freundlichen (!) Kommentar zu hinterlassen und die Künstlerin zu bitten, die Bilder kleiner zu machen und besser zu komprimieren. Da es aber ein sehr persönlicher und emotionaler Post war, schien mir das unangemessen. Aber ich muss das trotzdem irgendwie loswerden, deswegen dieser Post. Und damit es auch produktiv ist, versuche ich das so zu erklären, dass auch technisch unbedarfte Leute es anwenden können. Speziell möchte ich etwas zu folgenden Punkten erklären:

  1. Bildauflösung und Dateigröße
  2. Bilddateiformate und Bildkompression
  3. und vielleicht noch ein paar Details, die weniger wichtig sind

Von oben nach unten wird es technischer, aber zumindest bis zu Punkt 2 versuche ich, es für alle verständlich zu machen.

Bildauflösung und Dateigröße

Das einfachste, um die Dateigröße zu verringern, ist die Auflösung des Bildes. Wenn man Bilder hochlädt, sollte man sich Gedanken darüber machen, in welchem Kontext und auf welchen Geräten die Bilder angezeigt werden.

Ein Beispiel aus dem Post der Künstlerin, den ich oben erwähnt habe: Es war eine Bildserie aus neun Bildern, wobei man bei jedem Bild kurz da bleibt und dann weitergeht. Meine Bildschirmauflösung ist 1920×1080. Das ist durchaus eine typische Bildschirmauflösung. Viele Leute nutzen heute Tablets oder Smartphones mit kleineren Auflösungen.

Die Bilder hatten eine Auflösung von 2800×3200. Sie waren also drei mal so hoch, wie man sie typisch braucht. Und auch wenn man einen Bildschirm mit höherer Auflösung hätte, würden kleinere Bilder hier trotzdem reichen, um die Botschaft zu übermitteln.

Und die Bildgröße skaliert quadratisch. Wenn man das Seitenverhältnis beibehält und jede Seite drei mal so lang macht, verneunfacht sich die Fläche. Und damit verneunfacht sich auch in etwa der Speicherbedarf.

In diesem Beispiel könnte ich das Bild auf 945×1080 herunterskalieren. Dann wäre es immernoch höher als ich es auf meinem Bildschirm anzeige (weil der Browser auch noch Platz einnimmt), aber statt 13 MiB nur etwa 1,4 MiB groß. Deutlich kleiner also.

Faustregeln zur Bildgröße

  • überlegt euch, wie groß eure Bilddatei sein muss
  • skaliert sie runter, wenn sie zu groß ist, das geht mit jedem Bildverarbeitungsprogramm, vermutlich auch mit MS Paint (Tipp: Behaltet die Originaldatei)
  • wenn ihr trotzdem das Original in voller Pracht zeigen wollt: ladet es separat hoch und verlinkt es. So können Leute, die nur einen kurzen Blick darauf werfen können, die Datei schnell laden und die anderen haben trotzdem Zugriff auf die volle Größe
  • viele große Plattformen machen das übrigens automatisch, aber Patreon offensichtlich nicht

Bilddateiformate und Bildkompression

Es gibt verschiedene Bildformate. Ich konzentriere mich hier auf die, die man im WWW verwenden Kann: GIF, PNG, JPEG, WebP und AVIF (SVG ist hier ein Sonderfall, den ich weiter unten beschreibe).

Unterschiedliche Bildformate haben unterschiedliche Eigenschaften. Manche unterstützen nur eingeschränkte Farbbereiche. Manche können Transparent sein. Manche können animiert sein. Für diesen Post hier ist aber vor allem eins wichtig: Die Formate haben unterschiedliche Kompressionsverfahren.

Bilddateien sind naturgemäß groß, weil sie für jeden Pixel einen Farbwert speichern müssen. Oft haben Bilder aber gewisse Muster, die sich effizenter speichern lassen als jeden Pixel einzeln. Dabei gibt es zwei grundsätzlich unterschiedliche Verfahren, wie Bilder komprimiert werden können: verlustfrei und verlustbehaftet

Verlustfreie Kompression

Verlustfreie Kompression ist ziemlich genau das, wonach es klingt: Die Bilddatei wird ohne Verluste kleiner gemacht. Die Auflösung bleibt gleich, die Farbwerte bleiben gleich, man kann das Eingangsbild 1:1 wieder aus der komprimierten Version erstellen.

Verlustfreie Kompression funktionier am besten mit großen, einfarbigen Flächen und scharfen Kanten dazwischen. Und mit „einfarbig“ meine ich wirklich einfarbig. Nicht „eine Fläche hat ungefähr dieselbe Farbe“, wie man es zum Beispiel in Fotos hat. Ein Beispiel: Man scanne ein weißes DIN-A4-Blatt ein. Als Mensch würde man sagen, dass das Blatt einheitlich weiß ist. Bei einem ausreichend guten Scanner stellt sich aber heraus: im Papier sind jede Menge kleine Strukturen.

Für den Computer macht das einen riesigen Unterschied. Vereinfacht gesagt kann er z.B. bei einem 1000×1000 Pixel großen, komplett weißen Bild sagen: „Das sind 1000×1000 Pixel, alle weiß“ und hat damit das Bild perfekt beschrieben. Bei einem 1000×1000 Pixel großen Scan einer weißen Papierseite ist praktisch jedes Pixel ein kleines bisschen anders, und zwar um einen zufälligen Betrag. Das lässt sich deutlich schlechter beschreiben.

Allgemein also: Am Computer erstellte Bilder mit einfarbigen flächen und scharfen Kanten lassen sich gut komprimieren. Ein Beispiel für ein solches Bild wäre eines meiner Fordite-Bilder:

Geschwungene rote, gelbe und braune Flächen, Die Flächen haben komplizierte Formen, aber scharfe Kanten zwischen ihnen

Verbreitete Bildformate mit verlustfreier Kompression sind GIF, PNG und WebP (bei WebP aufpassen, WebP kann sowohl verlustfreie als auch verlustbehaftete Kompression). Empfehlung: Nehmt WebP, das hat üblicherweise die beste Kompression dieser Formate. Wenn die Seite WebP nicht unterstützt, nehmt PNG. GIF hat eine deutlich schlechtere Kompression und unterstützt weniger Farben in einem Bild.

Die Bilder, über die ich mich in der Einführung beschwert habe, waren handgezeichnete Bilder. Schöne Bilder, aber viel zu unregelmäßig für verlustfreie Kompression. Die Ursprungsdatei war 13 MiB groß, mit ein paar Tricks (siehe „Kompression optimieren“ weiter unten) habe ich eine 5,9 MiB große PNG-Datei herausgekriegt. Mit verlustfreiem Webp kommt man runter auf 4,4 MiB. Immernoch ziemlich groß

Verlustbehaftete Kompression

Das Gegenstück zu verlustfreier Kompression ist verlustbehaftete Kompression. Und wie der Name schon sagt, verliert das Bild etwas bei der Kompression. Idealerweise Informationen, die man beim Betrachten des Bildes nicht wirklich wahrnimmt. Verlustbehaftete Kompression eignet sich gut für „natürliche“ Bilder, wie zum Beispiel Fotos oder Handzeichnungen, aber auch recht gut für Zeichnungen, die am Computer erstellt wurden, aber so komplex sind, dass sie recht unregelmäßig sind.

Ein Beispiel dafür wäre dieses Foto:

Eine grüne Fußmatte, auf der in schwarzen Buchstaben „Keine Panik“ steht.

Bei Bildern solcher Art ist es meist nicht wichtig, wenn ein paar Details verloren gehen. Aber es gehen Details verloren. Man kann das gerade bei Bildern gut sehen, die sich sehr gut für verlustfreie Kompression eignen. Ein Beispiel hier wäre Napstablook:

Ein trauriger weißer Geist auf dunklem Hintergrund.

Wenn ich den jetzt stark verlustbehaftet komprimiere, sieht er so aus:

Der Geist von vorhin, allerdings mit komischen grauen Klecksen überall

Wenn ihr das bei der Auflösung nicht seht, zoomt herein, dann sieht man es ganz deutlich: Jede Menge graue Flecken auf dem weißen Geist. Das nennt man „Artefakte“ (oder „Kompressionsartefakte“), weil es durch die Kompression hinzugefügte Eigenschaften des Bildes sind. Fun Fact: Da sich Napstablook sehr gut für verlustfreie Kompression eignet (nur zwei Farben, große, einheitliche Flächen, klare Kanten), ist die JPEG-Datei selbst bei sehr geringer Qualität mehr als vier Mal so groß wie die verlustfreie Variante.

Üblicherweise kann man bei verlustbehafteter Kompression eine „Qualität“ angeben, die von 0 bis 100 geht. Je höher die Qualität, desto weniger auffällig sind die Artefakte, aber desto schlechter ist die Kompression. Das ist ein Trade-off. Wenn ihr beim Abspeichern eines Bildes eine Qualität angeben sollt, dann ist die Kompressionsqualität gemeint. Bei verlustfreien Formaten hingegen muss man keine Qualität angeben, denn sie geben das Ursprungsbild perfekt wieder.

Verbreitete Formate mit verlustbehafteter Kompression sind JPEG, WebP (auch hier: aufpassen, WebP unterstützt beides) und AVIF. Wenn ich die oben erwähnten Bilder der künstlerin verlustbehaftet abspeichere, komme ich auf etwa 940 kiB für JPEG (Qualiät 90), 235 kiB mit WebP (Qualität 70) und nur 141 kiB für AVIF (Qualität 50). Zum Erinnerung: Verlustfrei komme ich auf bestenfalls 4,4 MiB. Das ist ein sehr gutes Zeichen, dass verlustbehaftete Kompression hier die richtige Wahl ist.

Empfehlung: nutzt WebP oder AVIF, wenn die Website, auf der ihr das Bild hochladet, das unterstützt. Sonst nutzt JPEG. Brauchebare Qualitätswerte sind bei JPEG 90, bei WebP 70 und bei AVIF 50. Früher gab es mal online tools, um die Formate bei verschiedenen Qualitäten direkt zu vergleichen, ich konnte aber mit einer kurzen Suche keine mehr finden. Im Zweifelsfall müsst ihr herumprobieren, wie viel Qualitätsverlust für den gegebenen Anwendungsfall ertragbar ist.

Faustregeln zu Bildformaten

  • nutzt verlustfreie Formate wie PNG und WebP (in der verlustfreien Variante) für am Computer erstellte Bilder mit größeren, einfarbigen Flächen und scharfen Kanten
  • nutzt verlustbehaftete Formate wie JPEG, WebP (in der verlustbehafteten Variante) oder AVIF für Fotos, von Hand gemalten oder gezeichneten Bilden und Ähnlichem
  • vermeidet, dasselbe Bild mehrfach in Kette in verschiedenen Formaten verlustbehaftet zu komprimieren, die Qualitätsverluste akkumulieren sich
  • behaltet immer das Originalbild irgendwo, wenn ihr verlustbehaftet komprimiert

Anderer Krams

Hier wird es ein bisschen technischer, aber trotzdem nicht übermäßig kompliziert.

Kompression optimieren

Nicht jede Kompression ist gleichwertig. Insbesondere bei PNG-Dateien kann man oft viel Platz sparen, wenn man die Datei mit passenden tools wie optipng oder zopflipng optimiert. Der Tradeoff ist hier: Man wendet einige Sekunden bis Minuten an Rechenzeit auf, um die Kompressionsrate eines Bildes zu verbessern. Das lohnt sich besonders, wenn man erwartet, dass ein Bild sehr oft heruntergeladen wird.

optipng läuft deutlich schneller als zopflipng, aber zopflipng hat üblicherweise ein bisschen kleinere Ergebnisse. In den meisten Fällen sollte optipng ausreichen. WebP (verlustfrei) ist aber in der Regel schneller als beide und erzeugt kleinere Dateien. Deswegen wenn möglich WebP verwenden.

Auch für JPEG gibt es ein Optimierungstool namens jpegoptim, dass JPEG-Dateien verlustfrei optimiert (d.h. der Verlust wird nicht schlimmer, als er es ohnehin schon ist). Die Verkleinerung ist aber deutlich geringer als bei den PNG-Optimierungstools. Auch hier: WebP (verlustbehaftet) und AVIF erzeugen bei vergleichbarer Bildqualität kleinere Dateien.

Bilder in HTTP und HTML

Wenn man selber eine Website schreibt, hat man mehr Freiheiten, was die Bildformate angeht. Hier ein paar Tipps:

Wenn man nicht sicher ist, welches Format ein Client (Browser) unterstützt: der Client kann mit dem Accept-Header angeben, welche Formate er unterstützt, und der Server kann entsprechend Ergebnisse zurückgeben. So kann man zum Beispiel auf derm Server etwas größere PNG und kleinere WebP-Versionen desselben Bildes liegen haben, die dann entsprechend der Anforderung zurückgeliefert werden.

Was die Bildauflösung angibt: Das <picture>-Element in HTML bietet eine Möglichkeit, den Browser je nach Bildschirmauflösung die richtige Bildauflösung zu wählen. So kann z.B. ein Smartphone-Browser kleinere Bilder laden als ein Browser auf einem Computer mit einem großen Bildschirm.

Daneben gibt es auch Möglichkeiten, Bilder je nach Bildschirm mit unterschiedlichen Seitenverhältnissen anzuzeigen. Dazu gibt es den MDN-Artikel zu responsive images.

Allgemein bietet es sich auch an, dass der Server Cache-Anweisungen für Bilder mitgibt, damit der Browser die Bilder lokal vorhält und nicht bei jedem Laden der Seite neu laden muss.

AVIF und Verlustfreiheit

Ich habe oben so getan, als ob AVIF immer verlustbehaftet ist. Das ist nicht korrekt. Ähnlich wie WebP gibt es auch bei AVIF eine verlustfreie Variante. Die komprimiert allerdings in allen Versuchen, die ich bisher gemacht habe, deutlich schlechter als PNG, deswegen habe ich sie hier ignoriert. Kann aber auch sein, dass das daran lag, dass der encoder, den ich verwendet habe, nicht besonders gut war.

Sonderfall Vektorgrafiken

Ich habe in diesem Artikel bisher nur Rastergrafiken behandelt. Das sind Grafiken, wo das Bild pixelweise aufgebaut ist. Es gibt aber noch einen grundverschiedenen Bildtyp: Vektorgrafiken. Hier sind die Bildinformationen als Beschreibung geometrischer Figuren gespeichert. Das bedeutet, diese Bilder lassen sich beliebig skalieren, ohne dass sie an Qualität verlieren. Ihr Anwendungsbereich ist aber begrenzt: Es ist einfach, eine Rastergrafik aus einer Vektorgrafik zu erzeugen. Umgekehrt ist es schwierig bis unmöglich und praktisch nie eine 1:1-Abbildung des ursprünglichen Bildes.

Das einzige im WWW verbreitete Vektorgrafikformat ist SVG.

Rollenspielszenen: Baumaterial „finden“

Rollenspielszene: Nachdem wir Mel wiedergefunden haben, haben wir noch die Miniatursonne besiegt, die immer noch die Gegend unsicher gemacht und eine U-Bahn-Baustelle der mysteriösen Corporation zerlegt hat.

Dummerweise wurde Jacksnipe dabei von der Miniatursonne so geblendet, dass sie kaum noch sehen kann (gerade einmal hell und dunkel unterscheiden geht noch). Also suchen wir nach jemandem, der sie behandeln kann. In einer nahegelegenen Siedlung, Shroomville, finden wir eine Gärtnerin, die uns an einen geschickten Mediziner verweist.

Wir erzählen den Leuten dort auch von der Baustelle, denn die Leute hatten bei unserem letzten Besuch über seltsame Erschütterungen geklagt. Die Baustelle besorgt sie, denn sie fürchten, dass die Höhle ihrer Siedlung einstürzen könnte. Sie bräuchten Material, um die Höhlendecke abzustützen.

Sie wären uns sehr dankbar, wenn wir Material „finden“ könnten, das die Corporation nicht mehr braucht. Gerne. Fuck the Corpo, und außerdem ist es immer gut, in einer Siedlung willkommen zu sein.

Die Frage ist nur: Wo „finden“ wir am Besten Baumaterial, ohne dass die Corporation es wieder zurückfindet? Und vielleicht sollten wir vorher Jacksnipes Augenlicht wiederherstellen.

Rollenspielszenen: Der Vogelschutzbund

Rollenspielszene. Wir wollen den Wald retten, weil dieser für ein Militär-/Industriegelände (und für das Holz) abgeholzt werden soll.

Dafür brauchen wir so viele Leute wie möglich, die sich dagegen stellen. Siobhan, jung und rebellisch, sucht nach örtlichen Umweltschutzvereinen. Sie findet als einziges den örtlichen Vogelschutzbund aus älteren, konservativeren Leuten. Nach einem kurzen Gespräch will sie schon fast wieder gehen, aber

Nein, geh nicht, wir kriegen so selten neue Mitglieder!

Siobhan bleibt, und berichtet den entsetzten Vogelschützern von den Abholzungsplänen. Deren Uterstützung haben wir also. Ob Siobhan jetzt demnächst Nistkästen aufhängen muss, ist noch offen.

Schneckenfressende Schnecken

Wer einen Garten hat, kennt den Ärger. Kaum hat man ein zärtliches Pflänzchen eingepflanzt, kommen alle Nacktschnecken aus dem Umkreis und fressen es auf.

Alle Nacktschnecken? Nein! Der Tigerschnegel frisst u.a. auch anderen Schnecken und deren Eier. Er hat auch ein markantes Muster, also achtet darauf, beim Schneckenbeseitigen diese Schnecke in Ruhe zu lassen.

Rollenspielszenen: Vanillekipferl

Rollenspielszene. Rocket Mel wacht nach einem Sturz in einen (nicht ganz so) bodenlosen Abgrund wieder auf. Durch die geschlossenen Augen erfasst sie grelles Licht. Alles in ihrem Körper spricht sich dagegen aus, aufzustehen, aber

Du wird nicht Rocket Mel, wenn du auf deinen Körper hörst, wenn er dir sagt, dass du etwas nicht tun sollst.

Ein paar Stunden später findet der Rest der Gruppe Mel endlich wieder. Nach einigen sehr verworrenen Plänen (die einen vanillekipferlfressenden Drachen beinhalteten) haben sie sich einfach ein sehr langes Seil genommen und sind in den Abgrund geklettert. Mel ist erleichtert:

Wo wart ihr so lange?!? Ich bin fast verrückt geworden!

Midnight Steel verteidigt sich:

Sorry! Ich musste erst noch Vanillekipferl backen.

Rollenspielszenen: Ich war high!

Rollenspielszene: Wir arbeiten einen Plan aus, wie wir Mel retten, die am Ende der ersten Session in einen bodenlosen Abgrund gefallen ist.

Midnight Steel überlegt, ob wir uns vielleicht an einem Seil herunterlassen könnten. Jacksnipe antwortet, dass sie das schon versucht haben. Midnight Steel kann sich nicht daran erinnern. Jacksnipe:

Wie kannst du dich nicht daran erinnern? Du hast das Seil gehalten!

Midnight antwortet darauf nur:

Da war ich high!

Nicht unbedingt das, was man hören möchte von der Person, der man in dem Moment sein Leben anvertraut hat.

Den Button neu erfinden

Ich ärgere mich ja immer mal wieder darüber auf, dass es Single-Page-Apps so verbreitet sind. Eine HTML-Seite, Unmengen an Javascript, lange Ladezeiten, komische Bugs. Das habe ich zum Beispiel in diesem Blogpost aus 2024 dargelegt. Auch 2010 habe ich schon einen rant darüber geschrieben.

Ein weiterer dummer Aspekt ist, dass man in solchen single-page-apps jede Menge Funktionalität re-implementieren muss, die der Browser von Natur aus schon kann. Navigation zwischen „Seiten“ zum Beispiel, die in einer SPA natürlich rein clientseitig passiert. Und ich muss zugeben, dass ich hier Teil des Problems bin. Nicht privat, aber beruflich. Nicht, weil es mir gefällt, sondern weil es unmöglich ist, Kunden und Kollegen davon zu überzeugen, es anders zu machen (sprich: Alle Grundfunktionen sollten ohne JS laufen, JS wird nur dort eingesetzt, wo es nicht anders geht oder um den Komfort zu erhöhen).

Wo ich nicht Teil des Problems bin, ist aggressiver Einsatz von nicht-semantischem HTML. Zum Beispiel ein <span> mit einem onClick-Handler versehen und es dann wie einen Link zu behandeln. Das ist nicht barrierefrei, umgeht wichtige Funktionen des Browsers (wie z.B. das „in neuem Tab öffnen“) und ist schlicht und einfach falsch.

Jetzt könnte man sagen: „Ja, aber man kann ja alle diese Eigenschaften vergeben.“ Mit aria-Rollen, noch mehr Javascript, Fokussierbarkeit usw. Kann man vielleicht. Ich habe einen Artikel gefunden, in dem jemand das mal gezielt ausprobiert hat: If you want to create a button from scratch, you must first create the universe.

Das Ergebnis ist: etwa 500 Zeilen Javascript-Code, und das Ergebnis ist in keiner Weise besser als ein einfaches <button>. Und in der Praxis macht sich keiner diese Mühe, und es kommt ein blasser Schatten eines Buttons heraus. Aber wir müssen halt immer wieder das Rad neu erfinden.

Antidemokratische Umwälzung

Ich habe neulich den Podcast „Deutschland 33/45“ gefunden (über den Deja-vu Geschichte-Podcast). Darin wird detailliert die Politik und die Gesellschaftlichen Begebenheiten des Nazi-Regimes in Deutschland in chronologischer Reihenfolge erzählt. Ich bin in diesem Podcast immer noch im Jahr 1933, und der Podcast behandelt die Machtübernahme deutlich detaillierter als es z.B. in der Schule durchgenommen wird.

Jedenfalls wird dort auch beschrieben, wie die Nazis (sehr) schnell ihre Leute überall eingesetzt haben, in der Polizei, in den Regierungen, in Ämtern, an Unis. Und diese Strategie verwenden Demokratiefeinde heute noch. Man kann zum Beispiel in die USA unter Trump schauen. Natürlich trifft Trump nicht auf die gleiche Situation die Hitler, und kann damit auch nicht ganz so schnell und ohne großen Widerstand seine Demokratiezerstörung umsetzen. Aber gewisse Ähnlichkeiten gibt es doch: Einschießen auf ein Feindbild, Beschwichtigungen, damit einiges nicht so schlimm ausgeht, Wortbrüche immer und immer wieder, Verbreitung von Bullshit, und so weiter.

Aber wir müssen nicht einmal nach Amerika schauen. Auch hier in Deutschland haben wir eine rechtsextreme Partei, die in den Umfragen katasrtophal gut abschneidet (als „erschreckend gut abschneiden“ würde ich schon alles über 1% bezeichnen, aber die sind mittlerweile im zweistelligen Bereich).

Und wie dieser Artikel hier darlegt, wird die AfD auch nicht zögern, „Reinigungsaktionen“ durchzuziehen. In Sachsen-Anhalt plant sie demnach, falls sie an die Regierung kommt, missliebige Beamte zu versetzen, Demokratieprojekten, Flüchtlingshilfe und queeren Organisationen de Geldhahn zuzudrehen, usw. Und es wird nicht laut, sondern leise. So wie die Nazis Anfang 1933 ihren Extremismus heruntergespielt haben, so wird es auch die AfD tun. So wie die Nazis 1933 Menschen „in Schutzhaft“ nahmen und „kommunistische Terroristen“ verfolgten, so wird auch die AfD einen Weg finden, das alles als glorreiche Errungenschaft ihrer Politik darzustellen.

Und ebenso wie bei den Nazis, ebenso wie bei Trump, kann niemand sagen, dass man das vorher nicht wissen konnte. Alle haben während ihres Wahlkampfes immer wieder angekündigt, was sie machen werden. Man sollte nicht viel glauben, was die AfD erzählt, aber hier sollte man es glauben. Auch wenn sich AfD-Politiker oft weniger extremistisch äußern und die extremistischen Forderungen herunterspielen, so sind sie doch Kern des Parteiprogramms, und Lippenbekenntnisse, dass das ja alles nicht stimmen würde, sind eben nicht mehr als Lippenbekenntnisse.