philosophy

Diese Seite beschreibt Entscheidungen, nicht einen Technologie-Kult

Grundhaltung – Technik soll ruhig, lesbar und dauerhaft bleiben

Das SSLXY-Leitbild vermeidet es, Webseiten allein deshalb größer oder komplizierter zu machen, weil zusätzliche Technik verfügbar ist. Vieles, was modern wirkt, kann zugleich schwerer, unübersichtlicher und schneller veraltet sein. Entscheidend ist deshalb nicht, möglichst viel Technik unterzubringen, sondern eine Aufgabe mit möglichst wenig unnötiger Komplexität stabil und nachvollziehbar zu lösen.

Diese Haltung hat viel mit der Rechnergeschichte davor zu tun. Wer mit Systemen gearbeitet hat, bei denen Speicher, Datenträger und Stabilität reale Grenzen waren, entwickelt fast automatisch eine andere Disziplin. Man überlegt früher, was wirklich nötig ist. Man trennt eher Wichtiges von Schmuck. Man lernt, dass Klarheit nicht altmodisch ist, sondern meist die robustere Lösung.

Guter Code gilt hier nicht als Ansammlung cleverer Einfälle, sondern als saubere Ordnung. Eine Datei soll auch Monate oder Jahre später lesbar, ruhig aufgebaut und in sich logisch bleiben. Langfristige Verständlichkeit ist damit ein eigenes Qualitätsmerkmal.

„Guter Code erklärt sich nicht durch Lautstärke, sondern durch innere Ordnung.“

Einfachheit ist nicht dasselbe wie Simplismus

Eine technische Lösung ist nicht automatisch gut, nur weil sie kurz ist. Gute Einfachheit entsteht, wenn eine Lösung die tatsächliche Aufgabe vollständig erfüllt und dabei möglichst wenig unnötige Komplexität einführt.

Manchmal braucht eine Aufgabe JavaScript, serverseitige Logik, Datenhaltung oder externe Dienste. Dann ist zusätzliche Technik gerechtfertigt. Die Philosophie besteht nicht darin, Komplexität grundsätzlich zu verbieten, sondern sie sichtbar und begründbar zu halten.

„So einfach wie möglich – aber nicht einfacher als die Aufgabe.“

Warum HTML von Hand

Handgeschriebenes HTML ist in diesem Leitbild weder Romantik noch Selbstzweck. Es ist eine direkte und kontrollierbare Form, Seitenstruktur auszudrücken. Sichtbar bleibt, was tatsächlich im Dokument steht, wie Inhalte gegliedert sind und welche Struktur Browser, Suchsysteme, Assistenztechnik und Menschen erhalten. Unnötige Zwischenebenen sollen vermieden werden, nicht sinnvolle Werkzeuge.

Gerade bei kleineren und mittleren Webauftritten ist diese Direktheit ein Vorteil. Statt Strukturen erst aus einem System herauszuverhandeln, kann man sie direkt, sauber und eindeutig schreiben. Überschriften, Absätze, Listen, Navigation, Bilder, semantische Bereiche – das alles lässt sich schlicht und klar aufbauen, ohne dass ein schweres Umfeld nötig wäre.

Das bedeutet nicht, dass alles immer ultraminimal sein muss. Es bedeutet nur, dass jede zusätzliche Schicht begründet sein sollte. Wenn eine Datei mit der Zeit wächst, ist das in Ordnung, solange sie noch eine erkennbare Ordnung hat. Unordnung entsteht nicht durch Länge, sondern durch fehlende Struktur.

HTML ist Struktur und Bedeutung, nicht nur ein Träger für CSS

Der WHATWG HTML Living Standard beschreibt HTML mit definierten Elementen, Semantik, Struktur und APIs. Für das Archiv folgt daraus: Überschriften, Navigation, Abschnitte, Listen, Links, Tabellen und Formulare werden nach ihrer Aufgabe gewählt – nicht nur danach, welche Box sich am leichtesten gestalten lässt.

