Startseite hochwertiger: Typografie, Weltfarben, Event-Karte

Wunsch 27.08.2026: "soll nur noch hochwertiger und professioneller
aussehen." Kein neues Design, sondern die Details, die den Unterschied
zwischen "gemacht" und "gesetzt" ausmachen:

- Ueberschrift enger gesetzt (-.022em, Zeilenabstand 1.08, text-wrap:
  balance). Bei 4rem wirkt normale Laufweite auseinandergefallen; die
  drei Zeilen verteilen sich jetzt gleichmaessig statt mit kurzer
  Restzeile.
- Jede Welt-Kachel traegt die Farbe IHRER Welt statt dreimal derselben:
  Babyblau, Silber, das gedeckte Rot von Spicy Media. Die Werte sind
  nicht erfunden, sondern die --accent-Toene der drei Themendateien.
- Plaketten ("WELT 1") klein, in Versalien, weit gesperrt -- liest sich
  als Kapitelmarke statt als Beschriftung.
- Event-Karte: Datum als gesperrte Versalzeile (ordnet sich dem Titel
  unter), "Mehr erfahren" als ruhiger Knopf statt nacktem Textlink,
  Haarlinie am Bild, Text auf 5 Zeilen begrenzt -- damit nicht die
  Textlaenge aus der Verwaltung das Aussehen der Startseite bestimmt und
  bei zwei Events beide Kacheln gleich hoch sind (geprueft: 572/572px).

ZWEI FUNDE BEIM PRUEFEN, BEIDE WICHTIGER ALS DER FEINSCHLIFF:

1. INHALTSRICHTLINIE UND ZEILENENDEN. Der Browser rechnet die Pruefsumme
   eines Inline-Skripts NICHT ueber die Bytes der Datei, sondern ueber
   den Text im Dokument -- und der HTML-Parser ersetzt beim Einlesen
   jedes CR LF durch LF (HTML-Spezifikation, "preprocessing the input
   stream"). Eine Datei mit Windows-Zeilenenden ergibt serverseitig also
   eine ANDERE Summe, und die Seite fuehrt ihr eigenes Skript nicht mehr
   aus: kein Live-Status, keine Events, nichts. Live war es unauffaellig
   (Linux-Auscheckung hat LF), auf dem Windows-Rechner sofort tot
   (core.autocrlf=true). inhaltsrichtlinie.js vereinheitlicht jetzt vor
   dem Rechnen auf LF -- das ist die Summe, die der Browser wirklich
   bildet, und macht die Richtlinie unabhaengig davon, mit welchem
   Werkzeug eine Datei zuletzt gespeichert wurde.

2. TESTS MIT FESTEM PORT KOENNEN LUEGEN. Drei Server aus frueheren
   Laeufen liefen noch. Neue Testlaeufe konnten ihren Port nicht belegen,
   starben still -- und massen weiter gegen den ALTEN Code. Ergebnis
   waren Fehlermeldungen zu einem laengst behobenen Fehler. pruef-musik,
   pruef-kasse und pruef-startseite suchen sich jetzt einen freien Port.

Neuer Test pruef-startseite.mjs (19 Pruefungen) mit FESTEN Event-Daten:
Beim Pruefen kam einmal nichts vom Server, der Abschnitt blieb leer und
der Test haette "kein Fehler" gemeldet, obwohl er nichts gesehen hat.
Geprueft werden Maske am Artwork, genau eine Kachel bei einem Event,
volle Breite, saubere Textkuerzung auf ganze Zeilen, eigene Weltfarben,
zwei gleich hohe Kacheln bei zwei Events, Handy ohne Ueberlauf.

Alles gruen: startseite 19, musik 17, kasse 15, inhaltsrichtlinie 22,
handy 56.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/inhaltsrichtlinie.js

@@ -111,10 +111,31 @@ const merker = new Map();
 
 /* Findet alle Inline-Skriptblöcke und bildet je Block die Prüfsumme.
 
-   Wichtig: Gerechnet wird über den Inhalt EXAKT so, wie er zwischen den
-   Tags steht -- kein Trimmen, keine Umwandlung von Zeilenenden. Der
-   Browser rechnet über dieselben Bytes; schon ein entferntes Leerzeichen
-   ergibt eine andere Summe und damit ein blockiertes Skript. */
+   Gerechnet wird über den Inhalt exakt so, wie er zwischen den Tags
+   steht -- kein Trimmen. Schon ein entferntes Leerzeichen ergibt eine
+   andere Summe und damit ein blockiertes Skript.
+
+   ⚠️ MIT EINER AUSNAHME: ZEILENENDEN (gefunden 27.08.2026)
+
+   Der Browser rechnet NICHT über die Bytes der Datei, sondern über den
+   Text, wie er im Dokument ankommt. Und der HTML-Parser ersetzt beim
+   Einlesen jedes CR LF und jedes einzelne CR durch ein LF -- das steht
+   so in der HTML-Spezifikation ("preprocessing the input stream"). Eine
+   Datei mit Windows-Zeilenenden ergibt also serverseitig eine andere
+   Summe als im Browser, und die Seite führt ihr eigenes Skript nicht
+   mehr aus.
+
+   Aufgefallen ist es beim Prüfen der Startseite auf dem Windows-Rechner:
+   Das Skript war blockiert, obwohl die Datei fehlerfrei war -- die
+   Arbeitskopie hat CR LF (git core.autocrlf=true), das Verzeichnis auf
+   dem Server hat LF. Live lief es deshalb, lokal nicht. Genau solche
+   Unterschiede fressen Stunden, weil man den Fehler im eigenen Code
+   sucht.
+
+   Deshalb wird hier auf LF vereinheitlicht, bevor gerechnet wird. Das
+   ist keine Bequemlichkeit, sondern die Summe, die der Browser wirklich
+   bildet -- und es macht die Richtlinie unempfindlich dagegen, mit
+   welchem Werkzeug eine Datei zuletzt gespeichert wurde. */
 function summenBilden(html) {
   const summen = [];
   /* Nur Blöcke OHNE src. Ein <script src="..."> hat keinen Inhalt, der
@@ -124,7 +145,10 @@ function summenBilden(html) {
   while ((treffer = muster.exec(html)) !== null) {
     const inhalt = treffer[1];
     if (!inhalt) continue;
-    const summe = crypto.createHash("sha256").update(inhalt, "utf8").digest("base64");
+    /* Genau die Normalisierung, die der HTML-Parser vornimmt: CR LF und
+       einzelnes CR werden zu LF (siehe Begründung im Kopf dieser Funktion). */
+    const wieImBrowser = inhalt.replace(/\r\n?/g, "\n");
+    const summe = crypto.createHash("sha256").update(wieImBrowser, "utf8").digest("base64");
     summen.push(`'sha256-${summe}'`);
   }
   return summen;