-
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
1 comentários
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