Semantik unterstützt mehrere Ebenen gleichzeitig: Menschen, Browser, Assistenztechnik, Suchsysteme und die spätere Wartung einer Datei. Struktur bleibt dadurch auch dann lesbar, wenn die ursprüngliche Bearbeitung lange zurückliegt.

Handgeschrieben bedeutet nicht ungeprüft

Direkter Code profitiert besonders von maschineller Prüfung: HTML-Conformance, JSON-LD-Parsing, JavaScript-Syntax, interne Links, doppelte IDs und fehlende Sprungziele lassen sich automatisiert prüfen.

Der HTML-Standard selbst unterscheidet zwischen Fehlern, die maschinell geprüft werden können, und solchen, die menschliche Beurteilung brauchen. Ein Validator ersetzt deshalb kein Review, aber er verhindert, dass triviale Strukturfehler unnötig menschliche Aufmerksamkeit binden.

Struktur und CSS – Gestaltung soll führen, nicht überdecken

CSS dient hier nicht der Effekthascherei. Gestaltung darf sauber und stimmig sein, soll aber Inhalte tragen und Orientierung geben. Bevorzugt werden ruhige Layouts, klare Abstände, nachvollziehbare Farben und eine Typografie, die auch bei längeren Texten lesbar bleibt.

Gerade bei Informationsseiten ist das wichtig. Wenn jede Box, jede Zeile und jeder Bereich Aufmerksamkeit schreit, verliert der eigentliche Inhalt an Gewicht. Gute Gestaltung ist oft eher die Kunst, Unruhe zu vermeiden. Farben, Linien, Rahmen, Hervorhebungen und Abstände sollen nicht dekorativ um ihrer selbst willen sein, sondern logisch.

„Gestaltung soll Inhalte lesbarer machen, nicht lauter.“

Wiederkehrende Muster sind ein kleines Designsystem – auch ohne Framework

Konsistente Abstände, Boxen, Navigationsmuster, Fokuszustände und Typografie erzeugen eine gemeinsame Sprache. Dafür ist nicht automatisch ein großes Komponenten-Framework nötig.

Ein kleiner Satz bewusst gepflegter Klassen kann für eine überschaubare statische Website dieselbe Aufgabe erfüllen: Wiederverwendung, Konsistenz und geringere Fehlerwahrscheinlichkeit.

JavaScript nur dort, wo es wirklich etwas verbessert

JavaScript wird nicht grundsätzlich abgelehnt. Kritisch ist vielmehr sein reflexartiger Einsatz an Stellen, an denen keine echte Interaktion oder Verbesserung entsteht. Skripte sollen Werkzeug sein, nicht automatisch die Ausgangsbasis jeder Funktion.

JavaScript ist dann sinnvoll, wenn es Bedienung verbessert, Barrieren reduziert oder klar begrenzte dynamische Aufgaben übernimmt, die ohne Skript unnötig umständlich wären. Ein To-top-Button, eine sauber begründete Lightbox, ein Datumsstempel oder gezielte Kartenlogik können dafür Beispiele sein. Jede zusätzliche Skriptfunktion muss ihren Nutzen gegenüber Komplexität und Ausfallrisiko rechtfertigen.

Gerade statische Seiten profitieren von dieser Zurückhaltung. Was nicht dynamisch sein muss, erzeugt keine unnötige Komplexität. Eine kleinere Zahl beweglicher Teile erleichtert in vielen Fällen Wartung, Prüfung und Absicherung. Das ist keine Minimalismus-Ideologie, sondern eine dokumentierte Architekturentscheidung.

Die Grundfunktion zuerst, Komfort darüber

Für Informationsseiten ist ein einfacher Grundsatz besonders robust: Der eigentliche Inhalt, die Links und die Navigation sollten bereits in der HTML-Struktur vorhanden sein. CSS verbessert die Darstellung; JavaScript ergänzt Verhalten.

Das heißt nicht, dass jede moderne Anwendung ohne JavaScript vollständig funktionieren muss. Es heißt, dass eine Funktion nicht unnötig von einer komplexeren Schicht abhängig gemacht wird, wenn die Kernaufgabe auch darunter sinnvoll bestehen kann.

