Le projet CSS Zen Garden

 (csszengarden.com)
2 points par GN⁺ 2025-04-28 | 1 commentaires | Partager sur WhatsApp
  • CSS Zen Garden est un projet de démonstration montrant qu’un même document HTML peut offrir une expérience visuelle totalement différente uniquement grâce à un design basé sur CSS
  • En sélectionnant une feuille de style dans la liste des designs, le HTML reste inchangé et seul le CSS externe change, ce qui modifie le rendu de la page
  • Les participants peuvent télécharger l’exemple HTML/CSS et travailler en local, mais au moment de la soumission, seule la feuille de style peut être modifiée
  • Le fichier CSS finalisé et les ressources associées doivent être mis en ligne sur le serveur web du participant puis soumis via un lien, et les créations retenues sont déployées sur le serveur de CSS Zen Garden
  • Les CSS pratiques priment sur les fonctionnalités expérimentales, avec obligation d’un CSS valide et d’un fonctionnement sur IE9+ ainsi que sur les dernières versions de Chrome, Firefox et les navigateurs iOS et Android

Une expérience CSS pour donner un aspect totalement différent au même HTML

  • CSS Zen Garden est une démonstration destinée à mettre en valeur la puissance expressive de CSS
  • L’utilisateur peut choisir une entrée dans la liste des designs pour appliquer la feuille de style correspondante à la page actuelle
  • La contrainte essentielle consiste à remplacer uniquement le fichier CSS externe sans modifier le HTML
    • La structure du document reste identique, seul le résultat visuel change
    • Cela montre jusqu’où le design et le code peuvent étendre les possibilités visuelles du web
  • On peut y voir un projet pédagogique qui encourage la participation et l’inspiration, et qui partage des réalisations concrètement possibles avec CSS

Modalités de participation et processus de soumission

  • Les participants repensent cette page en s’appuyant sur de solides compétences en design visuel et en CSS
    • Les fichiers d’exemple comportent des commentaires, afin que même les débutants en CSS puissent s’en servir comme point de départ
    • Des tutoriels avancés et des conseils sont proposés dans le CSS Resource Guide
  • Le travail peut être réalisé sur une copie locale après téléchargement des exemples HTML et CSS
  • Pour soumettre un projet, il faut mettre en ligne le fichier CSS finalisé et les ressources associées sur un serveur web sous son contrôle, puis l’envoyer via le lien de soumission
    • Il n’est pas recommandé de soumettre un travail inachevé
    • Les soumissions retenues sont téléchargées par l’équipe de CSS Zen Garden puis déployées sur son serveur
  • La récompense consiste en la reconnaissance, l’inspiration, et la contribution à une ressource partagée qui démontre les possibilités de CSS

Exigences CSS et licence

  • Les exigences privilégient un CSS fonctionnel et pratique plutôt que des fonctionnalités expérimentales récentes
    • L’usage de CSS 1 & 2 est préféré lorsque c’est possible
    • CSS 3 & 4 doivent être limités aux éléments largement pris en charge, ou accompagnés de solutions de repli solides
    • Le CSS doit passer la validation
    • En tenant compte des user agents récents et des environnements mobiles, obtenir une mise en page identique au pixel près sur toutes les plateformes peut être difficile
    • Le design doit fonctionner au minimum sur IE9+, les dernières versions de Chrome et Firefox, ainsi que sur les navigateurs iOS et Android
  • Les soumissions doivent être des créations originales et respecter le droit d’auteur
    • Les contenus susceptibles de choquer doivent être réduits au minimum
    • Les designs autour du thème du jardin étant déjà nombreux, des thèmes visuels originaux et intéressants sont encouragés
  • Les droits sur les éléments graphiques restent au soumissionnaire, mais le CSS doit être publié sous la même licence Creative Commons BY-NC-SA 3.0 que le site afin que d’autres puissent l’utiliser pour apprendre

À lire aussi

