Proyecto CSS Zen Garden

 (csszengarden.com)
2 puntos por GN⁺ 2025-04-28 | 1 comentarios | Compartir por WhatsApp
  • CSS Zen Garden es un proyecto demo que muestra cómo un mismo documento HTML puede convertirse en una experiencia visual completamente distinta solo con diseño basado en CSS
  • Al seleccionar una hoja de estilos en la lista de diseños, el HTML permanece igual y solo cambia el CSS externo, modificando el renderizado de la página
  • Los participantes descargan el HTML/CSS de muestra y trabajan localmente, pero al enviar su propuesta solo pueden modificar la hoja de estilos
  • El archivo CSS terminado y los recursos relacionados se suben al servidor web propio del participante y se envían mediante un enlace; los trabajos seleccionados se despliegan en el servidor de CSS Zen Garden
  • Se prioriza CSS práctico por encima de funciones experimentales, y se exige CSS validable y funcionamiento en IE9+ y en navegadores modernos Chrome, Firefox, iOS y Android

Un experimento con CSS que hace que el mismo HTML se vea completamente diferente

  • CSS Zen Garden es una demo pensada para mostrar el poder expresivo de CSS
  • El usuario puede elegir un elemento de la lista de diseños y aplicar a la página actual la hoja de estilos correspondiente
  • La restricción central es no modificar el HTML y reemplazar únicamente el archivo CSS externo
    • Mantiene la misma estructura del documento y cambia solo el resultado visual
    • Muestra hasta dónde el diseño y la codificación pueden ampliar las posibilidades visuales de la web
  • Puede verse como un proyecto de aprendizaje que fomenta la participación y la inspiración, y comparte resultados que realmente pueden implementarse con CSS

Forma de participar y flujo de envío

  • Los participantes rediseñan esta página basándose en un diseño visual sólido y en sus habilidades con CSS
    • Los archivos de ejemplo incluyen comentarios, por lo que también pueden servir como punto de partida para principiantes en CSS
    • Los tutoriales avanzados y consejos están disponibles en la CSS Resource Guide
  • El trabajo puede realizarse descargando el HTML y el CSS de muestra y trabajando sobre una copia local
  • Para enviar una propuesta, hay que subir el archivo CSS terminado y los recursos relacionados a un servidor web bajo control propio y enviarlos mediante el enlace de envío
    • No se recomienda enviar trabajos incompletos
    • Las propuestas seleccionadas serán descargadas por CSS Zen Garden y desplegadas en su servidor
  • La recompensa por participar está en el reconocimiento, la inspiración y la contribución a un recurso compartido que muestra las posibilidades de CSS