Robuste Seiten planen auch den Ausfall einer Komfortschicht mit ein

SEO und Inhalt – lieber saubere Struktur als leere Tricks

Suchmaschinenoptimierung beginnt in diesem Leitbild nicht bei Tricks, sondern bei Ordnung. Ein sauberer Seitentitel, nachvollziehbare Gliederung, ehrliche Beschreibungen, klare interne Verlinkung und inhaltliche Substanz bilden die Grundlage. Kurzfristige Optimierungsmechanik ersetzt keine gute Informationsarchitektur.

SEO ist wichtig, steht aber nicht über dem Besucher. Eine gute Platzierung nützt wenig, wenn danach eine unklare, veraltete oder enttäuschende Seite folgt. Sichtbarkeit ist hilfreich; Vertrauen, Orientierung und ehrliche Information bleiben wichtiger.

Texte werden deshalb zuerst auf Verständlichkeit für Menschen ausgerichtet. Logische Gliederung, echte Information und sprachliche Präzision bilden zugleich eine solide technische Grundlage. Schlechte Inhalte werden durch Metadaten nicht gut; gute Inhalte können durch saubere Struktur besser auffindbar werden.

Künstliche Überoptimierung wird vermieden. Texte sollen nicht mit wiederholten Begriffen überladen werden, wenn dadurch Lesbarkeit und Informationswert sinken. Gute SEO wird hier als Verbindung aus technischer und sprachlicher Disziplin verstanden.

„Eine Seite sollte nicht für Suchmaschinen klingen, sondern für Menschen. Saubere Technik hilft beiden – aber der Besucher kommt zuerst.“

Menschen-zuerst ist keine Gegenposition zu sauberem SEO

Google beschreibt SEO selbst als Hilfe für Suchmaschinen, Inhalte zu verstehen, und für Nutzer, diese Inhalte zu finden. Gleichzeitig empfiehlt Google ausdrücklich hilfreiche, verlässliche und „people-first“ Inhalte statt Texte, die primär zur Manipulation von Rankings erzeugt werden.

Das passt unmittelbar zum Archivleitbild: Eine Seite darf technisch suchfreundlich sein, ohne sprachlich wie eine Suchmaschine zu klingen. Titel, interne Verlinkung, strukturierte Daten und klare Gliederung unterstützen echte Information – sie ersetzen sie nicht.

Bedienbarkeit – Technik muss nicht nur geladen, sondern auch benutzt werden können

Bedienbarkeit ist kein Zusatz und keine späte Nacharbeit. Sie gehört von Anfang an in die Struktur. Eine Seite, die optisch ordentlich wirkt, aber mit Tastatur, Fokus, Bewegung oder Lesbarkeit schlecht umgeht, ist technisch nicht fertig.

Dazu gehören klare Überschriften, verständliche Fokuszustände, ausreichende Kontraste, sinnvolle Linktexte, verlässliche Navigation und reduzierbare Bewegung. Eine Informationsseite muss kein Sonderprojekt für Barrierefreiheit sein, sollte aber vermeidbare Ausschlüsse nicht durch dekorative oder technische Entscheidungen erzeugen.

Auch hier gilt das Grundprinzip: nicht aufblasen, sondern sauber bauen. Gute Zugänglichkeit entsteht häufig durch Semantik, klare Logik und bewusste Zurückhaltung bei unnötigen Interaktions- und Animationseffekten.

WCAG 2.2 ist ein Prüfrahmen – Bedienbarkeit bleibt praktische Arbeit

WCAG 2.2 wurde am 5. Oktober 2023 erstmals als W3C Recommendation veröffentlicht; die Recommendation erhielt später eine aktualisierte Fassung. Sie ergänzt gegenüber WCAG 2.1 unter anderem Anforderungen zu nicht verdecktem Fokus, Dragging, Mindestzielgrößen, konsistenter Hilfe, redundanter Eingabe und zugänglicher Authentisierung.

