Projeto CSS Zen Garden

• O CSS Zen Garden é um projeto de demonstração que mostra como o mesmo documento HTML pode se transformar em uma experiência visual completamente diferente usando apenas design baseado em CSS
• Ao escolher uma folha de estilos na lista de designs, o HTML permanece igual e apenas o CSS externo muda, alterando a renderização da página
• Participantes podem baixar o HTML/CSS de exemplo e trabalhar localmente, mas, no envio, só podem modificar a folha de estilos
• O arquivo CSS finalizado e os recursos relacionados devem ser enviados para um servidor web próprio e submetidos por link; trabalhos selecionados são hospedados no servidor do CSS Zen Garden
• CSS prático tem prioridade sobre recursos experimentais, e são exigidos CSS validável e funcionamento no IE9+ e nas versões recentes de Chrome, Firefox, iOS e Android

---

Um experimento em CSS que faz o mesmo HTML parecer completamente diferente

• O CSS Zen Garden é uma demonstração criada para mostrar o poder expressivo do CSS
• Usuários podem escolher um item na lista de designs para aplicar a folha de estilos correspondente à página atual
• A restrição central está em trocar apenas o arquivo CSS externo, sem alterar o HTML
  • O resultado visual muda mantendo a mesma estrutura do documento
  • Mostra até onde design e codificação podem expandir as possibilidades visuais da web
• Pode ser visto como um projeto de aprendizado que incentiva participação e inspiração, compartilhando resultados que podem ser implementados na prática com CSS

Como participar e fluxo de envio

• Participantes redesenham esta página com base em um design visual forte e em suas habilidades com CSS
  • Os arquivos de exemplo têm comentários e podem servir como ponto de partida até para iniciantes em CSS
  • Tutoriais avançados e dicas são fornecidos no CSS Resource Guide
• O trabalho pode ser feito em uma cópia local baixando o HTML e o CSS de exemplo
• Para enviar, é preciso publicar o arquivo CSS finalizado e os recursos relacionados em um servidor web sob seu controle e enviá-los pelo link de submissão
  • Não é recomendado enviar trabalhos inacabados
  • As submissões selecionadas são baixadas pela equipe do CSS Zen Garden e hospedadas no servidor
• A recompensa pela participação está no reconhecimento, na inspiração e na contribuição para um material compartilhado que demonstra as possibilidades do CSS

Requisitos de CSS e licença

• Os requisitos são voltados a CSS funcional e prático, mais do que a recursos experimentais de ponta
  • Onde for possível, prefere-se o uso de CSS 1 e 2
  • CSS 3 e 4 devem ser limitados a elementos amplamente suportados ou oferecer alternativas robustas
  • O CSS deve passar por validação
  • Considerando user agents recentes e ambientes móveis, pode ser difícil obter layouts idênticos pixel a pixel em todas as plataformas
  • O design deve funcionar pelo menos no IE9+, nas versões recentes do Chrome e Firefox, e em navegadores iOS e Android
• As submissões devem ser artworks originais e respeitar a lei de direitos autorais
  • Materiais que possam causar desconforto devem ser minimizados
  • Como já há muitos designs relacionados a jardins, recomenda-se um tema visual único e interessante
• Os direitos autorais dos gráficos permanecem com quem enviou, mas o CSS deve ser publicado sob a mesma licença Creative Commons BY-NC-SA 3.0 do site para que outras pessoas possam usá-lo no aprendizado

[GN⁺]

Opiniões no Hacker News

