Das CSS-Zen-Garden-Projekt

 (csszengarden.com)
2 Punkte von GN⁺ 2025-04-28 | 1 Kommentare | Auf WhatsApp teilen
  • CSS Zen Garden ist ein Demo-Projekt, das zeigt, dass selbst dasselbe HTML-Dokument allein durch CSS-basiertes Design völlig unterschiedliche visuelle Erlebnisse bieten kann
  • Wenn man in der Designliste ein Stylesheet auswählt, bleibt das HTML unverändert, und nur das externe CSS wird ausgetauscht, wodurch sich das Rendering der Seite verändert
  • Teilnehmende laden Beispiel-HTML/CSS herunter und arbeiten lokal daran, dürfen bei der Einreichung jedoch nur das Stylesheet ändern
  • Die fertige CSS-Datei und zugehörige Assets werden auf den eigenen Webserver hochgeladen und per Link eingereicht; ausgewählte Arbeiten werden auf dem CSS-Zen-Garden-Server bereitgestellt
  • Vorrang hat praktisches CSS statt experimenteller Funktionen; verlangt werden validierbares CSS sowie funktionierendes Verhalten in IE9+ und aktuellen Browsern wie Chrome, Firefox, iOS und Android

Das CSS-Experiment, das dasselbe HTML völlig anders aussehen lässt

  • CSS Zen Garden ist eine Demo, die die Ausdruckskraft von CSS zeigt
  • Nutzer können in der Designliste den gewünschten Eintrag auswählen und das entsprechende Stylesheet auf die aktuelle Seite anwenden
  • Die zentrale Einschränkung besteht darin, das HTML nicht zu verändern und nur die externe CSS-Datei auszutauschen
    • Die gleiche Dokumentstruktur bleibt erhalten, während sich nur das visuelle Ergebnis ändert
    • Es zeigt, wie weit Design und Coding die visuellen Möglichkeiten des Webs ausdehnen können
  • Es lässt sich als Lernprojekt verstehen, das zur Teilnahme und Inspiration anregt und Ergebnisse teilt, die sich tatsächlich mit CSS umsetzen lassen

Teilnahme und Einreichungsablauf

  • Teilnehmende gestalten diese Seite auf Basis eines starken visuellen Designs und CSS-Könnens neu
    • Die Beispieldateien enthalten Kommentare, sodass auch CSS-Einsteiger sie als Ausgangspunkt nutzen können
    • Fortgeschrittene Tutorials und Tipps werden im CSS Resource Guide bereitgestellt
  • Die Arbeit kann mit einer lokal kopierten Version der Beispiel-HTML und des Beispiel-CSS erfolgen
  • Für die Einreichung müssen die fertige CSS-Datei und zugehörige Assets auf einen selbst kontrollierten Webserver hochgeladen und dann über den Einreichungslink übermittelt werden
    • Von der Einreichung unfertiger Arbeiten wird abgeraten
    • Ausgewählte Einreichungen werden von CSS Zen Garden heruntergeladen und auf dem Server bereitgestellt
  • Die Belohnung für die Teilnahme liegt in Anerkennung, Inspiration und dem Beitrag zu gemeinsam genutztem Material, das die Möglichkeiten von CSS zeigt

CSS-Anforderungen und Lizenz

  • Die Anforderungen richten sich eher auf funktionales und praktisches CSS als auf die neuesten experimentellen Funktionen
    • Wo möglich, wird die Verwendung von CSS 1 & 2 bevorzugt
    • CSS 3 & 4 sollten auf breit unterstützte Elemente beschränkt bleiben oder eine starke Fallback-Lösung bieten
    • Das CSS muss die Validierung bestehen
    • Wenn man aktuelle User Agents und mobile Umgebungen berücksichtigt, kann ein auf allen Plattformen pixelgenau identisches Layout schwierig sein
    • Das Design muss mindestens in IE9+, aktuellem Chrome, Firefox sowie in Browsern auf iOS und Android funktionieren
  • Einreichungen müssen originäre Artworks sein und das Urheberrecht respektieren
    • Material, das Anstoß erregen könnte, sollte auf ein Minimum reduziert werden
    • Gartenbezogene Designs gibt es bereits mehr als genug, daher werden einzigartige und interessante visuelle Themen empfohlen
  • Die Urheberrechte an Grafiken verbleiben bei den Einreichenden, aber das CSS muss unter derselben Creative Commons BY-NC-SA 3.0 veröffentlicht werden wie die Website, damit andere es zum Lernen nutzen können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-04-28