1 commentaires

 
GN⁺ 2025-04-28
Avis sur Hacker News

  • Il y a un contexte qu’on ne perçoit pas vraiment si l’on n’a pas fait de développement web à l’époque où cela a été créé.
    Avant CSS, on abusait des éléments table comme d’une grille pour faire des mises en page, et on découpait les images en morceaux pour les placer dans chaque cellule. Aujourd’hui, on s’en souvient à peu près, mais la résistance à CSS de l’époque semble avoir été largement oubliée.
    Beaucoup de développeurs web étaient satisfaits du statu quo et ne voulaient pas apprendre CSS, et le mythe selon lequel « avec CSS, on ne peut faire que des designs ennuyeux et rectangulaires » a longtemps persisté. En rassemblant et en montrant de superbes designs avec CSS Zen Garden, Dave Shea a pratiquement mis fin à cet argument ; c’est amusant de voir que la victoire a été si totale qu’on a même oublié qu’un tel débat avait existé.

    • Les débuts de CSS étaient bien plus limités qu’aujourd’hui. border-radius n’est arrivé que vers 2011, et même un site relativement simple comme https://90s.dev/ nécessite environ 420 lignes de CSS moderne, si l’on se base sur https://90s.dev/style.css.
      Et cela malgré un usage généreux de l’imbrication et du très transformateur :has. Je me souviens qu’à cause des limites fondamentales de CSS à l’époque, il fallait modifier à la fois la structure CSS et HTML pour implémenter des formes qu’on ne pouvait pas créer de manière intuitive.
    • Si l’on utilisait des éléments table au début, c’est parce qu’obtenir un rendu correct avec CSS dans plusieurs navigateurs était un cauchemar. Un cauchemar coûteux, qui n’était supportable que pour des startups bien financées ayant les moyens de refondre souvent leur HTML.
    • Le moment exact est flou, mais il y a eu une période où CSS, qui venait d’apparaître, ne suffisait pas pour créer des mises en page plus complexes. Il n’y avait pas de flexbox, et encore moins de grid.
      À mon avis, CSS Zen Garden existait précisément pour montrer jusqu’où on pouvait aller avec CSS à ce moment-là.
    • Je n’ai jamais vraiment compris ce qu’il y avait de si incorrect, en pratique, à utiliser des éléments table pour faire une grille. À part les histoires de « HTML sémantique », qui n’ont de sens que pour certaines applications, je ne vois pas vraiment.
    • Je ne me souviens pas d’une résistance à CSS, mais je me souviens qu’il était courant de voir des sites utiliser un peu de CSS pour styliser les polices tout en gardant des tables pour la mise en page. Ce n’était pas de la résistance, c’était du pragmatisme.
      Quand on avait besoin d’une grille stable et prévisible, on utilisait des mises en page en tables, surtout pour les mises en page denses et complexes. Il était aussi courant que seule la navigation soit en table, et l’objectif de l’époque était le pixel perfect.
      Vous vous souvenez de l’élément spacer vers 2000 ? Il n’a finalement jamais vraiment pris, et les GIF d’un pixel étaient plus courants et plus prévisibles.
      Jusqu’à la popularisation de flexbox en 2014, les mises en page CSS à base de float ressemblaient à un numéro d’équilibriste. Les div vides et les div contenant du contenu se comportaient différemment, ce qui était pénible ; je ne récupérerai jamais ce temps, mais au moins j’ai été payé.
      L’idée que le CSS des débuts permettait facilement de belles mises en page façon « Zen Garden » ne correspond pas à mon expérience. Cela dit, je construisais des sites de médias d’information, pas des sites artistiques amusants.

  • Ce site est ancien, et je le dis dans le bon sens du terme.
    Dans les années 2000, cela a été pour moi un choc culturel, et m’a amené à quitter Microsoft ASP.NET pour créer des applications sous Linux. J’ai compris que les « server controls » avec des paramètres de style inline étaient une approche complètement erronée, pour ainsi dire « anti-Internet ».
    Alex Russell, le créateur de Dojo JS, avait présenté cette perspective lors d’une conférence, et j’ai été stupéfait de réaliser tout ce que j’avais manqué en suivant l’actualité technique via les canaux Microsoft.
    Pendant quelques années, mes outils se résumaient à Web.py, HTML, JS et CSS ; puis jQuery, Backbone et Underscore sont arrivés, avant que React et TypeScript ne rendent à nouveau le « full-stack » lourd et peu réactif, à mon sens.

    • Je ne vois pas très bien ce qui empêchait de construire ce genre d’application avec ASP.NET. ASP.NET ne l’interdisait pas, et il était possible de créer des feuilles de style et de séparer les fichiers JS.
      Ironiquement, l’ancien est redevenu nouveau. Côté Next.js, on est en train de recréer le view state ; Tailwind remet le styling inline au goût du jour ; et shadcn utilise des composants React, si bien qu’on a presque bouclé la boucle.
    • Maintenant, il y a Svelte, qu’on peut voir comme une forme de full-stack un peu « intelligente ».
    • C’est encore en ligne. C’est presque une relique, mais on peut le voir sur https://www.ajaxtoolkit.net/. Il n’y avait pas de logiciel d’entreprise sans drag panel.
      Pendant un temps, le balisage sémantique et CSS ont pris l’avantage, mais je n’ai même plus l’intérêt de suivre les tendances actuelles. J’ai décroché à peu près au moment du « HTML dans JavaScript » (JSX).
    • J’ai commencé avec ASP et PHP, et ASP.NET servait surtout à aider les développeurs Visual Studio à fabriquer des applications web médiocres ; ce n’était pas adapté au Web au sens large.
      Il n’y avait même pas besoin de passer à Linux. Le service informatique n’autorisait pas les postes Linux, donc je faisais tout sous Windows, puis je déployais à la fois sur des serveurs Windows et Linux.

  • J’ai le sentiment que le cœur de CSS Zen Garden était de montrer qu’en exploitant au maximum le HTML sémantique, on pouvait séparer présentation et contenu, et les traiter de façon totalement indépendante.
    Aujourd’hui encore, on peut aller à peu près aussi loin que Zen Garden, mais en réalité on évolue dans les limites de CSS. C’est davantage « CSS peut faire ceci, donc on crée ce design » que « je veux ce design, donc j’utilise ce CSS ».
    Beaucoup de choix de style ne sont possibles qu’en modifiant directement le DOM, et certaines choses ne sont pas faisables en CSS pur. Même dans des discussions du W3C, j’ai déjà vu des raisonnements du genre « pourquoi faudrait-il une nouvelle propriété CSS alors qu’il suffit d’envelopper avec une div de plus ? ».
    Insérer ou remplacer des images est simple, mais remplacer un SVG stylisable est impossible sans insérer directement les nœuds SVG dans le HTML. Au final, les décisions de présentation et de structure du contenu se retrouvent mélangées au niveau HTML et JavaScript, et même un simple changement de design oblige à toucher toute la stack.

    • La promesse de la communauté CSS a toujours été qu’on pouvait séparer structure et présentation.
      Après 30 ans à écrire des interfaces graphiques, je suis désormais convaincu que l’endroit où l’on trace cette frontière est mauvais. Il faut plutôt isoler l’intention. Les Composites de mon projet jouent ce rôle, et je suis très impatient de les publier la semaine prochaine.
    • C’est là que XSLT entre en scène.
    • À l’inverse, le CSS moderne est très puissant : pour beaucoup de designs qui ne sont pas des châteaux en l’air mais tiennent compte des caractéristiques du média, CSS et HTML suffisent à produire une implémentation propre.

  • Pour quelqu’un qui a appris le CSS avec des ressources comme Zen Garden et Eric Meyer, les outils CSS modernes comme Tailwind ressemblent à un anti-pattern

    • Je suis entièrement d’accord. Tailwind a vraiment beaucoup de problèmes
      Le HTML se retrouve recouvert d’informations de style. Lire du HTML devrait consister à voir le contenu et la sémantique, pas à décoder que pl-16 pr-8 bg-olive-500 text-gray-700 signifie « probablement un en-tête de carte »
      On peut dire qu’aujourd’hui les gens ne lisent plus le HTML, mais si les développeurs qui utilisent ce genre de framework transforment le HTML en bazar infâme, qui va le lire ? Quand il y a trop de classes de framework, le HTML contient plus de bruit que de contenu ; la lecture du HTML disparaît donc, et les développeurs empilent à nouveau davantage de classes et de styles : un cycle auto-renforçant
      Les développeurs web dupliquent aussi énormément les styles. Au lieu de quelque chose comme .button, des combinaisons du type text-white rounded bg-gray-aaa sont dispersées à des centaines d’endroits. Je ne sais pas si c’est un problème de Tailwind ou de développeurs, mais dans les gros projets, changer le style de tous les éléments d’UI similaires devient une partie de whac-a-mole pour retrouver quel style inline sur quel élément il faut modifier
    • Ce genre d’outils CSS semble séduisant pour les personnes qui ont appris le développement web sur le tas. Au début, on partait de « en-tête, texte, image » parce qu’on voulait créer le design qu’on avait en tête, puis on apprenait en se demandant « comment centrer ça ? », « comment changer la couleur ? », « et l’espacement entre les éléments ? »
      On se constitue alors vite une boîte à outils d’idées CSS, mais on passe à côté des détails qui font que le CSS fonctionne bien. Je savais contourner des problèmes bizarres avec position: absolute et transform, mais je ne connaissais pas le contexte de formatage de bloc ni les subtilités du modèle de boîte
      Si vos connaissances CSS ne sont que des rustines posées sur des connaissances CSS fragiles, vous ne faites que brûler du carburant. Dans ce cas, apporter une boîte à outils de styles composables qui permet d’éviter beaucoup de pièges du CSS peut sembler séduisant
      Ce qui m’a fait changer d’avis, c’est une courte série de livres en ligne qui enseignait HTML/CSS depuis les bases. Elle expliquait tout à partir des premiers principes et pourquoi les choses étaient ainsi, au lieu de balancer « 10 façons de centrer une div » et de s’arrêter là. Je l’ai lue en un après-midi et elle a changé ma manière de voir le développement web, mais impossible de me souvenir du nom du livre. Je me rappelle surtout cette phrase : « display: block ressemble à un document Word, et display: flex est plus proche de la façon dont les gens s’attendent à ce que ça marche »
    • Le code Tailwind est vraiment laid. Je le déteste. Quand il est arrivé, je travaillais sur de gros sites, et l’idée de coller des centaines de propriétés de style sur des milliers de pages au lieu de quelques lignes dans un fichier CSS et d’un nom de classe me semblait être une énorme régression, qui annulait la moitié des avantages du CSS
    • Je pense que ça fonctionne bien comme standard dans une entreprise de plusieurs centaines de personnes. Si vous voulez tout styler de manière jetable sur une landing page, faites-le

  • Cela ressemble à un peu de lumière dans l’âge sombre de Tailwind et du CSS-in-JS
    Il est difficile aujourd’hui de mesurer à quel point CSS Zen Garden a été important il y a une vingtaine d’années

    • Le CSS-in-JS est surtout une solution d’organisation du code, comme avec Styled Components ou Emotion. Il ne change pas fondamentalement la façon dont le CSS fonctionne
    • C’est sûr que ça m’a fait aimer le CSS. Cela ne veut pas dire que je ne comprends pas pourquoi Tailwind est séduisant dans les projets à grande échelle
    • Quand j’ai commencé à apprendre le CSS, j’ai acheté leur livre. C’était vraiment une autre époque

  • À l’époque, ce site a eu une énorme influence sur moi
    Pour ceux qui ne connaissent pas, on pouvait proposer un design pour le même contenu HTML en utilisant uniquement du CSS et des images. Voici quelques exemples qui m’avaient particulièrement marqué
    https://csszengarden.com/202/
    https://csszengarden.com/189/
    https://csszengarden.com/177/
    https://csszengarden.com/136/
    https://csszengarden.com/206/
    Il y avait aussi un design où, en faisant défiler la page, une épée en position: fixed « coupait la page en deux », mais il ne semble plus être dans la liste. Je me souviens aussi d’un autre où le haut de la page était le niveau de la mer, et où, en scrollant vers le bas, on trouvait au fond de l’océan soit une pieuvre, soit un sous-marin, soit un plongeur

    • Pareil pour moi. Quand je vois ces designs, je me rappelle à quel point le web design est devenu ennuyeux aujourd’hui

  • J’y ai publié deux designs, et je reçois encore aujourd’hui des e-mails me demandant l’autorisation de réutiliser le CSS

  • Voir CSS Zen Garden aujourd’hui sur HN m’a vraiment fait plaisir. C’était une belle époque.
    Mais il faut quand même que je râle un peu.
    Ce qui m’inquiète le plus avec Tailwind et les « frameworks » CSS similaires, ainsi qu’avec le développement logiciel moderne en général, c’est qu’on semble de plus en plus fier de ne pas comprendre le système sous-jacent.
    Tailwind offre une solution rapide et superficielle. On colle des classes utilitaires sur la page et on obtient un résultat « suffisamment correct » sans jamais apprendre comment CSS fonctionne réellement. Peu importe si le HTML devient un foutoir avec plus de classes CSS que de contenu.
    L’attitude, c’est : « Qu’est-ce que ça peut faire de savoir comment ça marche ? La page est jolie. C’est gagné ! »
    Ce n’est pas seulement un problème propre à Tailwind, mais une tendance plus large dans l’industrie. On célèbre l’ignorance et on se précipite vers le résultat sans construire une vraie compréhension.
    Depuis quand est-ce devenu une fierté de ne pas savoir ? C’est triste de voir la profondeur et la maîtrise traitées comme optionnelles, voire indésirables.

    • C’est choquant de voir à quel point la plupart du HTML est mauvais. Je viens de regarder Twitter : un post de ma timeline ne contenait qu’un paragraphe de texte, une image et une dizaine d’icônes liées, mais rien que le HTML faisait 254 lignes, 21,8 ko, avec 104 div imbriqués et plus de 860 classes.
      Il y a plus de classes que de caractères dans le contenu textuel, et les noms de classes représentent à eux seuls environ 9 ko. Et ça se répète pour chaque post de la timeline.
      Quelques div, quelques classes, une classe par icône et quelques lignes de CSS devraient suffire. Sérieusement, on pourrait styler tous les posts de la timeline avec moins de caractères qu’il n’y en a dans les noms de classes d’un seul post.
      Je ne comprends pas comment des développeurs professionnels peuvent produire un HTML aussi obèse.
    • Le développement logiciel consiste à empiler des couches d’abstraction au fil du temps. Tu te débrouilles comment en assembleur ?
    • Je vois ce que tu veux dire, mais je ne pense pas que ça s’applique à Tailwind. Les classes Tailwind correspondent directement à des propriétés CSS, donc si tu ne comprends pas CSS, tu ne peux pas vraiment faire grand-chose.

  • On dirait quelque chose venu du passé. J’aimais CSS Zen Garden, mais son objectif et sa philosophie correspondaient à un monde où la finalité principale des sites web était de fournir des documents.
    Le monde des médias riches semble avoir laissé cette vision du web derrière lui vers le milieu des années 2000.

    • Plutôt que des médias riches, je dirais que le web est devenu 100 % centré sur le marketing. Même en faisant défiler, ce ne sont que des pubs.
    • C’est une sérieuse régression.
      https://blog.danieljanus.pl/2019/10/07/web-of-documents/
    • Tu parles d’un « monde où la finalité principale des sites web était de fournir des documents », mais nous vivons encore dans ce monde. Je ne dis pas ça par sarcasme.
      À part quelques applications de cartographie, la majeure partie du web consiste encore à lire quelque chose, et toute cette pagaille n’est pas nécessaire. C’est seulement plus complexe parce que les développeurs préfèrent la complexité à la simplicité.
    • Les « médias modernes » sont-ils vraiment riches ? J’ai plutôt l’impression que la densité d’information et le rapport signal/bruit empirent.

  • Content que Garden soit de retour. À l’époque où le design web basé sur CSS était à la pointe et où les gens commençaient à utiliser des div profondément imbriqués au lieu de table profondément imbriquées, CSS Zen Garden et Spoono faisaient partie de mes sites préférés.
    Le livre était bien aussi.