• Há um contexto que não fica muito evidente para quem não fazia desenvolvimento web na época em que isso foi criado.
  Antes do CSS, abusava-se de elementos table como se fossem uma grade para criar layouts, e imagens eram fatiadas e colocadas em cada célula. Hoje as pessoas ainda lembram mais ou menos disso, mas a resistência ao CSS daquela época parece ter sido bastante esquecida.
  Muitos desenvolvedores web estavam satisfeitos com o status quo e não queriam aprender CSS, e o mito de que “com CSS só dá para fazer designs chatos e quadrados” persistia com força. Quando Dave Shea reuniu e mostrou designs incríveis no CSS Zen Garden, ele basicamente acabou com esse argumento; foi uma vitória tão completa que é engraçado como até o fato de essa discussão ter existido acabou sendo esquecido.

  • O CSS inicial era muito mais limitado do que o de hoje. border-radius só entrou por volta de 2011, e até um site relativamente simples como https://90s.dev/ precisa de cerca de 420 linhas com CSS moderno em https://90s.dev/style.css.
    Isso mesmo usando bastante aninhamento e o revolucionário :has. Por causa das limitações fundamentais do CSS na época, lembro de ter que mudar tanto o CSS quanto a estrutura HTML para implementar formas que não dava para criar de modo intuitivo.
  • O motivo de se usar table no começo era que fazer tudo alinhar corretamente com CSS em vários navegadores era um pesadelo. Um pesadelo caro, e só era tranquilo para startups bem financiadas que tinham folga para refatorar o HTML com frequência.
  • O momento exato é meio nebuloso, mas houve uma fase em que o CSS, ainda surgindo, era insuficiente para criar layouts mais complexos. Não havia flexbox, muito menos grid.
    Vejo o CSS Zen Garden como algo que existia para mostrar até onde dava para ir com CSS naquele momento.
  • Nunca entendi o que havia de tão errado, na prática, em criar grades com elementos table. Fora a conversa de “HTML semântico”, que só faz sentido para algumas aplicações, não vejo muita coisa.
  • Não me lembro de resistência ao CSS, mas lembro que era comum ver sites usando um pouco de CSS para estilizar fontes, enquanto o layout continuava em table. Isso não era resistência, era praticidade.
    Quando você precisava de uma grade estável e previsível, usava layout em table, especialmente em layouts densos e complexos. Também era comum só a navegação usar layout em table, e o objetivo da época era ser pixel perfect.
    Lembra dos elementos spacer por volta de 2000? No fim, eles não pegaram, e GIFs de pixel eram mais comuns e previsíveis.
    Até o flexbox se popularizar em 2014, layout com float em CSS era como equilibrar pratos girando. Divs vazias e divs com conteúdo se comportavam de maneiras diferentes, o que era doloroso; esse tempo eu não recupero, mas pelo menos fui pago por ele.
    A ideia de que o CSS inicial entregava facilmente layouts bonitos de “Zen Garden” não bate com a minha experiência. Mas eu estava criando sites de mídia informativa, não sites artísticos interessantes.

• Este site é antigo, e digo isso no bom sentido.
  Nos anos 2000, ele foi um choque cultural para mim e me levou a sair do Microsoft ASP.NET e criar apps no Linux. Percebi que “server controls” com parâmetros de inline style eram uma abordagem completamente errada, por assim dizer, “anti-internet”.
  Alex Russell, criador do Dojo JS, mostrou essa perspectiva em uma conferência, e fiquei chocado ao perceber quanta informação eu tinha perdido enquanto recebia notícias de tecnologia pelos canais da Microsoft.
  Por alguns anos, minhas ferramentas foram basicamente Web.py, HTML, JS e CSS; depois vieram jQuery, Backbone e Underscore, até que React e TypeScript pareceram deixar o novo “full-stack” pesado de novo.

  • Não sei o que impediria você de criar esse tipo de app em ASP.NET. O ASP.NET não bloqueava isso, e também era possível criar folhas de estilo e separar arquivos JS.
    Ironicamente, o antigo voltou a ser novo. No lado do Next.js, estão recriando view state; o Tailwind traz inline styling; e o shadcn usa componentes React, quase completando uma volta inteira.
  • Agora existe o Svelte, que pode ser visto como um full-stack um pouco “inteligente”.
  • Isso ainda está online. É quase uma relíquia antiga, mas dá para ver em https://www.ajaxtoolkit.net/. Não existia software corporativo sem drag panel.
    Por um tempo, markup semântico e CSS ficaram à frente, mas hoje em dia nem tenho mais interesse em acompanhar as tendências. Parei de me importar lá pelo “HTML dentro de JavaScript” (JSX).
  • Comecei com ASP e PHP, mas o ASP.NET tinha muito a cara de ajudar desenvolvedores de Visual Studio a criar web apps toscos, e não combinava com a web em sentido amplo.
    Nem precisei migrar para Linux. Como o departamento de TI não permitia desktop Linux, eu criava tudo no Windows e fazia deploy tanto em servidores Windows quanto Linux.