Für die Archivseiten bedeutet das nicht, Standardtexte in die Oberfläche zu übertragen. Entscheidend ist, die Bedienbarkeit an überprüfbaren Kriterien zu messen: Tastatur, Fokus, Kontrast, Bewegungsreduktion, verständliche Namen und robuste Semantik.

Sicherheit und technische Disziplin

Sicherheit beginnt in diesem Leitbild nicht bei dramatischen Einzelmaßnahmen, sondern bei Disziplin. Weniger unnötige Abhängigkeiten, weniger bewegliche Teile, weniger fremde Einbindungen und weniger überflüssige Dynamik können die Angriffsfläche reduzieren. Modern oder bequem ist nicht automatisch sicher oder betrieblich sinnvoll.

Für viele Informationsseiten werden deshalb statische Lösungen, wenige externe Abhängigkeiten und nachvollziehbare Architekturen bevorzugt. Sicherheit ist dabei nicht nur ein Header-Set oder eine Checkliste, sondern auch eine Frage bewusster Reduktion und klarer Zuständigkeit.

Gerade auf kleinen und mittleren Seiten ist das wichtiger, als viele glauben. Eine übersichtliche technische Basis ist nicht nur leichter zu pflegen, sondern meist auch schwerer kaputtzumachen.

Jede Abhängigkeit ist Nutzen und Verpflichtung zugleich

Eine Bibliothek, ein Framework, ein CDN oder ein SaaS-Dienst kann viel Arbeit sparen. Gleichzeitig entstehen Updatepflichten, Ausfallmöglichkeiten, API-Änderungen und gegebenenfalls neue Datenschutz- oder Sicherheitsfragen.

Bei einer neuen Abhängigkeit werden deshalb nicht nur ihre Funktionen betrachtet. Ebenso wichtig ist die Gegenfrage: Welche Updatepflichten, Ausfallmöglichkeiten, Datenwege und dauerhaften Wartungsaufgaben entstehen dadurch?

Datensparsamkeit kann auch Architektur sein

Was eine Seite nicht erhebt, muss sie nicht speichern, schützen, auswerten oder später erklären. Für rein informative Seiten ist deshalb eine statische Architektur ohne unnötige Tracker, Konten oder Fremdeinbindungen nicht nur einfach, sondern oft auch datenschutzfreundlicher.

Das ist keine Behauptung, dass jede externe Technik datenschutzwidrig wäre. Es ist die bewusstere Frage, ob eine zusätzliche Datenspur für die tatsächliche Aufgabe überhaupt notwendig ist.

Pflege über Jahre – der eigentliche Test guter Arbeit

Viele Webseiten sehen am Anfang ordentlich aus. Die eigentliche Qualität zeigt sich aber später. Nach Monaten. Nach Jahren. Nach vielen kleinen Änderungen, Ergänzungen, Korrekturen und neuen Seiten. Erst dann merkt man, ob die Grundstruktur trägt oder ob alles mit jeder Änderung schwerer und unübersichtlicher wird.

Code wird deshalb in längeren Zeiträumen betrachtet: Lassen sich Muster später wiederverwenden? Bleibt die Datei nachvollziehbar? Sind Bereiche sauber getrennt? Sind Klassen und Blöcke konsistent genug, dass sie nicht bei jeder Änderung neu erfunden werden müssen? Langfristige Pflegbarkeit ist keine Nebensache, sondern Teil der technischen Qualität.

„Der wahre Test von Code ist nicht der erste Eindruck, sondern die dritte Überarbeitung nach mehreren Jahren.“

Ruhige Pflege verändert lieber nachvollziehbar als spektakulär

Wartbarkeit entsteht auch außerhalb des eigentlichen Codes

Dateinamen, Ordnerlogik, Standards, Änderungsnotizen und klare Zuständigkeiten sind Teil der technischen Qualität. Eine gute Datei kann trotzdem schwer pflegbar werden, wenn niemand mehr weiß, welche Fassung maßgeblich ist oder warum eine bestimmte Ausnahme existiert.

Dokumentation muss nicht aus dicken Handbüchern bestehen. Oft reichen wenige präzise Regeln, wenn sie tatsächlich aktuell und verlässlich sind.