Requisitos de CSS y licencia

  • Los requisitos se centran en CSS funcional y práctico más que en funciones experimentales de última generación
    • Siempre que sea posible, se prefiere usar CSS 1 y 2
    • CSS 3 y 4 deben limitarse a elementos ampliamente soportados o incluir alternativas sólidas
    • El CSS debe pasar la validación
    • Al considerar agentes de usuario modernos y entornos móviles, puede ser difícil lograr un layout idéntico píxel por píxel en todas las plataformas
    • El diseño debe funcionar como mínimo en IE9+ y en navegadores modernos Chrome, Firefox, iOS y Android
  • Las propuestas deben ser arte original y respetar la ley de derechos de autor
    • Debe minimizarse el uso de material que pueda resultar ofensivo
    • Como ya hay suficientes diseños relacionados con jardines, se recomiendan temas visuales únicos e interesantes
  • Los derechos de autor de los gráficos permanecen con quien los envía, pero el CSS debe publicarse bajo la misma licencia Creative Commons BY-NC-SA 3.0 del sitio para que otras personas puedan usarlo para aprender

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-04-28
Opiniones en Hacker News

  • Hay un contexto que no se ve tan fácil si no hiciste desarrollo web en la época en que esto se creó.
    Antes de CSS, se abusaba de los elementos table como si fueran una grilla para crear layouts, y se cortaban imágenes en pedazos para ponerlas en cada celda. Hoy eso más o menos se recuerda, pero la resistencia contra CSS de aquel entonces parece bastante olvidada.
    Había muchos desarrolladores web conformes con el statu quo que no querían aprender CSS, y persistía el mito de que “con CSS solo se pueden hacer diseños aburridos y cuadrados”. Dave Shea reunió y mostró diseños geniales con CSS Zen Garden y, en la práctica, acabó con ese argumento; ganó de forma tan contundente que ahora hasta resulta curioso que se haya olvidado que esa discusión existió.

    • El CSS de los primeros tiempos era muchísimo más limitado que el de hoy. border-radius recién llegó alrededor de 2011, y aun un sitio relativamente simple como https://90s.dev/ necesita unas 420 líneas según su CSS moderno en https://90s.dev/style.css.
      Y eso incluso usando bastante anidación y el revolucionario :has. Recuerdo que, por las limitaciones fundamentales del CSS de la época, había que cambiar tanto el CSS como la estructura HTML para implementar formas que no se podían crear de manera intuitiva.
    • La razón por la que al principio se usaban tables era que lograr que CSS quedara bien en varios navegadores era una pesadilla. Una pesadilla cara, y solo estaba bien si eras una startup con bastante financiamiento y margen para rehacer el HTML con frecuencia.
    • No tengo claro el momento exacto, pero hubo una época en que CSS, que recién estaba apareciendo, no alcanzaba para crear layouts más complejos. No había flexbox, y ni hablar de grid.
      Creo que CSS Zen Garden existía para mostrar hasta dónde se podía llegar con CSS en ese momento.
    • Nunca entendí qué tenía de tan malo usar elementos table para crear una grilla. Más allá de lo de “HTML semántico”, que solo tiene sentido para algunas aplicaciones, no veo mucho más.
    • No recuerdo resistencia contra CSS, pero sí recuerdo que era común ver sitios que usaban un poco de CSS para estilizar fuentes y, aun así, usaban tables para el layout. Eso no era resistencia, era practicidad.
      Si necesitabas una grilla estable y predecible, usabas layout con tables, sobre todo en layouts densos y complejos. También era común que solo la navegación usara layout con tables, y el objetivo de la época era ser pixel perfect.
      ¿Recuerdan los elementos spacer alrededor del año 2000? Al final no se impusieron, y los GIF de píxel eran más comunes y predecibles.
      Hasta que flexbox se popularizó en 2014, hacer layouts con floats en CSS era como mantener platos girando. Los div vacíos y los div con contenido se comportaban distinto, lo que era un sufrimiento; no voy a recuperar ese tiempo, pero al menos me pagaron.
      La idea de que el CSS inicial te daba fácilmente layouts “Zen Garden” geniales no coincide con mi experiencia. Eso sí: yo estaba construyendo sitios de medios informativos, no sitios artísticos divertidos.

  • Este sitio es viejo, y lo digo en el buen sentido.
    En los 2000 fue un choque cultural para mí, y me llevó a dejar Microsoft ASP.NET y crear apps en Linux. Me di cuenta de que los “server controls” con parámetros de inline style eran una forma totalmente equivocada, digamos “anti-internet”, de hacer las cosas.
    Alex Russell, el creador de Dojo JS, mostró esa perspectiva en una conferencia, y me impactó descubrir cuánta información me había perdido mientras recibía noticias técnicas por canales de Microsoft.
    Durante algunos años mis herramientas fueron más o menos Web.py, HTML, JS y CSS; después llegaron jQuery, Backbone y Underscore, y luego React y TypeScript hicieron que el nuevo “full stack” volviera a sentirse pesado.

    • No sé qué impedía crear ese tipo de apps en ASP.NET. ASP.NET no lo prohibía, y también podías crear hojas de estilo y separar archivos JS.
      Irónicamente, lo viejo volvió a ser nuevo. Del lado de Next.js están recreando el view state; Tailwind vuelve al inline styling, y shadcn usa componentes React, así que casi dimos una vuelta completa.
    • Ahora existe Svelte, que podría verse como un full stack algo “inteligente”.
    • Eso todavía sigue en línea. Es casi una reliquia antigua, pero se puede ver en https://www.ajaxtoolkit.net/. No había software empresarial sin drag panel.
      Durante un tiempo el marcado semántico y CSS llevaron la delantera, pero hoy ya ni me interesa revisar las tendencias. Perdí el interés más o menos cuando apareció “HTML dentro de JavaScript” (JSX).
    • Empecé con ASP y PHP, pero ASP.NET estaba más orientado a ayudar a los desarrolladores de Visual Studio a hacer aplicaciones web mediocres, y no encajaba con la web en sentido amplio.
      Ni siquiera hacía falta mudarse a Linux. Como el departamento de IT no permitía escritorios Linux, hacía todo en Windows y desplegaba tanto en servidores Windows como Linux.

  • Siento que el punto central de CSS Zen Garden era que, si aprovechabas al máximo el HTML semántico, podías separar presentación y contenido y tratarlos de forma totalmente independiente.
    Incluso hoy se puede llegar hasta algo como Zen Garden, pero en realidad te estás moviendo dentro de los límites de CSS. Es más bien “CSS puede hacer esto, así que hago este diseño”, no “quiero este diseño, así que uso este CSS”.
    Hay muchas elecciones de estilo que solo son posibles si modificas el DOM directamente, y hay cosas que no se pueden hacer con CSS puro. Incluso en discusiones del W3C vi argumentos del tipo “¿para qué hace falta una nueva propiedad CSS si basta con envolverlo en un div más?”.
    Insertar o reemplazar imágenes es simple, pero reemplazar SVG estilables es imposible porque hay que poner los nodos SVG directamente en el HTML. Al final terminas mezclando decisiones de presentación y de estructura del contenido a nivel de HTML y JavaScript, y hasta un cambio de diseño sencillo toca todo el stack.

    • La promesa de la comunidad CSS siempre fue que se podía separar estructura y presentación.
      Después de 30 años escribiendo GUI, ahora estoy convencido de que la línea se trazó en el lugar equivocado. En cambio, hay que aislar la intención. Los Composites de mi proyecto cumplen ese rol, y estoy muy entusiasmado por publicarlos la próxima semana.
    • Aquí entra XSLT.
    • Por otro lado, el CSS actual es muy potente, y muchos diseños que no son castillos en el aire sino que consideran las características del medio se pueden implementar limpiamente solo con CSS y HTML.

  • Desde la perspectiva de alguien que aprendió CSS con recursos como Zen Garden y Eric Meyer, las herramientas modernas de CSS como Tailwind parecen un antipatrón

    • Totalmente de acuerdo. Tailwind tiene muchísimos problemas.
      El HTML queda cubierto de información de estilos. Leer HTML debería consistir en ver el contenido y la semántica, no en descifrar que pl-16 pr-8 bg-olive-500 text-gray-700 “probablemente sea el encabezado de una tarjeta”.
      Se podría decir que hoy la gente ya no lee HTML, pero si los desarrolladores que usan estos frameworks convierten el HTML en un desastre espantoso, ¿quién lo va a leer? Cuando hay demasiadas clases del framework, el HTML termina teniendo más ruido que contenido; entonces se deja de leer HTML, y eso se convierte en un ciclo de autorrefuerzo en el que los desarrolladores vuelven a acumular aún más clases y estilos.
      Los desarrolladores web también duplican estilos en exceso. En vez de algo como .button, combinaciones como text-white rounded bg-gray-aaa quedan desperdigadas en cientos de lugares. No sé si es un problema de Tailwind o de los desarrolladores, pero en proyectos grandes, cambiar el estilo de todos los elementos de UI similares se vuelve un juego de golpear topos para encontrar qué estilo inline de qué elemento hay que tocar.
    • Ese tipo de herramientas de CSS parece atractivo para quienes aprendieron desarrollo web de forma improvisada. Al principio quería construir el diseño que tenía en la cabeza, así que empecé con “encabezado, texto, imagen” y fui aprendiendo cosas como “¿cómo lo centro?”, “¿cómo cambio el color?”, “¿y el espaciado entre elementos?”.
      Así se arma rápido una caja de herramientas de ideas de CSS, pero se pasan por alto los detalles que hacen que CSS funcione bien. Sabía esquivar problemas raros con position: absolute y transform, pero no conocía el contexto de formato de bloque ni los detalles finos del modelo de caja.
      Si tu conocimiento de CSS no es más que parches pegados sobre un conocimiento flojo de CSS, solo estás quemando combustible. En ese momento puede parecer atractiva una caja de herramientas de estilos combinables que te ayude a evitar muchas trampas de CSS.
      Lo que me hizo cambiar de opinión fue una serie en formato de libro breve en línea que enseñaba HTML/CSS desde lo básico. Explicaba todo desde primeros principios y por qué era así, no solo te tiraba “10 formas de centrar un div” y listo. Lo leí todo en una tarde y cambió mi forma de ver el desarrollo web, pero no logro recordar el nombre del libro. Recuerdo especialmente una frase: “display: block es como un documento de Word, y display: flex se acerca más a cómo la gente espera que funcione”.
    • El código de Tailwind es realmente feo. Lo detesto. Cuando salió, yo estaba trabajando en sitios grandes, y la idea de poner cientos de propiedades de estilo en miles de páginas, en lugar de unas pocas líneas en un archivo CSS y un nombre de clase, me pareció un gran retroceso que deshacía la mitad de las ventajas de CSS.
    • Creo que funciona bien como estándar en una empresa de cientos de personas. Si en una landing page quieres estilizar todo como algo de un solo uso, adelante.

  • Se siente como un poco de luz en la era oscura de Tailwind y CSS-in-JS.
    Hoy cuesta sentir lo importante que fue CSS Zen Garden hace unos 20 años.

    • CSS-in-JS, al estilo de Styled Components o Emotion, es principalmente una solución para la organización del código. No cambia de raíz la forma en que funciona CSS.
    • Definitivamente hizo que me enamorara de CSS. Eso no significa que no entienda por qué Tailwind resulta atractivo en proyectos grandes.
    • Cuando empecé a aprender CSS compré el libro que publicaron ellos. Era otra época, de verdad.

  • En su momento este sitio tuvo una influencia enorme en mí.
    Para quienes no lo conocen: para el mismo contenido HTML se podían enviar diseños usando solo CSS e imágenes. Algunos ejemplos que me impresionaron especialmente fueron estos:
    https://csszengarden.com/202/
    https://csszengarden.com/189/
    https://csszengarden.com/177/
    https://csszengarden.com/136/
    https://csszengarden.com/206/
    Había también un diseño en el que, al hacer scroll, una espada con position: fixed “cortaba la página por la mitad”, pero parece que ya no está en la lista. También recuerdo otro en el que la parte superior de la página era la superficie del mar y, al desplazarte hacia abajo, en el fondo del océano había uno de estos: un pulpo, un submarino o un buzo.

    • Me pasa igual. Ver esos diseños me recuerda lo aburrido que se volvió el diseño web hoy.

  • Subí dos diseños ahí, y todavía recibo correos pidiendo permiso para reutilizar el CSS.

  • Me dio mucho gusto ver hoy CSS Zen Garden en HN. Eran buenos tiempos.
    Pero ahora me toca quejarme un poco.
    Lo que más me preocupa de Tailwind y otros “frameworks” de CSS parecidos, y del desarrollo de software moderno en general, es que cada vez se presume más no entender el sistema de base.
    Tailwind da una solución rápida y superficial. Pegas clases utilitarias en la página y obtienes algo que “se ve suficientemente bien” sin tener que aprender cómo funciona realmente CSS. No importa que el HTML se vuelva un desastre con más clases CSS que contenido.
    La actitud es: “¿Qué importa cómo funciona? Salió una página bonita. ¡Éxito!”.
    Esto no es un problema solo de Tailwind, sino una tendencia más amplia de la industria. Se celebra la ignorancia y se apresuran los resultados sin construir una comprensión real.
    ¿Desde cuándo no saber se volvió motivo de orgullo? Es triste que la profundidad y la maestría se traten como opcionales, incluso como algo indeseable.

    • Es impactante ver lo malo que es la mayor parte del HTML. Acabo de ver Twitter, y una publicación de mi timeline tenía solo un párrafo de texto, una imagen y unos 10 íconos enlazados, pero el HTML tenía 254 líneas, 21.8 kB, 104 divs anidados y más de 860 clases.
      Hay más clases que caracteres de contenido de texto, y solo los nombres de las clases ocupan unos 9 kB. Eso se repite en cada publicación del timeline.
      Unos cuantos divs, unas cuantas clases y una clase por ícono, más unas líneas de CSS, deberían bastar. En serio, se podrían estilizar todas las publicaciones del timeline con menos caracteres que los que ocupan los nombres de clases de una sola publicación.
      No entiendo cómo desarrolladores profesionales pueden producir HTML tan absurdamente inflado.
    • El desarrollo de software consiste en acumular capas de abstracción con el tiempo. ¿Qué tan bien manejas assembly?
    • Entiendo lo que dices, pero no creo que aplique a Tailwind. Las clases de Tailwind corresponden directamente a propiedades de CSS, así que si no entiendes CSS, en realidad no puedes hacer gran cosa.

  • Se siente como algo llegado del pasado. Me gustaba CSS Zen Garden, pero su objetivo y filosofía estaban pensados para un mundo en el que el propósito principal de un sitio web era entregar documentos.
    Parece que el mundo de los medios enriquecidos dejó atrás esa visión de la web hacia mediados de los 2000.

    • Más que medios enriquecidos, creo que la web se volvió 100% centrada en marketing. Sigues bajando y todo sigue siendo publicidad.
    • Eso es un downgrade grave.
      https://blog.danieljanus.pl/2019/10/07/web-of-documents/
    • Dices “un mundo en el que el propósito principal de un sitio web era entregar documentos”, pero todavía vivimos en ese mundo. No lo digo con sarcasmo.
      Salvo algunas aplicaciones de mapas, la mayor parte de la web sigue siendo leer algo, y no se necesita tanta chatarra para eso. Solo se vuelve más compleja porque los desarrolladores prefieren la complejidad a la simplicidad.
    • ¿Los “medios modernos” son realmente enriquecidos? Creo que la densidad de información y la relación señal/ruido más bien han empeorado.

  • Me da gusto que Garden haya vuelto. En la época en que el diseño web basado en CSS era de vanguardia y la gente empezaba a usar divs profundamente anidados en lugar de tables profundamente anidadas, CSS Zen Garden y Spoono eran de mis sitios favoritos.
    El libro también era bueno.