• Sinto que o ponto central do CSS Zen Garden era que, ao aproveitar ao máximo o HTML semântico, seria possível separar apresentação e conteúdo e tratá-los de forma totalmente independente.
  Até hoje é possível chegar ao nível do Zen Garden, mas, na prática, você está operando dentro dos limites do CSS. É mais uma lógica de “como o CSS consegue fazer isso, então crio este design” do que “quero este design, então uso este CSS”.
  Há muitas escolhas de estilo que só são possíveis alterando diretamente o DOM, e há coisas que não funcionam com CSS puro. Em discussões do W3C, já vi argumentos do tipo “por que precisamos de uma nova propriedade CSS se basta envolver em mais uma div?”.
  Inserir ou trocar imagens é simples, mas trocar SVGs que possam ser estilizados é impossível sem colocar os nós SVG diretamente no HTML. No fim, as decisões de apresentação e de estrutura de conteúdo acabam misturadas no nível de HTML e JavaScript, e até uma simples mudança de design passa a tocar a stack inteira.

  • A promessa da comunidade CSS sempre foi que seria possível separar estrutura e apresentação.
    Depois de 30 anos escrevendo GUIs, hoje tenho certeza de que a linha foi traçada no lugar errado. Em vez disso, é preciso isolar a intenção. No meu projeto, os Composites cumprem esse papel, e estou muito animado para lançá-los na semana que vem.
  • É aqui que entra o XSLT.
  • Por outro lado, o CSS hoje é muito poderoso; muitos designs que não são castelos no ar, mas levam em conta as características do meio, podem ser implementados de forma limpa apenas com CSS e HTML.

• Para quem aprendeu CSS com materiais como o Zen Garden e Eric Meyer, ferramentas modernas de CSS como o Tailwind parecem um antipadrão

  • Concordo totalmente. O Tailwind tem problemas demais
    O HTML fica coberto de informações de estilo. Ler HTML deveria ser sobre ver conteúdo e significado, não decifrar que pl-16 pr-8 bg-olive-500 text-gray-700 “provavelmente é o cabeçalho de um card”
    Dá para dizer que hoje em dia as pessoas não leem HTML, mas quem vai ler se desenvolvedores que usam esses frameworks transformam o HTML numa bagunça horrível? Quando há classes demais do framework, o HTML passa a ter mais ruído do que conteúdo; então a leitura de HTML desaparece, e isso vira um ciclo de autorreforço em que os desenvolvedores empilham ainda mais classes e estilos
    Desenvolvedores web também duplicam estilos demais. Em vez de algo como .button, combinações como text-white rounded bg-gray-aaa ficam espalhadas por centenas de lugares. Não sei se é um problema do Tailwind ou dos desenvolvedores, mas em projetos grandes, mudar o estilo de todos os elementos de UI parecidos vira um jogo de bate-toupeira para descobrir quais estilos inline de quais elementos precisam ser encontrados
  • Esse tipo de ferramenta de CSS parece atraente para pessoas que aprenderam desenvolvimento web de forma improvisada. No começo, queríamos criar o design que tínhamos na cabeça, então começávamos por “cabeçalho, texto, imagem” e aprendíamos coisas como “como centralizar?”, “como mudar a cor?”, “e o espaçamento entre os elementos?”
    Com isso, logo se forma uma caixa de ferramentas de ideias de CSS, mas acabamos perdendo os detalhes que fazem o CSS funcionar bem. Eu sabia contornar problemas estranhos com position: absolute e transform, mas não conhecia o contexto de formatação de bloco nem os detalhes do box model
    Se o seu conhecimento de CSS é só um monte de curativos colados sobre um conhecimento frágil de CSS, você só está queimando combustível. Nesse momento, pode parecer atraente adotar uma caixa de ferramentas de estilos combináveis que ajuda a evitar muitas armadilhas do CSS
    O que mudou minha opinião foi uma série curta em formato de livro online que ensinava HTML/CSS desde o básico. Ela explicava tudo a partir dos primeiros princípios e mostrava por que as coisas eram daquele jeito, em vez de simplesmente jogar “10 formas de centralizar uma div” e encerrar o assunto. Li tudo numa tarde e isso mudou a forma como eu via desenvolvimento web, mas de jeito nenhum consigo lembrar o nome do livro. Lembro especialmente da frase: “display: block é como um documento do Word, e display: flex é mais próximo do que as pessoas esperam”
  • Código Tailwind é realmente feio. Eu odeio. Quando ele surgiu, eu trabalhava em sites grandes, e a ideia de colocar centenas de propriedades de estilo em milhares de páginas, em vez de algumas linhas em um arquivo CSS e um único nome de classe, parecia um enorme retrocesso que desfazia metade das vantagens do CSS
  • Acho que funciona bem como padrão em empresas com centenas de pessoas. Se você quer estilizar tudo como algo descartável em uma landing page, vá em frente

• Parece um pouco de luz na era sombria do Tailwind e do CSS-in-JS
  Hoje é difícil sentir o quanto o CSS Zen Garden foi importante uns 20 anos atrás

  • CSS-in-JS é uma solução principalmente para organização de código, como no estilo do Styled Components ou do Emotion. Ele não muda fundamentalmente a forma como o CSS funciona
  • Com certeza foi o que me fez amar CSS. Mas isso não quer dizer que eu deixe de entender por que o Tailwind é atraente em projetos de grande escala
  • Quando comecei a aprender CSS, comprei o livro que eles publicaram. Era realmente outra época