Heutige Werkzeuge – KI und Cloud nur nach praktischer Prüfung

Die Bevorzugung ruhiger, direkt kontrollierbarer Seiten bedeutet keine grundsätzliche Ablehnung neuer Werkzeuge. KI-Modelle und Cloud-Dienste werden als Werkzeuge betrachtet, nicht als Mode und nicht als Ersatz für Urteil. Bewertet wird, was sie im realen Betrieb tatsächlich leisten.

Solche Werkzeuge werden nüchtern geprüft: nicht nach Werbeton oder bloßem Neuheitswert, sondern nach wiederholbarem Nutzen. Entscheidend ist, ob ein Werkzeug auch nach mehreren Einsätzen verlässlich bleibt, ob Grenzen erkennbar sind und ob zusätzlicher Ballast den Nutzen übersteigt.

KI-Modelle gelten deshalb weder als Autorität noch als bloße Spielerei. Sie können beim Ordnen, Vergleichen, Formulieren oder Gegenprüfen helfen, können aber ebenso Scheinpräzision, unnötige Länge oder neue Abhängigkeiten erzeugen. Für Cloud-Dienste gilt dieselbe Nutzenprüfung: Mehrwert, Aufwand, Datenschutz, Portabilität und Abhängigkeit werden gemeinsam betrachtet.

Die technische Haltung bleibt damit dieselbe wie bei älteren Werkzeugen: Ein Werkzeug muss sich im realen Gebrauch bewähren. Werbeversprechen oder Neuheitswert ersetzen keine belastbare Funktion.

„Neue Werkzeuge verdienen ihren Platz, wenn sie im Alltag dauerhaft tragen – nicht wenn sie nur modern klingen.“

KI kann Arbeit beschleunigen – Verantwortung bleibt beim Menschen

KI kann beim Vergleichen, Formulieren, Strukturieren, Übersetzen, Prüfen oder beim Erarbeiten technischer Varianten nützlich sein. Ihre Ausgabe wird dadurch aber nicht automatisch richtig.

Besonders bei Code, Recht, Sicherheit und technischen Details gilt: Ergebnis gegen Quelle, Bestand und reale Umgebung prüfen. Eine plausible Formulierung ist kein Beweis.

KI ist in diesem Leitbild am stärksten als Gegenleser, Werkzeug und Beschleuniger – nicht als unsichtbarer Ersatz für Urteil, Verantwortlichkeit oder reale Kenntnis des Systems.

Cloud-Nutzen wird gegen Abhängigkeit und Portabilität abgewogen

Ein Cloud-Dienst kann Verfügbarkeit, Zusammenarbeit oder Komfort verbessern. Gleichzeitig hängt ein Teil der Arbeit dann von Anbieter, Konto, Preis, API und Exportmöglichkeiten ab.

Deshalb gehört zur Bewertung die Ausstiegsfrage: Lassen sich Daten vollständig exportieren? Bleiben offene Formate? Gibt es einen lokalen oder alternativen Workflow? Wie schwer wäre ein späterer Wechsel?

Automatisieren, was wiederholbar ist – sichtbar lassen, was schiefgehen kann

Automatisierung ist dann gut, wenn sie reproduzierbare Arbeit zuverlässig übernimmt und Fehlerzustände sichtbar macht. Sie ist schlecht, wenn niemand mehr versteht, was sie verändert.

Gerade bei Build-, Upload-, Backup- oder Übersetzungsabläufen sollten Eingaben, Ausgaben und Rückweg dokumentiert bleiben.

Was dieses Leitbild eher vermeidet

Nicht Technik an sich wird vermieden, sondern Technik, deren eigener Aufwand keinen entsprechenden Nutzen erzeugt. Dazu gehören aufgeblähte Strukturen, unnötige Framework-Last, Effekte ohne funktionalen Gewinn, überladene Oberflächen, austauschbare Standardlösungen ohne klare Anpassung und Konstruktionen, die sich später nur schwer wieder lesen lassen.

