-
reset
- A autora começou copiando cerca de 200 linhas dos preflight styles do Tailwind para
tailwind.css
- Ela já estava acostumada há muito tempo com o reset do Tailwind, e a regra que aplica
box-sizing: border-box a todos os elementos faz com que a largura do elemento inclua o padding
* { box-sizing: border-box; }
- Também é possível que ela dependa inconscientemente de outras regras de reset, como
html {line-height: 1.5;}, e escrever CSS sem essas regras parece exigir uma grande adaptação
-
components
- A maior parte do CSS foi organizada em arquivos por componente, de forma semelhante a componentes Vue ou React
- Cada componente tem uma classe exclusiva, e a estrutura evita que o CSS de um componente sobrescreva o CSS de outro
- Na prática, cerca de 80% do CSS que ela quer alterar está dentro do arquivo do componente, então ao editar um componente de 100 linhas basta pensar nessas 100 linhas
- Por exemplo, o componente
.zine pode ter o seguinte HTML
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- O CSS reúne, com seletores aninhados, estados como
.horizontal, .vertical e :hover dentro do próprio componente
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Embora ela não tenha bloqueado programaticamente a interferência entre componentes com Web Components ou
@scope, só de definir e seguir convenções a situação já melhorou bastante
-
colours
- Em
colours.css, ela reúne variáveis CSS que podem ser usadas quando necessário
- Como cores são difíceis, e ela não queria revisar o uso de cores neste refactor, manteve a abordagem existente
- A única regra é listar nesse arquivo todas as cores usadas no site
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- No Tailwind, bastava escolher um degrau de tamanho, como
text-lg, xl ou 2xl, sem precisar lembrar se usava em, px ou rem
- Para manter isso em CSS vanilla, ela definiu variáveis de tamanho trazidas do Tailwind
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- Os tamanhos de fonte são definidos por variáveis; é um pouco mais verboso que no Tailwind, mas por enquanto é um método satisfatório
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- Elementos repetidos em vários componentes, como botões, são classificados como utilities
- Algumas classes utilitárias, como
.sr-only para elementos que devem aparecer apenas para usuários de leitor de tela, foram copiadas do Tailwind
- A ideia é manter essa área pequena e alterar com cuidado
-
base
- Estilos “base” são estilos aplicados diretamente ao site inteiro
- Como ela não tem confiança suficiente para impor muitos estilos ao site todo, essa área é mantida bem pequena
- No momento, as duas regras que parecem aceitáveis são para
<section> e a, e a regra de <section> pode mudar depois
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- Parece mais fácil manter os estilos base quase vazios no começo e, quando encontrar algo desejável em comum, mover isso dos componentes para a base em uma abordagem bottom-up
-
spacing
- A forma de gerenciar padding e margin ainda não está totalmente definida
- Quando usava Tailwind, ela colocava padding e margin de forma improvisada aqui e ali até o visual ficar como queria; agora está buscando uma abordagem mais baseada em princípios
- No momento, a intenção é fazer com que componentes de layout mais externos assumam a responsabilidade pelo espaçamento sempre que possível
- Quando se quer espaçar uniformemente os filhos dentro de um
<section> com vários filhos, a seguinte regra pode ser usada
section > *+* {
margin-top: 1rem;
}
-
responsive design
- No Tailwind, ela usava bastante uma sintaxe baseada em media queries, como
md:text-xl, para aplicar o estilo text-xl acima de um certo tamanho
- Agora, ela quer criar layouts com CSS grid mais flexíveis, que não precisem de tantos breakpoints
- Com
auto-fit, é possível usar automaticamente 2 colunas em telas grandes e 1 coluna em telas pequenas
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- Durante o desenvolvimento, não é necessário um sistema de build separado
- O CSS tem
@import embutido, então é possível dividir e importar arquivos
@import "reset.css";
@import "typography.css";
@import "colors.css";
- O CSS também já tem seletores aninhados embutidos
.page {
h2 { ...}
}
- Se quiser agrupar arquivos CSS para produção, é possível usar
esbuild
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- Em geral, ela evita usar sistemas de build para CSS e JS, mas considera o
esbuild aceitável por ser baseado em padrões da web e um binário estático em Go
- Ela já escreveu em 2021 um artigo sobre esbuild e Vue
3 comentários
Não fica um pouco melhor agora que mudou para
zero-config?Comentários do Hacker News
Ensino HTML semântico e marcação acessível há muito tempo, e também já trabalhei bastante com sites e apps para leitores de tela, e o maior problema do Tailwind é inverter a ordem em que você deveria pensar HTML e CSS
HTML serve para marcar o significado do documento, então é por aí que se deve começar, e depois estilizar com CSS. Se for preciso adicionar elementos extras por causa do estilo, dá para usar div ou span, mas antes vale pensar se não existe um elemento melhor
O Tailwind empurra o desenvolvedor para uma abordagem CSS-first, fazendo com que ele pense primeiro nas classes do Tailwind que quer usar e depois adicione outra div no DOM só para conseguir aplicar essas classes
A competência de um desenvolvedor web deveria incluir a capacidade de produzir HTML e CSS legíveis no futuro, utilizáveis por todos os usuários e em grande parte alinhados às especificações de HTML/CSS, e o Tailwind prejudica isso. Até o primeiro exemplo no site do Tailwind usa só div e span, o que foi uma má formação para novos desenvolvedores e também contribuiu para a tendência de LLMs despejarem sopa de divs sem instruções adicionais
Qualquer ferramenta pode ser mal utilizada, e o Tailwind não é exceção. Uso CSS há cerca de 20 anos e também já usei Less, SASS/SCSS, Stylus e PostCSS, mas me fixei no Tailwind nos últimos anos justamente porque ele permite uma estilização de aplicações mais robusta
Você não precisa criar abstrações excessivas de estilos/classes, colocar os estilos diretamente na marcação afetada reduz a carga cognitiva, também diminui mudanças acidentais de estilo causadas por seletores frouxos e facilita o debug. Tirando sites/apps muito simples, muitas vezes um codebase com Tailwind é menos complexo e menos frágil do que um codebase com framework CSS customizado
Considerando escala consistente de fontes, cores e tamanhos, bundles menores, consistência entre desenvolvedores que conhecem Tailwind, ecossistema sólido e familiaridade com LLMs, é uma excelente opção para muitas equipes. No fim, como a maioria das ferramentas, pode ser bem ou mal usada dependendo de quem a usa
Vejo a bagunça de HTML/CSS/JS como um mal necessário quando se trabalha para navegadores; para mim, é só a camada de apresentação. No trabalho, dou muito mais peso à exatidão do esquema de banco de dados e da lógica de negócio no backend
Se uma camada de apresentação bagunçada, mas usada o mínimo possível, ainda resultar em código minimamente sustentável, já está bom, e para esse objetivo o Tailwind funciona bem. LLMs escrevem bem nisso, novos desenvolvedores entendem rápido, e depois também é relativamente fácil de ler e modificar
Concordo totalmente que um projeto com Tailwind não é a melhor forma de um iniciante aprender HTML/CSS, mas prefiro muito mais que um iniciante foque em bom esquema de banco de dados, APIs intuitivas, lógica de negócio testável etc.
Não há nada no Tailwind em si que obrigue a usar div e span no lugar de tags HTML apropriadas
Documento e interface são coisas diferentes, e o Tailwind faz muito mais sentido em interfaces. Você pode usar Tailwind na interface e usar seletores HTML com escopo limitado para outros tipos de conteúdo
O fato de o Tailwind ser cerca de 4 vezes mais rápido do que escrever um codebase CSS complexo, com praticamente nenhum overhead, continua sendo uma vantagem independentemente da avaliação feita
Em resumo, é uma forma de escrever CSS em ordem de especificidade:
/scss/
├── 1-settings. <- configurações globais
├── 2-design-tokens <- fontes, cores, espaçamento etc.
├── 3-tools <- mixins Sass, funções CSS etc.
├── 4-generic <- reset, box sizing, normalize etc.
├── 5-elements <- estilos básicos para títulos, botões e links
├── 6-skeleton <- grid de layout etc.
├── 7-components <- cards, carrosséis etc.
├── 8-utilities <- utilitários e classes helper
├── _shame.scss <- hacks para consertar depois
└── main.scss
O ITCSS praticamente elimina as brigas de especificidade em um codebase CSS. Em geral, o único lugar onde entra
!importanté na camada de utilitários[1]: https://matthiasott.com/notes/how-i-structure-my-css
Se você olhar bibliotecas de componentes, elas até incluem atributos
aria: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...A menos que seja algo mais próximo de um panfleto digital, como uma landing page, eu sempre começo pela marcação e depois adiciono as classes CSS por cima
Duas coisas boas do Tailwind são que já existe muita informação de classes nos dados de treinamento de IA e que não há conflito de estilos
Assim, quando a IA cria um novo estilo, ela não precisa consultar a stylesheet existente, o que é bom para gestão de contexto
Em CSS customizado, a IA precisa ler a stylesheet existente para reduzir conflitos ou duplicação, mas stylesheets grandes podem ocupar muita memória da IA e isso pode virar um problema
Eu realmente adoro os textos da Julia Evans
Ela escreve a partir de um lugar de vulnerabilidade e honestidade. Muita gente escreve para parecer inteligente, mas a Julia escreve com a atitude de “eu também não sei tudo, mas encontrei algo que queria compartilhar”. Mesmo sem conhecê-la pessoalmente, dá a sensação de alguém compartilhando algo com pessoas queridas
Na última Strange Loop, ela apresentou junto com Randall Munroe, e embora houvesse gente esperando para falar com ele depois da palestra, eu fiquei esperando para falar com a Julia. Sinto muito, de verdade, se ela não entendeu minha piada sobre reescrever scripts bash em Perl
Eu não sou a Julia, mas tenho quase a mesma filosofia em relação a palestras e apresentações públicas, e venho tentando passar isso para colegas que têm dificuldade com esse tipo de apresentação. Poder transmitir a colegas e pessoas queridas um conhecimento com o qual estou um pouco mais familiar, e que pode ajudá-las, é um grande privilégio
CSS Modules é uma solução mais simples para o problema da cascata. Ele gera nomes de classe únicos para evitar conflitos entre classes [1]
E não tem dois grandes problemas do Tailwind: legibilidade [2] e falta de suporte de ferramentas. Em especial, acho melhor o suporte para debug e experimentação interativa no Chrome e no FireFox DevTools
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
O que sempre me impressionou no Tailwind é que quase todo argumento dos defensores acaba chegando a “nunca aprenderam CSS acima de um nível júnior”
É comum ouvir coisas como “sem Tailwind, um único arquivo CSS grande e desorganizado vai crescer sem controle, cheio de código legado e
!important”, mas CSS é uma habilidade como qualquer outra habilidade técnicaSe você aprende só o suficiente para deixar algo com a aparência certa e vai remendando por cima, a ambição rapidamente supera a sua capacidade de manter o código organizado
É realmente frustrante quando você está discutindo Tailwind e CSS e percebe que a outra pessoa não só não sabe o que significa “cascading”, como nunca nem considerou que esse conceito pudesse ser útil no contexto de stylesheets
Uso bastante CSS desde os anos 90, dei uma olhada no Tailwind e, depois que entendi a proposta, passei a evitar CSS puro na maior parte do tempo. Em certo sentido, é trocar uma bagunça por outra, mas pessoalmente prefiro lidar com sopa de classes localizada do que com uma cascata sobreposta e contraditória espalhada por vários arquivos
Dá para implementar ambos de forma limpa, mas arrumar bagunça em Tailwind é muito melhor do que arrumar bagunça em CSS, e o processo de desenvolvimento como um todo também me parece bem mais agradável
Eu mesmo programo há mais de 20 anos e trabalho com desenvolvimento web há quase 15, mas tenho dificuldade em encontrar motivação para aprender CSS de verdade. Há competências técnicas demais para acompanhar, e CSS fica bem baixo na minha lista de prioridades
Eu preferiria deixar isso com especialistas, mas as empresas não querem contratar desenvolvedores frontend dedicados
Estou escrevendo um guia de desenvolvimento web limpo focado em HTML e CSS que escalam bem: https://webdev.bryanhogan.com/
Talvez seja útil para o pessoal daqui. Para estilização, não uso algo como Tailwind, só frameworks modernos como Astro ou Svelte e CSS
Em todo projeto eu mantenho
reset.css,var.css,global.csseutil.css, e o restante dos estilos fica com escopo restrito ao componente ou layout correspondenteBom texto
Gosto de remover dependências de bibliotecas externas e construir soluções do zero, mas há um motivo claro para eu não ter feito isso no caso do Tailwind: ele oferece otimização para produção e garante que só seja enviado o mínimo de CSS realmente necessário
Mesmo que você liste em
globals.cssou em outro lugar todas as opções de cores, espaçamentos etc., não precisa se preocupar se vai usar todas essas variações em produção. Se estiver trabalhando dentro de um framework como Next.js, essa etapa de minimização acontece automaticamente no build, e só isso já é motivo suficiente para eu não sair do TailwindTambém nunca senti limitações difíceis de contornar ao usar CSS inline no Tailwind, e nunca tive grandes problemas para implementar com as ferramentas de grid do Tailwind um grid realmente responsivo conforme a largura da tela. Já resolvi todos os cenários citados no texto com Tailwind ou com uma combinação de Tailwind e CSS, e embora seja verdade que
grid-column-areasnão existe por padrão, isso ainda não me pareceu uma limitação importante em layouts de grid responsivosO maior problema do Tailwind é que leva tempo para se acostumar a lê-lo. Somos ensinados que CSS inline é ruim e CSS de escopo global é bom, e nos acostumamos com HTML limpo; por isso, código Tailwind real, principalmente em linhas longas, no começo parece realmente difícil de ler. Depois de muito tempo usando, me acostumei completamente com a aparência e acabei chegando à conclusão de que, para mim, o Tailwind é mais eficiente, mais sustentável e até mais legível, mas isso levou um bom tempo
Uma abordagem de que eu gosto muito hoje em dia é usar Tailwind junto com estilos com escopo (em Svelte e Vue)
Assim dá para manter a praticidade do Tailwind e minimizar a poluição do template:
+
{{ count }}
Para mim, Svelte e LLMs eliminaram completamente a necessidade de Tailwind
No fim das contas, percebi que eu usava Tailwind principalmente não por alguma restrição autoimposta, mas para evitar conflitos de CSS e por causa de uma sintaxe que me parecia mais lógica
A melhor coisa no Tailwind, para mim, é não precisar inventar nomes de classe temporários. Você não precisa mais usar BEM
Comentários no Lobste.rs
Em projetos pessoais, quase não uso mais frameworks de CSS/JavaScript
porque, sem dependências, também não pode haver vulnerabilidades na cadeia de suprimentos. Claro, esse não é o único tipo de vulnerabilidade, mas ajuda
Isso é resultado da soma de cansaço de frameworks, sobrecarga com
npm audite do fato de que, graças aos LLMs, passei a me importar menos com a opinião dos outros sobre como implementar algo. Por exemplo, perguntas como “por que você não usa React e Tailwind?”Isso é simplesmente como o CSS funciona
Quando vejo gente usando Tailwind às cegas sem saber disso, dá vontade de sair gritando para as nuvens. Para mim, 90% do Tailwind é estilo inline com uma sintaxe diferente, e talvez dê para dizer que é só um passo acima da tag
<FONT>Este post explica coisas que eu realmente precisava aprender
O Tailwind funciona de forma bem diferente de estilo inline e, na verdade, é muito mais parecido com CSS. Como o texto aponta, uma boa parte dos bons hábitos que ajudam a usar bem o Tailwind também são hábitos necessários para escrever CSS de forma eficaz. O Tailwind está mais próximo de anexar a cada elemento um bloco CSS com escopo implícito, só que usando uma DSL própria
Eu entendo bem como o CSS funciona, mas CSS puro ainda me intimida, e também não sou forte em design gráfico, então continuo usando Tailwind. Este texto oferece ideias para estruturar CSS partindo do Tailwind
Para alguém que não acompanhou muito bem as tendências recentes, este texto parece mostrar bastante bem práticas modernas de CSS
Também gostei de haver muitos links para textos que serviram de inspiração. Parece uma boa leitura, e por enquanto só li "no outer margin"
Dito isso, fico um pouco cético quanto à abordagem de definir estilos-base “de baixo para cima”. Não sei bem o que faria no lugar, e parece algo que vale testar, mas estilos-base tendem a ser intrinsecamente complicados
Gostei muito deste texto
Eu também aprendi CSS aos poucos, fazendo vários sites pequenos, e acho que teria sido útil ter esse tipo de pensamento sistêmico desde o começo. Tenho bastante resistência a frameworks, mas, por não usá-los, mesmo sabendo implementar do jeito que quero, muitas vezes fico com a sensação de estar flutuando no vazio, sem estrutura
Gostei de que a mensagem não é “Tailwind é ruim, então use CSS”, e sim algo como “Tailwind é excelente, mas talvez você não precise mais dele”
Sempre tive dificuldade em estruturar CSS manualmente, e este texto me fez pensar de um jeito bem diferente
Ao organizar CSS, esta técnica de estruturação foi bastante útil para mim: https://rstacruz.github.io/rscss/
No geral, combina bem com o que a jvns explicou no texto original e acrescenta um pouco mais de estrutura e organização por cima