• Este site teve uma influência enorme sobre mim no passado
  Para quem não conhece: era possível enviar designs para o mesmo conteúdo HTML usando apenas CSS e imagens. Alguns exemplos que me marcaram especialmente foram estes
  https://csszengarden.com/202/
  https://csszengarden.com/189/
  https://csszengarden.com/177/
  https://csszengarden.com/136/
  https://csszengarden.com/206/
  Também havia um design em que, ao rolar, uma espada com position: fixed “cortava a página ao meio”, mas parece que ele não está mais na lista. Lembro ainda de outro em que o topo da página era a superfície do mar e, ao rolar para baixo, havia no fundo do oceano um polvo, um submarino ou um mergulhador

  • Comigo também. Ver esses designs me faz lembrar como o web design ficou tedioso hoje em dia

• Publiquei dois designs lá e até hoje recebo e-mails pedindo permissão para reutilizar o CSS

• Foi muito bom ver o CSS Zen Garden hoje no HN. Bons tempos aqueles
  Mas agora preciso resmungar um pouco
  O que mais me preocupa no Tailwind e em “frameworks” CSS parecidos, e no desenvolvimento de software moderno em geral, é que cada vez mais se tem orgulho de não entender o sistema subjacente
  O Tailwind oferece uma solução rápida e superficial. Você cola classes utilitárias na página e obtém um resultado que “parece bom o suficiente” sem precisar aprender como CSS realmente funciona. Ninguém liga se o HTML vira uma bagunça com mais classes CSS do que conteúdo
  É a atitude de “que importa como funciona? A página ficou bonita. Sucesso!”
  Isso não é um problema só do Tailwind, mas uma tendência maior da indústria. Celebra-se a ignorância e se corre atrás apenas do resultado, sem construir entendimento real
  Desde quando não saber virou motivo de orgulho? É triste que profundidade e maestria sejam tratadas como opcionais, ou até indesejáveis

  • É chocante ver o quanto a maior parte do HTML é ruim. Acabei de olhar o Twitter: um post na minha timeline tinha apenas um parágrafo de texto, uma imagem e cerca de 10 ícones com link, mas só o HTML tinha 254 linhas, 21,8 kB, 104 divs aninhadas e mais de 860 classes
    Há mais classes do que caracteres no conteúdo textual, e só os nomes das classes somam cerca de 9 kB. Isso se repete em cada post da timeline
    Algumas divs, algumas classes, uma classe por ícone e algumas linhas de CSS deveriam bastar. Falando sério, daria para estilizar todos os posts da timeline com menos caracteres do que há nos nomes de classes de um único post
    Não entendo como desenvolvedores profissionais conseguem produzir um HTML tão absurdamente inchado
  • Desenvolvimento de software é ir acumulando camadas de abstração ao longo do tempo. Você é bom em assembly?
  • Entendo o que você quer dizer, mas acho que isso não se aplica ao Tailwind. As classes do Tailwind correspondem diretamente a propriedades CSS, então, se você não entende CSS, na prática não consegue fazer muita coisa

• Parece algo vindo do passado. Eu gostava do CSS Zen Garden, mas seus objetivos e sua filosofia eram adequados a um mundo em que o principal propósito dos sites era entregar documentos
  O mundo da mídia rica parece ter deixado essa visão da web para trás lá por meados dos anos 2000

  • Acho que, mais do que mídia rica, a web virou 100% orientada a marketing. Você rola para baixo e continua sendo anúncio
  • Isso é um downgrade sério
    https://blog.danieljanus.pl/2019/10/07/web-of-documents/
  • Você disse “um mundo em que o principal propósito dos sites era entregar documentos”, mas ainda vivemos nesse mundo. Não estou sendo sarcástico
    Tirando alguns aplicativos de mapas, a maior parte da web ainda é ler alguma coisa, e não precisa de tanta tralha assim. Só fica mais complexa porque os desenvolvedores preferem complexidade à simplicidade
  • “Mídia moderna” é realmente rica? Acho que a densidade de informação e a relação sinal-ruído estão piorando

• Fico feliz que o Garden tenha voltado. Na época em que web design baseado em CSS era o estado da arte e as pessoas começavam a usar divs profundamente aninhadas em vez de tables profundamente aninhadas, CSS Zen Garden e Spoono eram alguns dos meus sites favoritos
  O livro também era bom