• unnötig schwere Frontend-Konstruktionen für einfache Seiten
• JavaScript als Standardreaktion statt als bewusstes Werkzeug
• optische Unruhe, die Lesbarkeit und Orientierung schwächt
• SEO-Tricks ohne inhaltliche Substanz
• Strukturen, die beim späteren Pflegen mehr Schaden als Nutzen bringen
• Technik, die beeindruckend aussehen soll, aber im Alltag unnötig bremst

Das bedeutet keine grundsätzliche Ablehnung moderner Werkzeuge. Technik soll ihren Platz durch einen nachvollziehbaren Nutzen verdienen. Ein Werkzeug ist dann gut begründet, wenn es ein Problem zuverlässig löst, ohne unnötig Namen, Ballast und Wartungsaufwand hinzuzufügen.

Die Philosophie ist eine Prüffrage, kein Dogma

Ein Framework wird nicht abgelehnt, nur weil es ein Framework ist. Eine Cloud wird nicht abgelehnt, nur weil sie eine Cloud ist. JavaScript wird nicht abgelehnt, nur weil es JavaScript ist.

Die eigentliche Frage ist immer dieselbe: Wird die Lösung dadurch nachvollziehbar besser – oder nur größer, abhängiger und schwerer zu pflegen?

Der langfristige Maßstab

„Technik verdient ihren Platz nicht durch Neuheit, sondern dadurch, dass sie ihre Aufgabe dauerhaft trägt.“

Technischer Stand 2026: Leitbild gegen aktuelle Webstandards geprüft

Die Grundsätze dieser Seite stehen 2026 nicht im Widerspruch zu den maßgeblichen Webstandards. Der HTML-Standard wird weiterhin als Living Standard fortgeschrieben und beschreibt Semantik, Struktur, Interaktion und APIs als zusammenhängende Webplattform. Direkte, semantisch sinnvolle HTML-Strukturen bleiben deshalb keine nostalgische Sonderlösung, sondern Teil der aktuellen Plattform.

WCAG 2.2 bleibt ein aktueller W3C-Prüfrahmen für Webzugänglichkeit. Für das SSLXY-Leitbild besonders relevant sind Tastaturbedienung, sichtbarer und nicht verdeckter Fokus, Mindestzielgrößen, Bewegungsreduktion, verständliche Bezeichnungen und robuste semantische Grundlagen. Automatische Prüfungen helfen, ersetzen aber weiterhin keine reale Bedienprüfung.

Auch die SEO-Grundlinie bleibt aktuell: Google beschreibt SEO als Hilfe für Suchsysteme, Inhalte zu verstehen und Nutzern passende Inhalte zugänglich zu machen. Gleichzeitig wird weiterhin helpful, reliable, people-first content gegenüber suchmaschinenzentrierter Inhaltserzeugung hervorgehoben. Technische Optimierung und menschenorientierte Inhalte sind damit keine Gegensätze.

Bei KI-, Cloud- und Automatisierungswerkzeugen bleibt bewusst keine einzelne Produktgeneration zum Maßstab erhoben. Bewertet werden stattdessen dauerhafte Eigenschaften: nachvollziehbarer Nutzen, Fehlermöglichkeiten, Datenwege, Portabilität, Rückweg, Wartungsaufwand und die Möglichkeit, Ergebnisse unabhängig zu prüfen. Diese Kriterien bleiben auch dann brauchbar, wenn konkrete Produkte oder Anbieter wechseln.

Querverweise im SSLXY-Archiv

philosophy.htm beschreibt das übergreifende technische Leitbild. Die folgenden Seiten dokumentieren die historischen, praktischen und sicherheitstechnischen Bereiche, in denen diese Grundsätze konkret sichtbar werden.

• Startseite von sslxy.de
• Webmaster- und Webentwicklungskontext
• Webentwicklung seit 1996
• Systemchronik
• Hardware-Archiv
• Server-Härtung
• Software- und Tool-Alltag
• KI-Werkzeuge
• Repair Attitude
• Datensicherung und Backups
• The Vault