Hacker-News-Kommentare

  • Wenn man nicht gerade zu der Zeit Webentwicklung gemacht hat, als das hier entstand, fehlt einem leicht der Kontext.
    Vor CSS wurden für Layouts table-Elemente gitterartig missbraucht, und Bilder wurden zerschnitten und in die einzelnen Zellen gelegt. Daran erinnert man sich heute noch halbwegs, aber der Widerstand gegen CSS von damals scheint weitgehend vergessen zu sein.
    Viele Webentwickler waren mit dem Status quo zufrieden und wollten CSS nicht lernen, und der Mythos, dass man mit „CSS nur langweilige, eckige Designs“ bauen könne, hielt sich hartnäckig. Dave Shea hat mit CSS Zen Garden eindrucksvolle Designs gesammelt und gezeigt und dieses Argument damit praktisch erledigt; es ist fast schon komisch, dass heute selbst die Erinnerung an diese Debatte verblasst ist

    • Frühes CSS war viel dürftiger als heute. border-radius kam erst etwa 2011 dazu, und selbst eine vergleichsweise einfache Seite wie https://90s.dev/ braucht mit modernem CSS laut https://90s.dev/style.css rund 420 Zeilen.
      Und das, obwohl dort großzügig Verschachtelung und das spielverändernde :has verwendet werden. Ich erinnere mich, dass man wegen der grundlegenden Grenzen von CSS damals sowohl CSS als auch die HTML-Struktur ändern musste, um Formen umzusetzen, die sich nicht intuitiv bauen ließen
    • Der Grund, warum man anfangs table verwendete, war, dass es ein Albtraum war, CSS in mehreren Browsern sauber auszurichten. Ein teurer Albtraum, und wirklich tragbar war das nur für gut finanzierte Startups, die es sich leisten konnten, HTML ständig umzubauen
    • Der genaue Zeitpunkt ist unscharf, aber es gab eine Phase, in der das gerade aufkommende CSS für komplexere Layouts noch nicht ausreichte. Von flexbox ganz zu schweigen, und grid erst recht.
      CSS Zen Garden war aus meiner Sicht genau dazu da, zu zeigen, wie weit man mit CSS zu diesem Zeitpunkt kommen konnte
    • Ich habe nie wirklich verstanden, was daran so falsch gewesen sein soll, mit table-Elementen ein Raster zu bauen. Abgesehen von der Rede über „semantisches HTML“, die nur für manche Anwendungen relevant ist, erschließt sich mir da nicht viel
    • An Widerstand gegen CSS erinnere ich mich nicht, aber ich erinnere mich gut daran, dass viele Seiten CSS ein wenig für Schriftgestaltung nutzten, für das Layout aber weiter table. Das war kein Widerstand, sondern Pragmatismus.
      Wenn man ein stabiles, vorhersehbares Raster brauchte, nahm man table-Layouts, besonders bei dichten und komplexen Layouts. Es war auch üblich, nur die Navigation als table-Layout zu bauen, denn das Ziel war damals pixelgenau.
      Erinnerst du dich an die spacer-Elemente um das Jahr 2000? Die haben sich am Ende nicht durchgesetzt; Pixel-GIFs waren verbreiteter und berechenbarer.
      Bis flexbox 2014 im Mainstream ankam, fühlten sich CSS-Float-Layouts wie Tellerjonglage an. Leere divs und divs mit Inhalt verhielten sich unterschiedlich, was furchtbar war; diese Zeit bekomme ich nicht zurück, aber immerhin wurde ich dafür bezahlt.
      Die Vorstellung, frühes CSS hätte einem mühelos schicke „Zen Garden“-Layouts gegeben, passt nicht zu meiner Erfahrung. Allerdings habe ich keine verspielten Kunstseiten gebaut, sondern Informations- und Medienseiten

  • Diese Seite ist alt, und das im guten Sinne.
    In den 2000ern war sie für mich ein Kulturschock und hat mich dazu gebracht, weg von Microsoft ASP.NET zu kommen und Apps unter Linux zu bauen. Mir wurde klar, dass „server controls“ mit Inline-Style-Parametern eine völlig falsche, gewissermaßen „anti-internethafte“ Herangehensweise waren.
    Alex Russell, der Dojo JS geschaffen hat, hat diese Sichtweise auf einer Konferenz vermittelt, und ich war schockiert, wie viel ich verpasst hatte, während ich Technachrichten nur über Microsoft-Kanäle konsumierte.
    Einige Jahre lang bestanden meine Werkzeuge im Wesentlichen aus Web.py, HTML, JS und CSS; später kamen jQuery, Backbone und Underscore, und inzwischen fühlt es sich so an, als hätten React und TypeScript den neuen „Full Stack“ wieder stumpf gemacht

    • Ich weiß nicht, was genau einen daran gehindert haben soll, solche Apps in ASP.NET zu bauen. ASP.NET hat das nicht verhindert; man konnte ja durchaus Stylesheets anlegen und JS-Dateien auslagern.
      Ironischerweise ist das Alte wieder neu geworden. Im Next.js-Umfeld baut man View State im Grunde wieder nach, Tailwind bringt Inline-Styling zurück, und mit shadcn plus React-Komponenten hat sich der Kreis fast geschlossen
    • Jetzt gibt es Svelte, und das könnte man als einen etwas „cleveren“ Full Stack sehen
    • Das existiert übrigens immer noch im Netz. Es ist eher ein altes Fossil, aber man kann es unter https://www.ajaxtoolkit.net/ sehen. Enterprise-Software ohne Drag Panel gab es damals praktisch nicht.
      Eine Zeit lang waren semantisches Markup und CSS vorn, aber heute interessiert mich das aktuelle Trendgeschehen nicht einmal mehr genug, um nachzusehen. Bei „HTML in JavaScript“ (JSX) habe ich innerlich aufgehört
    • Ich habe mit ASP und PHP angefangen, und ASP.NET war stark darauf ausgelegt, Visual-Studio-Entwicklern beim Bau eher fragwürdiger Web-Apps zu helfen; zum Web im weiteren Sinn passte es nicht.
      Auf Linux umzusteigen war übrigens nicht einmal nötig. Unsere IT ließ keine Linux-Desktops zu, also habe ich alles unter Windows gebaut und sowohl auf Windows- als auch auf Linux-Servern ausgerollt

  • Für mich war der Kern von CSS Zen Garden, dass man durch maximale Nutzung von semantischem HTML Darstellung und Inhalt trennen und völlig unabhängig voneinander behandeln kann.
    Bis zu einem gewissen Grad wie im Zen Garden geht das auch heute noch, aber in Wahrheit bewegt man sich dabei innerhalb der Grenzen von CSS. Es ist eher ein „CSS kann das, also entwerfen wir so“ als ein „Wir wollen dieses Design, also schreiben wir dieses CSS“.
    Viele Stilentscheidungen sind nur möglich, wenn man den DOM direkt verändert, und manches geht mit reinem CSS überhaupt nicht. Selbst in W3C-Diskussionen habe ich schon Dinge gelesen wie: „Warum braucht ihr eine neue CSS-Eigenschaft? Wickelt es doch einfach noch in ein weiteres div.“
    Bilder einzufügen oder zu ersetzen ist einfach, aber ein stilisierbares SVG zu ersetzen ist nicht möglich, weil man dafür die SVG-Knoten direkt in das HTML einfügen muss. Am Ende vermischt man also auf HTML- und JavaScript-Ebene die Entscheidung über Darstellung und Inhaltsstruktur, und selbst einfache Designänderungen greifen dann in den gesamten Stack ein

    • Das Versprechen der CSS-Community war immer, dass sich Struktur und Darstellung trennen lassen.
      Nachdem ich 30 Jahre lang GUIs geschrieben habe, bin ich inzwischen überzeugt, dass die Trennlinie an der falschen Stelle gezogen wurde. Stattdessen muss man die Absicht isolieren. In meinem Projekt übernehmen Composites genau diese Rolle, und ich freue mich sehr darauf, es nächste Woche zu veröffentlichen
    • Hier kommt XSLT ins Spiel
    • Andererseits ist CSS heute sehr leistungsfähig, und viele Designs, die die Eigenschaften des Mediums berücksichtigen statt Luftschlösser zu bauen, lassen sich mit CSS und HTML allein sauber umsetzen

  • Aus der Perspektive von jemandem, der CSS mit Materialien wie Zen Garden und Eric Meyer gelernt hat, wirken moderne CSS-Werkzeuge wie Tailwind wie ein Antipattern

    • Stimme ich völlig zu. Tailwind hat wirklich viele Probleme.
      HTML wird komplett von Stilinformationen überdeckt. HTML zu lesen sollte bedeuten, Inhalt und Semantik zu sehen, nicht pl-16 pr-8 bg-olive-500 text-gray-700 zu entziffern und daraus zu schließen: „Das ist wohl ein Karten-Header.“
      Man kann sagen, dass Leute heute kein HTML mehr lesen, aber wenn Entwickler, die solche Frameworks benutzen, aus dem HTML ein schreckliches Durcheinander machen, wer soll es dann noch lesen? Wenn es zu viele Framework-Klassen werden, enthält HTML mehr Rauschen als Inhalt, dadurch verschwindet das Lesen von HTML, und dann schichten Entwickler wiederum noch mehr Klassen und Styles darauf — ein selbstverstärkender Zyklus
      Webentwickler duplizieren außerdem massiv Styles. Statt etwas wie .button zu verwenden, liegen Kombinationen wie text-white rounded bg-gray-aaa an Hunderten von Stellen verstreut herum. Ob das ein Tailwind-Problem oder ein Entwicklerproblem ist, weiß ich nicht, aber in großen Projekten wird es zum Whac-A-Mole, wenn man den Stil ähnlicher UI-Elemente im ganzen Projekt ändern will und erst herausfinden muss, an welchem Element welcher Inline-Style sitzt
    • Solche CSS-Werkzeuge scheinen für Leute attraktiv zu sein, die Webentwicklung improvisiert gelernt haben. Am Anfang wollte man einfach das Design im Kopf umsetzen und fing bei „Header, Text, Bild“ an und lernte dann entlang von Fragen wie „Wie zentriere ich das?“, „Wie ändere ich die Farbe?“, „Wie ist der Abstand zwischen Elementen?“
      So hat man zwar schnell einen Werkzeugkasten voller CSS-Ideen, verpasst aber die Details, die CSS wirklich gut funktionieren lassen. Ich wusste, wie man seltsame Probleme mit position: absolute und transform umgeht, aber ich kannte weder den Block-Formatting-Context noch die Feinheiten des Box-Modells
      Wenn das CSS-Wissen nur aus Pflastern besteht, die auf fragiles CSS-Wissen geklebt wurden, verbrennt man letztlich nur Energie. Dann kann ein kombinierbarer Stil-Werkzeugkasten attraktiv wirken, der einen vor vielen CSS-Fallstricken bewahrt
      Was meine Sicht verändert hat, war eine kurze Online-Buchreihe, die HTML/CSS von Grund auf erklärt hat. Sie hat alles von den ersten Prinzipien aus erklärt und warum die Dinge so sind, statt einem einfach nur „10 Wege, ein div zu zentrieren“ hinzulegen und es dabei zu belassen. Ich habe sie an einem Nachmittag komplett gelesen, und meine Sicht auf Webentwicklung hat sich verändert, aber ich kann mich beim besten Willen nicht an den Namen erinnern. An einen Satz erinnere ich mich besonders: „display: block ist wie ein Word-Dokument, und display: flex kommt dem näher, was Menschen erwarten.“
    • Tailwind-Code ist wirklich hässlich. Ich hasse ihn. Als es aufkam, arbeitete ich gerade an großen Websites, und die Idee, statt ein paar Zeilen in einer CSS-Datei und einem Klassennamen auf Tausenden von Seiten Hunderte Style-Properties anzuhängen, wirkte wie ein gewaltiger Rückschritt, der die Hälfte der Vorteile von CSS wieder zunichtemacht
    • Als Standard in Unternehmen mit Hunderten von Mitarbeitern scheint es gut zu funktionieren. Wenn man auf einer Landingpage alles als Einmalstil setzen will, dann kann man das so machen

  • Es wirkt wie ein kleiner Lichtschein im dunklen Zeitalter von Tailwind und CSS-in-JS
    Heute ist es schwer nachzuempfinden, wie wichtig CSS Zen Garden vor etwa 20 Jahren war

    • CSS-in-JS ist hauptsächlich eine Lösung für die Code-Organisation, wie bei Styled Components oder Emotion. Es verändert nicht grundlegend, wie CSS funktioniert
    • Es hat mich definitiv dazu gebracht, CSS zu lieben. Das heißt aber nicht, dass ich nicht nachvollziehen kann, warum Tailwind in großen Projekten attraktiv ist
    • Als ich CSS zum ersten Mal lernte, habe ich ihr Buch gekauft. Das war wirklich eine andere Zeit

  • Früher hatte diese Seite einen enormen Einfluss auf mich
    Zur Erklärung für alle, die sie nicht kennen: Man konnte für denselben HTML-Inhalt ein Design nur mit CSS und Bildern einreichen. Besonders beeindruckend waren zum Beispiel diese Beispiele
    https://csszengarden.com/202/
    https://csszengarden.com/189/
    https://csszengarden.com/177/
    https://csszengarden.com/136/
    https://csszengarden.com/206/
    Es gab auch ein Design, bei dem beim Scrollen ein mit position: fixed gesetztes Schwert die „Seite in der Mitte zerschnitt“, aber das scheint jetzt nicht mehr in der Liste zu sein. An ein anderes erinnere ich mich so, dass der obere Rand der Seite die Meeresoberfläche war und man beim Herunterscrollen am Ende unter Wasser auf einen Oktopus, ein U-Boot oder einen Taucher stieß

    • Geht mir genauso. Wenn ich diese Designs sehe, denke ich daran, wie langweilig Webdesign heute geworden ist

  • Ich habe dort zwei Designs hochgeladen und bekomme bis heute E-Mails, in denen um Erlaubnis gebeten wird, mein CSS wiederzuverwenden

  • Ich freue mich wirklich, heute auf HN CSS Zen Garden zu sehen. Das waren gute Zeiten.
    Aber jetzt muss ich doch etwas meckern.
    Was mich an Tailwind und ähnlichen CSS-„Frameworks“ sowie an der modernen Softwareentwicklung insgesamt am meisten beunruhigt, ist, dass es zunehmend als etwas Positives gilt, die zugrunde liegenden Systeme nicht zu verstehen.
    Tailwind liefert eine schnelle, oberflächliche Lösung. Man hängt Utility-Klassen an die Seite, und bekommt ein „gut genug aussehendes“ Ergebnis, ohne lernen zu müssen, wie CSS tatsächlich funktioniert. Dass das HTML zu einem Chaos wird, in dem mehr CSS-Klassen als Inhalt stehen, stört dabei niemanden.
    Die Haltung ist: „Wen interessiert schon, wie es funktioniert? Die Seite sieht gut aus. Also Erfolg!“
    Das ist nicht nur ein Tailwind-Problem, sondern Teil einer größeren Entwicklung in der Branche. Unwissen wird gefeiert, und man jagt Ergebnissen hinterher, ohne echtes Verständnis aufzubauen.
    Seit wann ist es etwas, worauf man stolz ist, etwas nicht zu wissen? Es ist traurig, wenn Tiefe und Können als optional oder sogar als unerwünscht behandelt werden.

    • Wenn man sieht, wie schlecht das meiste HTML ist, ist das schockierend. Ich habe gerade auf Twitter nachgesehen: Ein einzelner Beitrag in meiner Timeline bestand nur aus einem Textabsatz, einem Bild und etwa 10 verlinkten Icons, aber allein das HTML hatte 254 Zeilen, 21,8 kB, 104 verschachtelte divs und mehr als 860 Klassen.
      Es gibt mehr Klassen als Zeichen im Textinhalt, und allein die Klassennamen machen ungefähr 9 kB aus. Das wiederholt sich bei jedem einzelnen Beitrag in der Timeline.
      Ein paar divs, ein paar Klassen, je eine Klasse pro Icon und ein paar Zeilen CSS sollten völlig ausreichen. Ehrlich gesagt könnte man alle Beiträge der Timeline mit weniger Zeichen stylen, als die Klassennamen eines einzigen Beitrags lang sind.
      Ich kann nicht nachvollziehen, wie professionelle Entwickler so absurd aufgeblähtes HTML erzeugen können.
    • Softwareentwicklung bedeutet, im Lauf der Zeit immer mehr Abstraktionsebenen aufzubauen. Wie gut kannst du Assembler?
    • Ich verstehe, was du meinst, aber ich finde nicht, dass das auf Tailwind zutrifft. Tailwind-Klassen entsprechen direkt CSS-Eigenschaften, daher kann man damit tatsächlich nicht viel anfangen, wenn man CSS nicht versteht.

  • Das fühlt sich an wie eine Botschaft aus der Vergangenheit. Ich mochte CSS Zen Garden, aber sein Ziel und seine Philosophie passten zu einer Welt, in der der Hauptzweck von Websites die Bereitstellung von Dokumenten war.
    Die Welt der Rich Media hat diese Vorstellung vom Web wohl Mitte der 2000er hinter sich gelassen.

    • Ich würde eher sagen, nicht Rich Media, sondern dass das Web zu 100 % marketinggetrieben geworden ist. Unten geht es einfach immer weiter mit Werbung.
    • Das ist ein schwerwiegendes Downgrade.
      https://blog.danieljanus.pl/2019/10/07/web-of-documents/
    • Du sagst „eine Welt, in der der Hauptzweck von Websites die Bereitstellung von Dokumenten war“, aber in dieser Welt leben wir immer noch. Das ist nicht sarkastisch gemeint.
      Abgesehen von ein paar Kartenanwendungen besteht das meiste im Web immer noch darin, etwas zu lesen, und dafür braucht man nicht all diesen Ballast. Es wird nur komplizierter, weil Entwickler Komplexität der Einfachheit vorziehen.
    • Ist „moderne Medienwelt“ wirklich reichhaltig? Ich finde eher, dass Informationsdichte und Signal-Rausch-Verhältnis schlechter geworden sind.

  • Schön, dass Garden zurück ist. In der Zeit, als CSS-basiertes Webdesign State of the Art war und die Leute begannen, statt tief verschachtelter Tabellen tief verschachtelte divs zu verwenden, waren CSS Zen Garden und Spoono meine Lieblingswebsites.
    Das Buch war auch gut.