DEV Community: Camilo Micheletto

HTML básico para estudantes de TI

Camilo Micheletto — Tue, 08 Apr 2025 20:15:50 +0000

Geralmente a primeira aula de HTML não condiz às expectativas dos estudantes, que empolgados com a possibilidade de enfiar mais uma página colorida cheia de animações em um endereço web, terminam o dia com uma página branca de "hello word", como uma versão mais complicada de simplesmente escrever essas palavras em um Word ou google docs.

HTML é a sigla pra Hipertext Markup Language, e geralmente a introdução à linguagem foca nas características de Markup mais do que as de Hipertext. O conceito de marcação costuma ser interpretado como "demarcar áreas de conteúdo pra estilização de CSS", o que na melhor das hipóteses é meia verdade.

Quando você é autor de trabalhos escritos, mesmo que não esteja seguindo ABNT, seu trabalho provavelmente tem uma capa, um título, cabeçalhos com o título do capítulo, seções com conteúdo agrupado, textos de título, subtítulo, corpo e anotações e um rodapé com as referências (links), nome dos autores e número da página.

Ao pegar um trabalho impresso você provavelmente identifica o que são cada um desses elementos apenas por como eles se parecem, pela cor, tamanho da fonte, localização e contraste desses elementos, mas também porque durante a escola você foi formado pra entender essa sintaxe visual. Aqui fica claro que informação não são só caracteres na tela, a diferença de um título e uma citação é indicada de forma exclusivamente visual.

Diferente de um trabalho de escola ou faculdade, um site pode ser veiculado pra todo canto do mundo, que talvez entenda essa sintaxe visual de forma diferente - a leitura dessas pessoas pode ser na vertical, da direita pra esquerda, o significado dos pesos, cores, pode ser diferente.

Como os sites trafegam em bits que vão se complexificando até virarem informação em tela, eles não vão carregar essa sintaxe - essa semântica de forma visual. Logo, pra carregar essa semântica precisamos representar essa sintaxe visual na forma de um dado que trafegue pela internet e possa ser interpretado por diversos dispositivos e adaptado pra sintaxe visual de qualquer cultura ou nicho. Por isso HTML é um hipertexto de marcação.

A documentação da WHATWG descreve o HTML da seguinte forma:

HTML é a linguagem de marcação central da World Wide Web. Originalmente, o HTML foi projetado principalmente como uma linguagem para descrever semanticamente documentos científicos. No entanto, sua concepção geral permitiu que ele fosse adaptado, ao longo dos anos subsequentes, para descrever diversos outros tipos de documentos e até mesmo aplicações. - HTML Living Stardard, Backgorund

Citação original em inglês

HTML is the World Wide Web's core markup language. Originally, HTML was primarily designed as a language for semantically describing scientific documents. Its general design, however, has enabled it to be adapted, over the subsequent years, to describe a number of other types of documents and even applications.

Ou seja, o HTML é uma linguagem que descreve documentos e conteúdos de forma universal, acessivel e customizável.

Sites e documentos

Sites e aplicações são documentos de texto como qualquer outro. A diferença de um trabalho escolar e um site é a formatação do seu conteúdo e as funcionalidades que você aplica a ele - respectivamente, papel do CSS e do Javascript.

Nas primeiras aulas de front-end a distância entre as tags esquisitas que geram letras em uma página branca e um site como esse costuma parecer abismal:

Imagem do site Village Montreal

Mas por debaixo da formatação temos tags como qualquer outra que com sua semântica representam o conteúdo que compreendemos visualmente através do CSS. No exemplo abaixo a mesma página com as tags sobrepondo os elementos que elas representam.

Por incrível que pareça é a mesma página sem formatação CSS, contendo o mesmo conteúdo e a mesma semântica. Visualmente ela é muito diferente, mas ao ser escutada através de tecnologias assistivas ou lida por um terminal, como o Browsh.

Usando um script pra colorir os elementos é possível ver que mesmo a página sem CSS possui um layout, mesmo que simples. Ela tem margens, padding, tamanhos de fonte e afins. O navegador injeta esse CSS base pra que possamos visualizar os elementos mesmo sem criar estilos autorais.

Sem CSS	Com CSS

A sintaxe

Pra entender a forma de escrever HTML, temos que entender que elementos tem pais, filhos e irmãos, tanto no layout quanto no código:

Para agrupar elementos visualmente temos que colocá-los no mesmo container, no layout isso dá a sensação visual de unidade, no código faz com que as mudanças de layout sejam aplicadas apenas à componentes que se referem a aquela parcela da página ou componente.

Pai (Parent)	Irmão (Sibling)

"Pais" são elementos que possuem outros dentro, são chamados também de containers	"Irmãos" são componentes que ficam lado a lado

Isso é importante pois muitos conceitos importantes do HTML e do CSS se baseiam nessa relação de parent, children e sibling. Elementos HTML são representados por tags, uma de abertura e fechamento. Elementos que não possuem filhos, como imagens e quebras de linha "fecham" já na tag de abertura:

<section> <!-- <---- Abertura - elemento pai -->
  <p> Text </p> <!-- <---- Elemento filho -->
</section> <!-- <---- Fechamento -->

<img
  src="https://www.placehold.co/400x400"
  alt="Imagem de placeholder"
/>
<!-- Elemento img não pode receber filhos,
na prática não dá pra colocar algo dentro de uma
imagem dessa forma -->

Tags sinalizam abertura e fechamento de um elemento, o espaço entre as tags abrigam elementos filhos. Dentro da tag é possível escrever atributos que aderem funcionalidades à tags, como classes que recebem estilos, ids que criam uma variável global com o elemento no Javascript.

Existe mais de uma centena de atributos, separado em atributos específicos e globais. Os específicos são atributos que adicionam funcionalidade à elementos específicos, como o type que modifica o tipo de um input, que pode ser "text", "number", "tel", "date" e afins ou o atributo form que vincula elementos de formulário que estão fora de um elemento <form> a o formulário que eles se referem.

💡 A lista completa de atributos pode ser lida no MDN, nela você pode conferir quais elementos tem determinado atributo.

Você também pode ir na documentação da MDN do próprio elemento pra ver quais atributos são válidos nele e o que eles fazem:

Semântica

A maioria dos sites possuem uma barra de navegação que tem o papel de disponibilizar através de links partes do site que o usuário pode acessar, tal como na imagem abaixo.

Da esquerda pra direita, a barra de navegação contém um logo que ao clicar direciona pra página inicial, 5 links que direcionam pra diferentes páginas do site e um link estilizado como um botão que direciona pra página de entrar em contato.

Site do estudio Analogue

Simplificando (e muito) o código do site, a estrutura de HTML suficiente pra expressar essas funcionalidades seria algo como essa:

<nav>
  <a href="./index.html">
    <img src="logo.png" alt="Ir para página inicial" />
  </a>
  <ul>
    <li><a href="./work">Work</a></li>
    <li><a href="./service">Service</a></li>
    <!-- etc ... -->
    <li><a href="./connect">Connect</a></li>
  </ul>
</nav>

Usamos o nav pois ele representa estruturas que contém navegação. "Navegar" é ir de uma página a outra ou a diferentes trechos da mesma página através de links, logo toda porção do site que faz isso pode ser representada com essa tag. Ao usar o nav leitores de tela lêem em voz alta o trecho dentro desse container como "navegação", informando a pessoa usuária que dentro dela tem links.
Temos uma âncora (<a>) ao redor de uma imagem representando um logotipo clicável que direciona à pagina inicial (index.html). Toda âncora precisa ter um texto descrevendo onde ela vai pra que até usuários não videntes (pessoas que tem baixa ou nenhuma visão) possam ter contexto da onde o link vai. O link é lido como " link" - o texto alternativo passado no atributo alt= da imagem pode ser lido como texto de um link, no exemplo a cima o leitor de tela leria "Ir para página inicial, link".
Logo abaixo tem uma lista não ordenada (<ul>) que representa um ou mais items de lista (<li>) que não são representados em uma ordem específica. Dado que selecionamos o primeiro item da lista "Work", o leitor de tela leria "Work, link, lista 6 items". Usar esse formato pra todo tipo de lista, como listagem de produtos representada por cards, dá ao cliente a informação de que é uma lista e da quantidade de items que ela possuí.

Usar os elementos de HTML corretos habilita:

Melhor uso de estilos, tirando a necessidade de escrever CSS adicional pra adaptar um elemento.
Habilita super poderes específicos pra elementos, como <form> que faz com que qualquer botão dentro dele possa submeter o formulário e possuí mecanismos de validação nativos.
Deixa o HTML legível pra pessoas não videntes, pessoas que acessam a web por outras aplicações que não navegadores e crawlers.
Robôs que lêem o conteúdo do site para indexá-lo em mecanismos de busca ou extrair conteúdo.

Boa parte da acessibilidade é escrever HTML corretamente. Um site com HTML não semântico é um site "pronto" pra um publico muito menor do que você imagina. Um site só com <div> é impossível de navegar só com o teclado, obrigado os clientes a terem um dispositivo de ponteiro ou estarem usando as duas mãos. Imagina um site que basta seu cliente machucar a mão dominante ou ninar uma criança que ele já não consegue acessar?

Esse artigo é um work in progress, na próxima edição vou falar de tipos de container e sua relação com o conteúdo.

Acho que podemos deixar o mobile first em 2024

Camilo Micheletto — Sat, 15 Feb 2025 15:44:58 +0000

Esse ano o termo "responsividade" fez 14 anos, o manifesto que incentivou a ideia de uma web que não trancasse as pessoas em experiências estáticas fez 24 anos. Em fevereiro desse ano, Ethan Marcotte, o pai da responsividade postou isso:

I am a web designer in my twenties. I’m wondering why the industry is designing for one browser, and for a handful of screen resolutions. I am a web designer in my thirties. I’m wondering why the industry is designing for one browser, and for a handful of screen resolutions. I am a web designer in my forties. I’m wondering why the industry is designing for one browser, and for a handful of screen resolutions. I am a web designer in my fifties. I’m wonderi

Se você é uma pessoa webdesigner em 2024 e ainda está criando telas pra um navegador e um punhado de resoluções, esse texto é pra você.

Responsividade e o mobile first

Mobile first é irmão gêmeo do design responsivo, nascido com meses de diferença em 2009. Em minhas pesquisas, a primeira ocorrência sólida desse termo foi por Luke Wroblewski no artigo de mesmo nome.

Em "Mobile First" Luke aborda de maneira conceitual a explosão dos dispositivos móveis, que já davam suporte à uma navegação web palpérrima, mas que devíamos projetar nossas aplicações pra absorver essa demanda crescente.

Em 2011 ele publica o livro "Mobile First" pela A Book Apart (leia de graça, em inglês aqui). Em resumo, o foco desse livro é em:

Vender pra uma industria print/web que mobile era o futuro
Abordar os limites, capacidades e propriedades da web no telefone celular
Indicar padrões de design e layout a se seguir pensando em um universo mobile

Antes de Ethan Marcotte popularizar responsividade com media queries dentro do CSS, a forma popular de fornecer experiências específicas pra mobile era definir media types pra cada link do CSS, assim cada dispositivo carregaria um arquivo de CSS apropriado.

<head>
  <!-- ... -->
  <link rel="stylesheet" href="main.css" media="screen" />
  <link rel="stylesheet" href="paper.css" media="print" />
  <link rel="stylesheet" href="tiny.css" media="handheld" />
  <!-- ... -->
</head>

O problema é que o media type de handheld demorou pra receber suporte dos navegadores mobile, e quando esses se tornaram capazes o bastante pra dar esse tipo de suporte, handheld era pouco popular, fazendo os navegadores mobile escolherem o media type de screen como padrão

Como media types não eram consistentes no meio mobile, Ethan sugere o uso de media queries dentro do CSS, que com base em outra media feature - max/min-width - definíamos novas propriedades de CSS, adaptando o layout.

Introduzir a mudança das media queries como atributos HTML que carregam links de acordo com os media types pra media queries dentro do arquivo de CSS com breakpoints indicando o tipo de dispositivo era um movimento natural com a evolução do working draft das media queries no CSS e da separação de responsabilidades de marcação e estilo do HTML. No livro, Luke junta o conceito de mobile first com essa visão:

“Through the application of fluid layouts, flexible media, CSS3 media queries, and (sometimes) a bit of JavaScript, responsive web design allows you to adapt to devices more significantly. With responsive web design, you can set a baseline (mobile) experience first, then progressively enhance or adapt your layout as device capabilities change.
This is accomplished by setting resolution “break points” and applying a different set of layout rules and media assets to each. A break point can be thought of as a conditional statement that determines if a device meets specific criteria like a minimum width of 600 pixels. If that condition is true, then the browser applies a different set of layout rules, usually through CSS, though sometimes with a little JavaScript as well.” - Mobile First, capítulo 7

Os não tão novos breakpoints

Se você programa assim, você está escrevendo CSS de 2011:

O trecho acima foi extraído do livro Responsive Web Design do Ethan Marcotte e você pode ler online aqui

Mais pro final desse livro, o Um Anel do CSS, a tabela de screen devices inspirada no post de 2009 do Luke.

Percebe que essa tabela tem quase as mesmas media queries que as da maioria dos cursos de CSS que você já viu, ou das bibliotecas de estilo que já consumiu? Se essa tabela fosse uma pessoa, ela já estaria no ensino médio

O problema dessa solução não é ela ser antiga - responsividade com breakpoints foi criada em um momento histórico que não haviam recursos pra construir responsividade de forma robusta, mas já havia o desejo de não opinar na forma que o usuário navegaria no site.

Media queries eram utilizadas por serem uma das poucas formas de fazer com que o layout "respondesse" ao espaço disponível, jamais foi a intenção que ela se mantivesse a principal por tanto tempo, e ela só se manteve porque a comunidade não evoluiu junto com o CSS.

Em 2024 nós estamos reaproveitando esse conceito breakpoints, que nada mais são que expectativas sobre tamanhos de dispositivos pra que possamos forçar nossos layouts a se encaixarem nelas.

Expectativas essas que já estavam mortas na pluraridade de dispositivos que existiam em 2012.

Qual o melhor jeito?

O conceito de "melhor jeito" é uma forma preguiçosa de enxergar tecnologia e foi em partes responsável por manter soluções como breakpoints como bala de prata por tanto tempo. Procurar melhores jeitos é deixar de expandir o ferramental pra tomar decisões do que funciona pra cada caso de uso.

Após 2012 com a invenção do flexbox, conseguimos atribuir a qualquer container a habilidade de quebrar pra linha debaixo os elementos que não cabem no espaço disponível. Percebam como na menor resolução o conteúdo que eram várias linhas se transforma numa coluna

É comum que as pessoas tornem o layout flexível, mas o criem pra gerenciar componentes estáticos. Nesse bento grid que construi, ao invés de redefinir as medidas de cada célula e cada coluna por breakpoint, eu defini que proporção do layout esses elementos ocupam, os limites máximos e mínimos que devem respeitar e deixei o navegador detectar quando devem quebrar ou não.

Esse é um caso de uso simples, mas é comum que as pessoas usem media queries pra esse tipo de ajuste. Isso porque não basta que o container seja flexível, os componentes tem que ser.

Em Dao of Web Design (2000) de John Allsopp fala que pra criar designs que funcionem em qualquer navegador (e acrescento em qualquer dispositivo) precisamos sugerir sua aparência, não controlar.

No artigo Full-Bleed Layout Using CSS Grid do Josh Comeau, ele resolve uma das disposições de layout mais comuns com apenas poucas linhas de CSS - usando o grid pra calcular o espaço disponível da coluna central.

Esse layout de 2019 do artigo Look Ma, no media queries! cria uma galeria de cards completamente responsiva definindo os limites mínimos e máximos de cada coluna grid através da técnica RAM (Repeat, Autofit, Minmax)

Não faz mais sentido chutar uma largura de dispositivo e forçar seu layout a caber nele, hoje você pode criar layouts e componentes que vão se adaptar independente do contexto que você os aplique, basta sugerir seus limites.

O HTML por si só faz isso, basta não quebrar com CSS

Tudo bem você usar essa metodologia se construir de outras formas ainda for uma limitação pra você. Não tá tudo bem em 2024 ensinar e escrever sobre CSS como se a gente ainda tivesse em 2009. Já podemos parar de escrever sobre grid, flexbox e afins como grandes novidades.

Se você quer começar a ver um inédito viável dessa situação limite, pratique o ato limite da leitura. Você pode começar por essa lista de artigos que selecionei:

Allyhere / expert-css

Repositório contendo materiais de estudo de CSS avançado

Expert CSS

Uma lista de leituras de conceitos, tecnologias, padrões de arquitetura e práticas modernas de CSS muito além do básico.

CSS pode ser um pouco frustrante as vezes, principalmente porque ele demanda tanta dedicação quanto Javascript e seus frameworks. Visando entrega e funcionalidade, são poucas as oportunidades que temos de exercer práticas modernas de CSS, mesmo que em forma de melhoria contínua, então a leitura e a prática constante se fazem ainda mais importante.

Nesse repositório vou agregar leituras do que considero práticas avançadas de CSS - mas levem a palavra "avançado" não como uma tentativa de delimitar o que acredito ser complexidade, mas como uma sugestão pessoal com base em cursos que consumi e oportunidades que tive. Na minha experiência, talvez hajam pouquíssimos trabalhos que cobrem esse nível de CSS de você, arquitetura de CSS por assim dizer, então não se cobre tanto se o que você ler…

View on GitHub

Artigos sobre CSS que explodiram minha cabeça em 2024

Camilo Micheletto — Sun, 29 Dec 2024 16:44:31 +0000

Apresentar sobre os 3 pilares da arquitetura CSS no Front in Sampa de 2024 me deu a oportunidade de ler muita coisa sobre CSS do ponto de vista teórico, o que sinto que me deu uma visão mais madura, holística e estratégica do desenvolvimento de CSS em escala.

Nesse rolê descobri pontos de vista sobre o CSS que além de reacenderem minha curiosidade me deixaram empolgado pra tomar novas decisões com essas novas visões de mundo.

Cyclomatic Complexity: Logic in CSS de Harry Roberts

Complexidade ciclomática é uma métrica de complexidade de um programa - cada controle de fluxo e cada saída aumenta a complexidade de um método, classe ou aplicação.

No CSS complexidade pode significar seletores lentos, pouco reutilizáveis e excessivamente específicos.

div.sidebar .login-box a.btn span {}

/*
Pode ser lido como

IF (inside .btn)
AND IF (on a)
AND IF (inside .login-box)
AND IF (inside .sidebar)
AND IF (on div)

*/

"Think of your selectors as mini programs"

Link do artigo no blog CSSWizardry, em inglês

Conditional CSS por Ahmad Shadeed

Ainda sobre o valor de ver CSS como uma linguagem com operações lógicas, não apenas falando de media queries que fazem avaliações lógicas pra tornar código disponível de acordo com as condições do contexto, mas todo estado interativo, a presença ou não de um próximo seletor, de um índice de seletor ou da presença de um filho específico (com :has).

É um artigo que é extremamente atual com as novas propriedades e a mudança de paradigma causada por :has, container queries e as já existentes mas não tão exploradas support queries.

Link do artigo no blog do Ahmad Shadeed, em inglês

The CSS Cascade por Amelia Wattenberger

Cascade Stylesheets, e ainda assim é muito comum ver erros de CSS que envolvem a forma e ordem que o CSS é escrito. Nesse blog post lindo da Amelia Wattenberger de forma simples e visual ela demonstra como a cascata funciona e trás insights de como pensar seu CSS com ela em consideração.

Link do artigo no blog da Amelia Wattenberger, em inglês

A Brief History of CSS-in-JS: How We Got Here and Where We're Going por Dan Ward

Quanto mais precisei usar CSS-in-JS mais me incomodavam os seus pontos negativos, como bundle size, alterações runtime e uma arquitetura de reuso versus co-locação confusa. Com variáveis CSS se torna ainda mais obsoleto preferir arrow function versus injetar variáveis via styles - é muito mais simples e o CSS lida bem com esse tipo de escopo.

É nesse artigo que passamos entender porque e como existe, com links incríveis citados por todo ele.

Link do artigo no medium, em inglês

CSS and the critical path por Stoyan Stefanov

CSS é o maior ofensor na lentidão de carregamento web, de CSS não utilizado e excessivo, seletores e operações que na interação afetam mais nodes que deveriam até seletores complexos e lentos que demandariam menos overwork e mais arquitetura.

Nesse artigo você vai entender como o navegador funciona no carregamento, compliação e priorização desse asset crítico e como tornar o caminho até ele menos pesaroso pro usuário final.

Link do artigo no blog do Stoyan Stefanov, em inglês

Após ler, assista esse vídeo do Harry Roberts sobre performance CSS no Frontend United

Responsive Web Design

Ethan Marcotte cunhou o termo "responsividade" com base em montagens arquitetônicas que de certa forma respondiam à ocupação do seu espaço, esse vislumbre inspirado no texto de John Alsopp no ano 200 que clamava uma Web mais livre e que ditasse menos regras pros usuários em um mundo numa crescente de dispositivos mudou a forma como escrevemos interfaces e vai mudar sua forma de vê-las também.

Link do artigo no blog A List Apart, em inglês

Após ler, assista esse vídeo da Jen Simmons com um olhar moderno da responsividade - os layouts intrínsecos

Pra fechar

The future of loading CSS por Jake Archibald

Conheci o Jake assistindo HTTP 203 no canal do Google e sigo o blog dele desde então. Nesse artigo ele explora a possibilidade de incluir links nas dobras do <body> pra carregar de forma progressiva os estilos do que está abaixo da "dobra".

Não sabia que era possível? É, TIL também!

Link do artigo no blog do Jake, em inglês

Após ler, assista o show HTTP 203 no canal Chrome for Developers, aprendo muito com o Jake e seus convidades

5 dicas de design de um front-end pra UI Designers

Camilo Micheletto — Fri, 29 Nov 2024 18:32:11 +0000

Trabalho como front-end há mais de 5 anos e minhas interações com pessoas de produto sempre me trouxeram percepções muito ricas de como o planejamento e criação interagem com o desenvolvimento.

Nesse artigo eu trago 5 pontos cruciais do que aprendi nessas interações.

1º Dica - Entre um breakpoint e outro, sempre manipule os elementos proporcionalmente

Nos breakpoints desktop, tablet e mobile o quadrado no centro fica 20% menor, mas e numa tela 545 x 1017px de dimensão?

Se você teve que fazer uma regra de 3 pra descobrir, saiba que no front-end tem que fazer a mesma coisa pra manter a proporção nos breakpoints que você não declara.

Prefira diminuir ou aumentar valores sem usar números mágicos, isso torna possível calcular o aspecto do componente proporcionalmente com base em qualquer dimensão de tela.

No exemplo abaixo o padding (espaçamento interno) das variantes de tamanho dos botões abaixo aumenta em 4px entre si, isso faz com que possamos declarar algo como:

.btn {
  padding: calc(
    var(--btn-base-size) + (
      var(--btn-increment) * var(--btn-size-index)
    )
  );
}

Essa expressão equivale à soma do tamanho base do padding do botão (8px) à 4 vezes o índice do tamanho do botão (0 - small, 1 - regular, 2 - large). Pensando em um botão do tipo large, seria 8 + (4 * 2) = 16.

Isso é útil pro desenvolvimento pois uma mudança na proporção geraria apenas uma alteração no código, incluir uma nova variante seria apenas incluir um novo índice. O mesmo layout pode ter por debaixo um código muito ou pouquíssimo resiliente, as decisões de layout que pessoas designers tomam são capazes de afetar nosso leque de opções.

2º Dica - Existem definições de acessibilidade pra textos, evite tomar essas decisões por estética

O tamanho mínimo indicado pra fontes de corpo de texto é 16px, o que pode parecer pequeno ao se desenvolver em frames maiores, levando designers menos experientes a criar componentes ou blocos de texto maiores do que o necessário.

Além do tamanho da fonte, temos padrões de altura de linha, largura de texto, contraste de figura e fundo e zoom. Esses padrões nos ajudam a criar layouts que funcionam pra todas as pessoas, não só as videntes neurotípicas.

No critério de sucesso 1.4.8 (Apresentação visual) da WCAG ^{(em inglês)} temos alguns exemplos de formatos que facilitam a legibilidade pra pessoas com deficiências cognitivas ou baixa visão, tradução livre:

A largura total dos glifos não pode superar 80 caracteres (40 se caracteres CJK - Chinês, Japonês ou Coreano).

O texto não pode estar no formato justificado (alinhado nas margens da direita e da esquerda).

O espaçamento de linha (leading) é pelo menos "um espaço e meio" em parágrafos, e a distância entre parágrafos deve ser 1.5x maior que o espaçamento da linha.

Outro ponto é que pra web é melhor que as escalas de fontes sigam padrões compreensíveis. A escala de múltiplos de 4px por exemplo é útil pra adequação em dispositivos retina, mas também pra pessoas do front-end declararem rems sem números mágicos.

Abaixo, um artigo do Zack MacTavish sobre o grid system de 8px, em inglês.

Designing in the 8pt grid system. In this article, I have shared a mobile… | by Zack MacTavish | Bootcamp | Medium

Zack MacTavish ・ Aug 14, 2022 ・
Medium

Deixem o golden ratio pro design gráfico, por favor!

3º Dica - Não nomeiem seus tokens de forma arbitrária

Por exemplo, tokens de cor com nomes como deep-pink ou brand-grey não definem o contexto da aplicação (fill, background, border, etc), não indicam o estado que os utiliza (default, active, hover, pressed, etc).

Essas convenções permitem que criemos melhores tokens na aplicação sem precisar constantemente consultar o Figma ou zero-height pra saber pra que serve ou qual aplicação desses tokens.

Eles serem agnósticos de cor é importante pra possibilitar dark mode ou white label precisar "traduzi-los".

Um exemplo dessa tradução pra dark mode é a lib de CSS Open Props.

Supondo que a aplicação tem dark mode, se criássemos apenas tokens de cor como purple-200 ou orange-light, faria sentido substituir esses mesmos tokens por uma cor mais escura ou diferente?
Quando criamos tokens referentes a contexto e estado é pra evitar a perda de semântica de tokens específicos.

Design tokens cheatsheet, Oscar Gonzales - 2021, em inglês

4ª Dica - Evitem criar experiências de leitura diferentes do desktop pro mobile

A decisão de reorganizar ou sumir com elementos nos breakpoints menores não pode ser arbitrária. Sua hierarquia visual só é útil pra pessoas videntes, mais gente do que você imagina vai ler o site como texto ou navegar ele através do teclado.

Uma sequência de conteúdo com significado é um dos pilares mais básicos de uma boa acessibilidade e isso é problema seu também, designer. Critério de sucesso 1.3.2, Sequência com significado, da WCAG ^{(em inglês)}.

A experiência mobile precisa mudar? Experimente ler seu layout como um texto corrido, esse copy ainda precisa fazer sentido!

5ª Dica - Texto alternativo e contraste é problema de designer também

Toda imagem que vem sem indicação de texto alternativo ou todo botão de ícone que vem sem label da ação é um momento que uma pessoa desenvolvedora precisa atuar como UX Writer.

Guia do HandTalk sobre a escrita de textos alternativos

Não esqueçam que todo problema de contraste começa no Figma primeiro!

Cês adicionariam alguma dica aqui? Tem algo que não faz sentido? Bora conversar!

Tudo o que você precisa saber sobre a arquitetura BEM CSS

Camilo Micheletto — Tue, 01 Oct 2024 14:36:02 +0000

Escrevi esse artigo visando responder perguntas sobre BEM que geralmente não são feitas, mas a ausência de suas respostas impactam no desenvolvimento e entendimento da arquitetura.

Esse artigo não é voltado pra pessoas iniciantes que estão conhecendo BEM CSS agora e/ou nunca tiveram contato com convenções de nomenclatura de classes CSS. Se esse é o seu caso, pule pra seção de fontes.

Header adaptado do site oficial legado do BEM CSS

Pra que serve uma arquitetura CSS?
O que é o BEM CSS?
- Categorizando elementos da UI de acordo com seu acoplamento
- Expressando a relação dos componentes através do CSS
- Relações de componentes complexos
Controle da especificidade com BEM
Reuso de CSS
BEM e Sass
Interações com outras arquiteturas
Fontes

🔗 Pra que serve uma arquitetura CSS?

Tal como as plantas, a forma que um código vai crescer e prosperar depende de como a gente cria, mantém e de onde as coisas estão localizadas.

Existem plantas com necessidades diferentes de solo, trato, água e luz do sol, tal como existem códigos com necessidades diferentes de padrões, localização e gerenciamento.

CSS é um elemento crítico no carregamento de uma página - o processo de renderização não inicia antes do navegador requisitar, baixar e transformar todo HTML e CSS em DOM e CSSOM e montar a árvore de render. Quanto menos CSS, melhor vai ser a performance, quanto mais organizado, padronizado e robusto o CSS, melhor ele é de manter, gerenciar, escalar e comprimir.

A forma de nomear os seletores CSS influencia a abrangência das regras, especificidade, localização e semântica desses, agilizando ou deteriorando o processo de desenvolvimento. Em projetos que mais de uma pessoa escreve CSS, temos diferentes níveis de habilidade na linguagem e diferentes costumes ou padrões pessoais dela, que se não gerenciados podem resultar em repetição excessiva de regras e bugs.

🔗 O que é o BEM CSS?

BEM é uma arquitetura CSS focada em styleguide, ela define padrões de categorização e escrita de regras CSS. O BEM foi criado na Yandex num contexto de aplicações que continham diversas páginas gerenciadas por uma ou poucas folhas de estilo.

BEM é a sigla pra Block, Element, Modifier. Cada uma dessas entidades representa uma categoria de elemento da interface, que é diretamente representada no CSS.

Representação de componentes de interface visualmente separados, Fonte: Site oficial do BEM CSS

🔗 Categorizando elementos da UI de acordo com seu acoplamento

Um Block representa um elemento de UI que é independente, ele pode ter filhos, como um header tem seus links de navegação e esses filhos, se forem independentes, podem ser blocos também.

O conceito de independência de um componente da interface pode ser definido pelo seguinte axioma

"Se o componente só faz sentido dentro de um contexto específico, ele deve ser um elemento daquele contexto. Se ele pode existir em diversos contextos, ele deve ser um bloco independente."

Um element é um componente que compõe outro maior e pertence a ele. Caso esse componente não exista e não dependa somente do contexto que ele está aplicado, ele pode ser um block. No BEM os blocks podem conter outros blocos, se um element precisar conter um element, ele provavelmente também é um bloco.

A relação entre um bloco e um elemento é representada pelo duplo underline block__element.

Blocos e elementos podem conter variações estéticas ou de layout dentro de um mesmo contexto. Pra isso temos modifiers. Essas classes podem representar diferentes estados ou variantes de um mesmo componente. Modificadores tal como elementos dependem do bloco e derivam apenas dele.

A relação entre um bloco ou um elemento e seus modificadores é representada pelo traço duplo block--modifier ou block__element--modifier.

Referência	Descrição
	Um checkbox é independente, pode ser aplicado dentro de outros componentes como `<form>`, `<div>` ou `<FieldContainer />`, por exemplo.
	Uma label pode ser considerada um bloco independente se ela for igualmente aplicada nos inputs da aplicação. Se a diferença entre labels for estética, ela pode ser um bloco que contém diversas variantes (modifiers), se a diferença entre as labels do input for estrutural (no template), faz sentido ela ser o elemento de um bloco
	Um card pode ser incluído em qualquer container, em diferentes contextos, podendo ser considerado independente (block). Se a imagem e textos dentro dos cards tiverem características que só faz sentido no contexto do card, elas podem ser consideradas elements
	Um botão pode ser administrado em qualquer lugar, inclusive mais de uma variante no mesmo lugar. Cada variante pode ser representada pela classe modificadora derivada do mesmo bloco ou elemento.

🔗 Expressando a relação dos componentes através do CSS

Usando o exemplo do checkbox, a forma que construímos os componentes e definimos as suas responsabilidades influencia naquilo que pode ser bloco, elemento ou modificador. Essa tomada de decisão começa no template:

<div class="form-field">
  <input
   class="form-field__input form-field__input--checkbox" 
   type="checkbox"
   value=""
   id="checkbox"
  />
  <label class="form-field__label" for="checkbox">
    Default checkbox
  </label>
</div>

Nesse template temos como bloco o componente .form-field que sempre vai conter um input .form-field__input e uma label de classe .form-field__label. A relação entre bloco (.form-field) e elemento (label ou input) é expressa por um underline duplo. Essa escrita faz com que através do CSS a gente entenda que:

form-field é uma entidade independente, ela não depende contexto do componente ou container pai pra seus estilos funcionarem, qualquer formulário pode receber campos do tipo .form-field
Por sua vez, o form-field pode conter um __input e uma __label, e seu layout e aparência depende do container form-field

.form-field {}
  .form-field__input {}
  .form-field__input--checkbox {}
  .form-field__label {}

Ao alterarmos a relação no template, alteramos a topografia da classe CSS. No exemplo abaixo input e label são entidades separadas:

<div class="column">
  <label class="label" for="checkbox">
    Default checkbox
  </label>
  <input
   class="input input--checkbox"
   type="checkbox"
   value=""
   id="checkbox"
  />
</div>

.column nesse caso pode ser vista tanto como um bloco como simplesmente uma classe utilitária. Além de outras arquiteturas CSS, é possível usar BEM com classes utilitárias, inclusive com essas seguindo sua própria convenção.
.input é um bloco que se refere à todos os inputs, podendo ser utilizado dentro de um container .column ou qualquer outro, funcionando independente da existência de .label. Possúi uma variante --checkbox que carrega estilos específicos pro input do tipo checkbox, como o estado de :checked.
.label é um bloco que seu layout e aparência não dependem do input, podendo até ter um .input como elemento filho.

Expresso em CSS, ficaria da seguinte forma:

.column {}

.input {}
.input--checkbox {}
.input--checkbox:checked {}

.label {}

O BEM foca a independência dos componentes - alterar um componente de lugar no HTML não deve afetar seu layout, alterar o CSS de um componente não deve afetar os outros componentes. Quando criamos elementos, demonstramos uma relação daquilo que será afetado quando alteramos seu bloco. Dessa forma você tem visibilidade do que seria um componente acoplado com suas partes e um módulo completamente independente. Como citado na documentação legada:

In 2006, we started working on our first large projects: Yandex.Music and Ya.Ru. These projects, with dozens of pages, revealed the main drawbacks of the current approach to development:

Any changes to the code of one page affected the code of other pages.

It was difficult to choose classnames.

Tradução

Em 2006, começamos a trabalhar no nosso primeiro projeto grande: Yandex.Music e o Ya.Ru. Esses projetos que tinham dúzias de páginas se revelavam as desvantagens da atual abordagem de desenvolvimento:

Qualquer mudança no código de uma página afetaria as outras páginas.

Era difícil escolher como nomear as classes.

🔗 Relações de componentes complexos

Em 2010 quando o BEM se tornou open source e ganhou um site a ideia de que cada elemento de UI era um 'componente' já se fazia presente, mesmo antes do atomic design (Brad Frost, 2013) em resposta ao desafio de manter a consistência de componentes iguais em páginas diferentes. Na época da criação do BEM na Yandex, por exemplo, usavam vários arquivos HTML e apenas um arquivo de CSS e um de Javascript.

Se cada página fosse um bloco e seus elementos fossem dependentes do contexto dessa página, todo o código que fosse consistente entre páginas seria duplicado. Separar a UI em pequenos componentes permitia o reuso dessas partes independente de que páginas elas fossem utilizadas.

Pra exemplificar esse conceito de reuso, podemos usar um componente mais complexo, como de um header:

Esse header pode ser escrito da seguinte forma (HTML resumido):

<nav class="navbar">
  <div class="navbar__container">
    <a class="navbar__logo" href="#">Navbar</a>
    <button class="navbar__toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
      <span class="navbar__toggler-icon"></span>
    </button>
    <div class="navbar__collapse" id="navbarSupportedContent">
      <ul class="navbar__list">
        <li class="navbar__item">
          <a class="navbar__link active" aria-current="page" href="#">Home</a>
        </li>
        <!-- etc -->
        <li class="navbar__item navbar__dropdown">
          <a class="navbar__dropdown-toggle" href="#" role="button" data-bs-toggle="dropdown" aria-expanded="false">
            Dropdown
          </a>
          <ul class="navbar__dropdown-menu">
            <li>
              <a class="navbar__dropdown-item" href="#">
                Action
              </a>
            </li>
            <!-- etc -->
          </ul>
        </li>
        <!-- etc -->
      </ul>
      <form class="navbar__form" role="search">
        <input class="navbar__form-input" type="search" placeholder="Search" aria-label="Search">
        <button class="navbar__form-btn" type="submit">
          Search
        </button>
      </form>
    </div>
  </div>
</nav>

Perceba que nesse exemplo todo o navbar foi declarado como um grande bloco e tudo o que ele continha foi considerado element de navbar. Com isso, perdemos diversas oportunidades de reuso.

Oportunidade	Descrição
	O logotipo dentro de `.navbar__logo` é representado por um link contendo imagem ou texto. Existem diversos elementos que podem ser 'envelopados' em um link, como ícones back to top ou cards clicáveis. Esse código poderia pertencer a um bloco `.link` ou `.media`
	Os itens `.navbar__list` e `.navbar__item` nada mais são que uma lista desordenada no formato de linha ao invés de coluna. Isso poderia reutilizado representando-a pelo bloco `.list` com o modificador `.list--row`. O dropdown por sua vez pode ter o mesmo funcionamento fora do navbar, dentro do seu próprio bloco `.dropdown`, com seus elementos `.dropdown__toggle` e, como ele renderiza uma lista, podemos reutilizar `.list` e, se necessário, complementar com um modificador
	Esse componente de busca pode ser representado de forma mais "fechada" com um bloco `.search` e elementos `.search__input`, `search__label` e `.search__trigger` ou de forma mais "aberta" como `.form-field`, `.input--text`, `.label` e `.button--outline`

Ainda pensando nessa relação de componentes "abertos" e "fechados", podemos representar o componente de busca usado no último exemplo das duas forma usando CSS.

Componente de busca "fechado"
Os elementos input, label e button são acoplados ao bloco search, mudanças no componente ou no HTML de search influenciam nos seus elementos.

.search {}
  .search__input {}
  .search__label {}
  .search__button {}

Componente de busca "aberto"
Os elementos input, label e button são independentes do bloco de search, ele apenas organiza os blocos já existentes que compõe esse componente.

.form-field {}

.input {}
.input--text {}

.label {}

.button {}
.button--outline {}

🔗 Controle da especificidade com BEM

Um dos problemas citados pela galera do Yandex é que mudanças no CSS podiam afetar partes indesejadas. No caso deles era utilizada uma folha de estilo pra todas as páginas da aplicação, e você pode achar que não é um problema pra ti se você usa algum processador como Sass ou diversos arquivos de CSS, mas é uma dor de cabeça ainda maior quando seletores de diferentes abrangências moram em múltiplos arquivos.

A forma que o BEM encontrou de contornar esse problema além da modularização de blocos é a especificidade. BEM só utiliza classes por motivos bem claros:

Classes podem ser reaproveitadas
Como você se refere diretamente aos elementos usando as classes, a especificidade tende a ser sempre muito próxima de 0,1,0
Pra alterar ou sobrescrever uma regra, basta adicionar outra classe
Regras que se referem à seletores mais globais como de resets ou normalizers são facilmente sobrescritas pelas classes.

Abaixo vemos um accordion que mantém uma diversidade de seletores, pra nos referirmos, por exemplo ao h2 desse accordion, temos que explicitamente dizer #accordion-item > h2:

<div id="accordion-item">
  <h2>
    <button class="btn">
      Accordion Item #1
    </button>
  </h2>
  <div class="collapse show">
    <div>
      <strong>This is the first item's accordion body.</strong>
    </div>
  </div>
</div>

Pra estilizar todos os elementos desse componente, precisamos estabelecer as seguintes relações:

/* 1,0,0 */
#accordion-item {}

/* 1,0,1 */
#accordion-item > h2 {}

/* 1,1,0 */
#accordion-item .btn {}

/* 1,1,0 */
#accordion-item .collapse {}

/* 1,2,0 */
#accordion-item > .collapse.show {}

/* 1,1,1 */
#accordion-item > .collapse > div {}

/* 1,1,2 */
#accordion-item > .collapse strong {}

Esse exemplo assume que .collapse por não se referir diretamente ao accordion (não é um .accordion-collapse, por exemplo) pode existir em outros lugares do código ou até em outros lugares de #accordion-item. Isso obriga a gente a deixar explícita sua relação com #accordion-item.

A regra #accordion-item > .collapse > div existe pois o estilo não pode impactar qualquer div, nem qualquer .collapse, pra alterar apenas aquilo que existe dentro do bloco #accordion-item precisamos adicionar muito mais complexidade e especificidade, além de que qualquer mudança no HTML desse componente causa bugs imprevisíveis.

<div class="accordion-item">
  <h2 class="title">
    <button class="button">
      Accordion Item #1
    </button>
  </h2>
  <div class="accordion-item__collapse">
    <div class="accordion-item__wrapper">
      <strong>This is the first item's accordion body.</strong>
    </div>
  </div>
</div>

No HTML acima estabelecemos as relações entre o .accordion-item e o .accordion-item__collapse sem adicionar especificidade. Ao nos referirmos diretamente aos elementos pela classe e não compondo seletores, quando alteramos o .accordion-item podemos quebrar o .accordion-item__collapse, mas ao alterar .accordion-item__collapse, o .accordion-item dificilmente será influenciado.

.title e .button serem blocos independentes faz com que alterarmos o HTML desse componente ou o CSS dessas classes não cause nenhum bug, pois elas existem de forma independente do bloco do accordion. Em relação à especificidade, a relação passa a ser da seguinte forma:

/* 0,1,0 */
.accordion-item {}

/* 0,1,0 */
.accordion-item__collapse {}

/* 0,1,0 */
.accordion-item__wrapper {}

/* 0,1,0 */
.title {}

/* 0,1,0 */
.button {}

A especificidade dessas regras é muito mais previsível, tanto que se eu quiser adicionar uma variante ao .accordion-item__wrapper basta eu criar uma classe com as regras e incluir no elemento no HTML, sem precisar criar no CSS um seletor .accordion-item__wrapper.accordion-item__wrapper--vertical.

🔗 Reuso de CSS

Quando me refiro a reuso de CSS, não falo apenas de blocos que podem ser reaplicados em diferentes componentes, à nível de seletores, mas também à conjuntos de regras que realizam as mesmas ações. No exemplo abaixo, temos 3 componentes diferentes e mesmo se escritos na convenção do BEM haverá repetição de conjuntos de regras:

Elemento	Regras
	`.alert { display: flex; gap: 0.5rem; /* etc... */ }`
	`.nav { display: flex; gap: 1rem; /* etc... */ }`
	`.breadcrumb { display: flex; gap: 0.5rem; /* etc... */ }`

Percebe como todos os elementos que tem a disposição de 'linha' muito provavelmente terão um grupo de regras de display: flex o configura dessa forma, terão um gap: npx e provavelmente um flex-wrap: wrap quando fizer sentido pro layout 'quebrar' pra linha de baixo?

Usando o breadcrumb como exemplo, podemos criar um bloco que represente uma linha ou coluna genérica e que seja configurável à partir de variantes.

<ol class="breadcrumb">
  <li class="breadcrumb__item">Home</li>
  <li class="breadcrumb__item active">Library</li>
</ol>

Ao invés de repetir o conjunto de regras que configura uma coluna, podemos adicionar à classe .breadcrumb o bloco de .row. Não há restrições sobre o mesmo elemento ser representado por dois blocos distintos, pois o conceito de bloco é acoplado com seus elementos, não com componentes específicos.

/* Breadcrumb deixa de configurar o layout e passa apenas a implementar estilos estéticos */
.breadcrumb {
  font: 200 1rem Poppins;
  line-height: 1.45;
}

/* Row se torna responsável pelo layout */
.row {
  display: flex;
  gap: 1rem;
}

/* E pode ter variantes na convenção BEM caso conveniente */
.row--flexible {
  flex-wrap: wrap;
}

Nesse caso o gap de .row é estático, mas os elementos apresentados nos exemplos tem diferentes valores nessa propriedade, de quem é a responsabilidade? Se você possuí uma estrutura de CSS utilitário, a responsabilidade pode ser de .row que será configurada pelo CSS utilitário .gap-0.5 ou .gap-sm.

Se você não usa CSS utilitário, o gap pode ser configurado pelo próprio componente breadcrumb:


/* Ao implementar o gap com variáveis CSS temos um valor
default e um valor configurável */
.row {
  --row__gap-default: 1rem;
  display: flex;
  gap: var(--row__gap, var(--row__gap-default));
}

/* Dessa forma podemos configurar o gap pelo breadcrumb.
A row ainda não depende dele, mas caso ele seja aplicado com
uma row, ele a configura */
.breadcrumb {
  --row__gap: 0.5rem;
  font: 200 1rem Poppins;
  line-height: 1.45;
}

Separar os estilos de layout dos de aparência é uma prática do OOCSS (link do artigo na Smashing Magazine, em inglês). Categorizar o CSS em skin e structure vem do entendimento de que a estrutura e layout de um elemento ou componente é mais reaproveitável e ubíqua do que a aparência de um componente.

Usando a convenção BEM é possível criar blocos que se referem à estruturas e modificadores que se referem à aparência, sendo ela apenas uma convenção de escrita de classes, a categorização e separação dessas classes pode ficar na responsabilidade de outro tipo de arquitetura.

🔗 BEM e Sass

Sass foi criado em 2009, um ano antes de BEM se tornar open source, a interação entre eles funciona extremamente bem (rsrs) por dois motivos:

Sass permite a criação de múltiplas folhas de estilo e a co-locação dos estilos de acordo com as necessidades do projeto,logo podemos criar uma folha pra cada bloco ou conjunto de blocos que se referem a um componente ou contexto.
Sass tem suporte à concatenação de string, o que torna ainda mais visual a relação da classe com seus elementos e modificadores. Pensando no exemplo do bloco .search citado anteriormente:

.search {
  &__input {}
  &__label {}
  &__button {}
}

Com CSS a relação de blocos e elementos se dá pelo prefixo do bloco, ex: .search__, no Sass os elementos são declarados dentro do bloco.

Um problema muito comum com Sass é o 'overnesting', que é quando aninhamos múltiplas classes em um bloco. Essa abordagem além de dificultar a legibilidade do bloco cria especificidade sem necessidade e acopla os elementos ao bloco mais do que o necessário.

/* Esse tipo de nesting ao invés de gerar seletores  0,1,0 */
.search {
  .search__item {}

  .search__label {
    &.search__label--floating {

    }
  }
}

/* Gera o CSS */
/* 0.2.0 */
.search .search__item {}

/* 0.2.0 */
.search .search__label {}

/* 0.3.0 */
.search .search__label.search__label--floating {}

O overnesting geralmente acontece pelo não conhecimento de como o Sass funciona ou pela tentativa de imitar o formato do HTML no CSS.

🔗 Interações com outras arquiteturas

Como naming convention BEM é flexível quando nos apropriamos de outras arquiteturas ou apenas características delas. Como citado na documentação:

No matter what methodology you choose to use in your projects, you will benefit from the advantages of more structured CSS and UI. Some styles are less strict and more flexible, while others are easier to understand and adapt in a team.

Tradução

Não importa qual metodologia você use em seus projetos, vbocê vai se beneficiar das vantagens de uma UI e CSS mais estruturados. Alguns estilos são menos estritos e mais flexíveis, outros sãi fáceis de entender e adaptar em um time.

Podemos escrever as regras do tipo block do CUBECSS na convenção do BEM.

A diferença entre os blocos do CUBECSS e do BEM é o seu escopo, no CUBE há uma separação semântica entre estrutura, configuração e aparência. Após declarar a camada de Composition que defini layouts num nível mais macro (Como o object no OOCSS ou ITCSS) e criar classes utilitárias na camada de Utility, sobra pouca configuração a se fazer na cabada do Block, o deixando mais enxuto.

Podemos também criar as diversas camadas propostas pelo ITCSS e criar Objects, Components e Utilities na sintaxe do BEM. O ITCSS não define a forma que criamos modificadores e a relação dos componentes e seus estados/variantes, mas sim a taxonomia e localização dos elementos respeitando seu escopo e dando previsibilidade na sua especificidade e posição na cascata.

Podemos expressar as mesmas relações do SMACSS, por exemplo, declarando states quando esses alteram um módulo específico na sintaxe BEM:

/* Na convenção SMACSS */
.tab {
  background-color: purple;
  color: white;
}

.is-tab-active {
  background-color: white;
  color: black;
}

/* Na convenção BEM */
.tab {
  background-color: purple;
  color: white;
  &__is-active {
    background-color: white;
    color: black;
  }
}

States que não são específicos de um módulo podem ser declarados como classes utilitárias ou blocos independentes.

Há muitas outras formas de se escrever BEM, não necessariamente vinculadas a uma arquitetura, como no exemplo abaixo.

BEM com nesting nativo V2 - ainda mais poderoso 🔥

Camilo Micheletto ・ Jun 29

#css #webdev #braziliandevs #tutorial

Afinal, BEM é a melhor arquitetura de CSS?

Não existe 'melhor arquitetura'. Todas as metodologias já propostas são claras nos problemas que elas visam resolver, e elas não necessariamente vão resolver todos os problemas da sua organização, time ou codebase. BEM pode resolver seus problemas de acoplamento de classes e especificidade, mas talvez não resolva o de performance ou localização.

O interessante é aumentar seu gabarito de metodologias, convenções e arquiteturas e escolher sua ferramenta de acordo com os problemas que tu visa resolver.

BEM num contexto de aplicação Vue com SFC pode ser incrível quando localizamos o bloco CSS no mesmo lugar que o componente que ele estiliza, mas pode gerar muito CSS duplicado ou inutilizado se não houver uma arquitetura mais voltada pra reuso de estruturas, como OOCSS ou CUBECSS.

🔗 Fontes

Font-size no CSS, qual unidade usar?

Camilo Micheletto — Sun, 28 Jul 2024 01:24:48 +0000

Devemos usar em e px pois é o que está na spec da W3C ?
Devemos usar rem pq é o que tá na boca do povo ?
Devemos usar o que o coração mandar?

Provavelmente você já deve ter visto em algum artigo ou aula essa tabela da W3C, muitas pessoas se baseiam nela pra indicar em e px como unidades a se utilizar quando se trata de font-size no CSS. Por mais que seja da W3C, essa documentação é de janeiro de 2010, um ano antes da definição formal da unidade rem.

A unidade relativa

O que buscamos em uma unidade CSS pra texto é uma entre duas características:

Ela ser relativa à configuração do usuário
Ela ser relativa ao font-size

Ser relativo à é a definição de uma unidade que o valor não é fixo, mas calculado à partir das características do documento ou definições da pessoa usuária.

`rem` por exemplo, substitui a declaração de `font-size: 100%` no body e é relativa à configuração do usuário

rem, em, ch e ex são tamanhos relativos à configurações da fonte em diferentes formas.

`rem`

rem é relativo ao tamanho da fonte das configurações do seu navegador / OS

Você pode testar como cada unidade reage à mudança das configurações do navegador digitando chrome://settings na barra de busca

O rem ser relativo ao tamanho da fonte definida no :root (mesma instância do que html, só que com mais especificidade) permite que as fontes "reajam" a essas configurações, mas também permite criar elementos que precisam ser relativos à alterações de fonte pelo usuário ou OS. Nesse caso, px potencialmente irá escalar também, mas quais unidades escalam dependem da configuração e consistência de comportamento entre navegadores - desses, o rem tem um ótimo suporte pra zoom e escala de fonte pelo usuário.

Ainda tô em busca de estudos mais detalhados sobre isso, aceito indicações

`em`

em é relativo ao font-size do próprio elemento ou do elemento pai mais próximo. font-size é uma característica hereditária, logo se o elemento pai tiver 18px, o 1em do elemento filho será 18px. Isso pode diminuir a previsibilidade do font-size de elementos aninhados.

Pensando em um container com font-size de 32px que contém um botão com font-size de 1.5em



.button-container {
  font-size: 32px;
}

.button {
  font-size: 1.5em; /* 32 * 150% (ou 1.5) = 48px */
}

Como essa unidade tem uma relatividade contextual, é difícil prever quando o font-size de um container pai pode afetar a base do font-size do elemento filho.

Ser relativo ao font-size do elemento ou do pai pode ser útil pra casos em que o componente precisa reagir proporcionalmente ao tamanho da fonte, num botão por ex:

O padding pode ser proporcional à fonte
O width/height de um ícone (svg) pode ser proporcional à fonte

Usar em no padding pode ser potencialmente ruim pra acessibilidade pois pode aumentar de forma imprevisível o espaço entre os elementos em grande escala, como definir o font-size do navegador como "Large" ou aplicar um zoom de 200%.

No Codepen abaixo eu demonstro um botão em que seu padding "reage" ao tamanho da fonte. Ao editar pra usar rem o crescimento não proporcional na minha opinião é menos agradável aos olhos.

`ch`

ch é uma unidade relativa à largura do glifo (U+0030) do caractere '0' da familia de fonte do elemento. Uma unidade relativa à um glifo específico pode ser usada pra definir uma largura de um elemento baseado na sua quantidade estimada de caracteres.

A escala na foto representa a taxa de legibilidade de uma linha de texto pelo instituto [Baymard](https://baymard.com/blog/line-length-readability). Hoje é possível manter um texto nesses limites, inclusive usando `clamp(50ch, 100%, 75ch)` ou similares

`ex`

ex é relativo à altura do caractere x minúsculo
ex representa a altura do x da primeira família de fonte disponível no sistema pro elemento aplicado.
Tal como em ele leva em consideração a altura de um glifo e pode aumentar sua escala de forma mais precisa que em em alguns casos, como na Gecko/Mozilla.

Vale ressaltar que dessas unidades, a única que realmente se baseia na largura dos caracteres do tipo é ch, as restantes se basearão na altura.

Não existe "melhor"

O uso das unidades relativas diz menos sobre "o que é melhor" ou o "que é recomendado", mas sobre entender as relações com a interação do usuário, user-agent e layout e criar estratégias que computem com base nessas informações, layouts estáticos são valores pré-definidos, layouts responsivos são representados por equações de primeiro ou segundo grau em que precisamos definir as relações com base no resultado pretendido.

BEM with native nesting V2 - Even more powerful 🔥

Camilo Micheletto — Sat, 29 Jun 2024 02:04:54 +0000

Recently, WhatIsLove Dev wrote a fantastic article explaining how to write BEM modifiers in pure CSS, similar to Sass. In the example the technique consists in using attribute selectors and parent selectors to make the block + modifier relationship:



.tag-list__tag {
  --background-color: var(--color-red-200);

  padding-block: 2px;
  padding-inline: 6px;
  background-color: hsl(var(--background-color) / 30%);

  &[class*='--html'] {
    --background-color: var(--color-green-100);
  }

  &[class*='--github'] {
    --background-color: var(--color-gray-100);
  }

  &[class*='--ts'] {
    --background-color: var(--color-blue-200);
  }
}

To apply a modifier, declare the base and modifier classes on the same element:



<aside class="aside box">
  <span class="aside__border aside__border--top">
    <!-- omitido -->
  </span>
</aside>

I thought

"It would be sick if I could just write the modified class, right? After all, the prefix of the modifier class is the base class (block)."

Suffix and Prefix

The idea is simple: the suffix refers to the base class, and the prefix to its modifiers. The attribute selector supports string start and end searching, so just nest the suffix inside the prefix.

Given a class .card with modifiers .card--brand and .card--grey:



:where([class^="card"]) {
  &[class*="--grey"] {}
  &[class*="--brand"] {}
}

([class^="card"]) - Captures the element's prefix (block)
&[class="--grey"] - Captures the element's suffix (element/modifier)

XABLAU

Downsides of the Technique

Attribute selectors are costly in terms of performance because they perform a substring search through the element tree.
In addition to class name collisions, there will be suffix collisions as well, doubling the need for careful naming.

Check out this CodePen to play around:

BEM com nesting nativo V2 - ainda mais poderoso 🔥

Camilo Micheletto — Sat, 29 Jun 2024 01:44:18 +0000

Recentemente o WhatIsLove Dev escreveu um artigo muito massa explicando como escrever modificadores BEM de forma muito parecida com a que fazemos no Sass usando apenas CSS pur. Abaixo, exemplo extraído do seu próprio site.

.tag-list__tag {
  --background-color: var(--color-red-200);

  padding-block: 2px;
  padding-inline: 6px;
  background-color: hsl(var(--background-color) / 30%);

  &[class*='--html'] {
    --background-color: var(--color-green-100);
  }

  &[class*='--github'] {
    --background-color: var(--color-gray-100);
  }

  &[class*='--ts'] {
    --background-color: var(--color-blue-200);
  }
}

Pra aplicar o modificador basta declarar a classe base e a classe modificadora no mesmo elemento, típico:

<aside class="aside box">
  <span class="aside__border aside__border--top">
    <!-- omitido -->
  </span>
</aside>

Ai eu pensei:

Pô, massa, mas seria ainda mais legal se eu escrevesse só a classe modificada né? Afinal o prefixo da classe modifier é a classe base (block).

Pois bem.

Sufixo e prefixo

A ideia é simples: o sufixo vai se referir sempre à classe base, o prefixo aos seus modificadores. O attribute selector dá suporte à busca no início e no fim da string, logo basta fazer nesting do sufixo dentro do prefixo.

Dado uma classe .card que possuí os modificadores .card--brand e .card--grey.

:where([class^="card"]) {
  &[class*="--grey"] {}
  &[class*="--brand"] {}
}

:where([class^="card"]) - Captura o prefixo (block) do elemento
&[class*="--grey"] - Captura o sufixo (element / modifier) do elemento

XABLAU

Pontos negativos da técnica

O seletor de atributo é um seletor caro pra performance pois além de realizar a busca na árvore de elementos ele ainda faz uma comparação de substring
Além da colisão de nomes de classe, teremos colisão de sufixos também, ou seja, o dobro de cuidado na nomenclatura.

Enfim, codepen pra vocês brincarem:

🔥 4 dead simple ways of customizing Bootstrap

Camilo Micheletto — Tue, 05 Dec 2023 04:12:51 +0000

In this article, I'll demonstrate various techniques for customizing Bootstrap themes, whether for projects using only CSS or those utilizing Sass.

My project uses just HTML and CSS
- I'm using Bootstrap 5
- I'm using Bootstrap 4
- Using modern CSS
My project uses Sass
- I'm using Bootstrap 4 or 5
Could it be better

My project uses just HTML and CSS 🔗

And I used a <link> to include bootstrap.min.css in my HTML

I'm using Bootstrap 5 🔗

Bootstrap 5 uses CSS variables to style its components. The base variables are in :root, and the specific component ones are declared within them. For instance, .btn-primary:



.btn-primary {
  --bs-btn-color: #fff;
  --bs-btn-bg: #0d6efd;
  --bs-btn-border-color: #0d6efd;
  --bs-btn-hover-color: #fff;
  --bs-btn-hover-bg: #0b5ed7;
  --bs-btn-hover-border-color: #0a58ca;
  --bs-btn-focus-shadow-rgb: 49, 132, 253;
  --bs-btn-active-color: #fff;
  --bs-btn-active-bg: #0a58ca;
  --bs-btn-active-border-color: #0a53be;
  --bs-btn-active-shadow: inset 0 3px 5px rgba(0, 0, 0, 0.125);
  --bs-btn-disabled-color: #fff;
  --bs-btn-disabled-bg: #0d6efd;
  --bs-btn-disabled-border-color: #0d6efd;
}

You can create your own CSS variables representing the new colors of this theme. Despite being many variables, they follow a repetition pattern.

To do this, simply create a new style sheet just below the Bootstrap one. The CSS gives preference to the one loaded last:



<!-- Bootstrap stylesheet -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" />

<!-- Your stylesheet -->
<link rel="stylesheet" href="style.css" />

Then, adjust their values as desired, preferably using your default variables. This way, you can replicate them across other elements using the same theme.



.btn-primary {
  --bs-btn-color: var(--primary-text-base);
  --bs-btn-bg: var(--primary-bg-base);
  --bs-btn-border-color: var(--primary-border-base);
  --bs-btn-hover-color: var(--primary-text-base);
  /* ... etc ... */
}

I'm using Bootstrap 4 🔗

With pure CSS, you can utilize specificity to override class content. Bootstrap classes function as utility classes, without co-dependency, having a specificity of 0.0.1.0, allowing them to be overridden by another class declared later in the code.

💡 If specificity is still a mystery to you, I recommend this article on specificity and cascade by Amelia Wanttenberger.

Bootstrap classes have a base class containing properties common to their variants and another containing properties specific to their variants.

Example



.alert {
  position: relative;
  padding: 0.75rem 1.25rem;
  margin-bottom: 1rem;
  border: 1px solid transparent;
  border-radius: 0.25rem;
}

.alert-primary {
  color: #004085;
  background-color: #cce5ff;
  border-color: #b8daff;
}

Knowing this, you can create a class with a namespace, e.g., .custom-alert-primary, with styles overriding the .alert theme.

Example:



<div class="alert custom-alert-primary" role="alert">
  A simple primary alert—check it out!
</div>

◾Using modern CSS 🔗

We can utilize cascade layers to separate Bootstrap and CSS into different layers, giving more priority to the layer with authored code.

Below is an example by Stephanie Eckles using Bootstrap from Smashing Magazine:



@layer bootstrap, base, application;

@import url(bootstrap.css) layer(bootstrap);

@layer base {
  body {...}
  .alert {...}
  .btn-primary {...}
}

The priority using @layer is defined from left to right, from least to most priority, ensuring that your styles' specificity remains higher than Bootstrap's.

CSS Layers have a global compatibility of 93%, according to Caniuse data.

Chrome	Edge	Firefox	Safari
99	99	97	15.4

My project uses Sass 🔗

And I used @import "bootstrap" to set up Bootstrap

I'm using Bootstrap 4 or 5 🔗

The Customize → Variable Defaults chapter of Bootstrap 5 documentation shows that it's possible to redeclare configuration variables from the variables.scss file directly in your import file (usually index.scss). The procedure is similar for Bootstrap 4, but ensure you check your version's documentation for declared variables and their usage.



// Requerido
@import "../node_modules/bootstrap/scss/functions";

/* Sobrescreve os valores padrão das variáveis padrão */
$body-bg: #000;
$body-color: #111;

@import "../node_modules/bootstrap/scss/variables";
@import "../node_modules/bootstrap/scss/variables-dark";

/* Remove do objeto $theme-colors do arquivo
variables.scss as chaves de 'info', 'light' e 'dark' */
$theme-colors: map-remove($theme-colors, "info", "light", "dark");

@import "../node_modules/bootstrap/scss/maps";
@import "../node_modules/bootstrap/scss/mixins";
@import "../node_modules/bootstrap/scss/root";

// Componentes opcionais
@import "../node_modules/bootstrap/scss/reboot";
@import "../node_modules/bootstrap/scss/type";
// etc

For customization, variables declared in the Bootstrap source code are marked with the !default flag. This means that if you declare a Bootstrap variable before variables.scss, it won't be overwritten, keeping your alteration as the default value.

The !default flag allows a variable to be created only if it doesn't exist yet. For more details, refer to the Sass documentation on default values.

Could it be better 🔗

Wow, but is it more work than Tailwind!?

Yes, definitely, but they serve different purposes. Bootstrap is used by 21% of sites surveyed by W3Techs, with over 6 million weekly downloads, according to npm's website. Since its inception in 2011, Bootstrap has been fundamental in setting standards and concepts that changed the way we do front-end today.

Being found in pure HTML/CSS sites, WordPress pages in PHP, or SPAs built with modern frameworks, Bootstrap's framework development focus was on retro-compatibility and robustness.

Incorporating a compilation step as Tailwind does with PostCSS wouldn't be feasible, as it would make the project dependent on a build tool like Webpack, Rollup, or even Vite in every project, which isn't always necessary.

Another point is that despite using JavaScript, if its functionalities aren't needed, it's extremely opt-in, allowing Bootstrap to be used independently of technologies, even in pure HTML/CSS projects.

3 mentiras que te contaram sobre quando usar as unidades em, rem ou px no CSS 🤬

Camilo Micheletto — Tue, 05 Dec 2023 03:53:50 +0000

Artigos sobre o tema são abundantes, mas desinformação sobre ele também é, e ela vem sido indiscriminadamente reproduzida. Meias verdades, equívocos e explicações rasas podem significar retrocessos pro desenvolvimento pessoal, mas também pra aplicações em produção.

Sumário

rem é mais acessível
rem é melhor que em
px e outras unidades absolutas são ruins
Referências

`rem` é mais acessível 🔗

TL;DR - pra tamanho de fontes é mesmo, já pra outras coisas...

rem ou root font-size é relativa ao tamanho de fonte base da folha de estilos do user-agent que geralmente é 16px porém depende do dispositivo:

Dispositivo / Navegador	font-size padrão
Opera Mini 4.5	13px
Palm webOS 2.0 & webOS TouchPad	14px
Opera Mini 7	17px
AOL 9	20px
Cybook Odyssey (leitor de e-book)	21px
Blackberry 6.0	22px
NetFront NX	23px
Kindle 3*	26px

Tabela transcrita e traduzida do artigo "People don't change the default 16px font size in their browser (You wish!)" do Nicolas Hoizey.

Vemos por ai diversas postagens que vão se resumir a dizer que rem é uma unidade responsiva - o que não só é mentira, como leva as pessoas a fazerem coisas assim:

@media (max-width: 42rem) {
  /* resto do código */
}

Isso cria uma media query que reage à largura do site relativa ao tamanho da fonte do user-agent. Isso significa que quando a pessoa usuária mudar a configuração de fonte do navegador pra poder enxergar melhor os textos (e elas mudam)

O breakpoint que você esperava que fosse 672px (42 * 16), agora só é ativado quando a tela tiver 840px de largura. Algumas pessoas defendem que esse comportamento é o ideal, trazendo uma grande perca de previsibilidade na declaração dos breakpoints.

Na dúvida:

Esse valor deve aumentar à medida que o usuário aumenta o tamanho da fonte padrão do navegador? Esta questão é a raiz do modelo mental que utilizo. Se o valor aumentar com o tamanho da fonte padrão, eu uso rem. Caso contrário, eu uso px. - The Surprising Truth About Pixels and Accessibility - Josh W. Comeau

💡 A tradução foi escrita pelo André Menezes (deMenezes) nesse artigo que recomendo demais se você quiser ler outro take sobre esse mesmo tópico.

Valores absolutos e relativos em CSS: quando usar px, % e rem

deMenezes ・ Jul 12 '22

#valor #absoluto #relativo #css

`rem` é melhor que `em` 🔗

TL;DR - em tem seus próprios casos de uso que rem não conseguiria substituir

Sempre desconfiem de afirmações como "x coisa é melhor que y", geralmente elas partem de um ponto de vista limitado ou pessoal e contribuem em nada pra com quem lê.

O em é relativo ao font-size do pai quando utilizado no font-size e relativo ao font-size dele mesmo quando utilizado em outros lugares como height e width. Se utilizado indiscriminadamente pode causar problemas indesejados com elementos aninhados:

<p style="font-size: 10px">
  <!-- font-size === 15px -->
  <span style="font-size: 1.5em">
    Teste 1.5em
    <!-- font-size === 30px -->
    <span style="font-size: 2em">
      Teste 1.5em
    </span>
  </span>
</p>

📖 Esse artigo (apesar de eu não concordar com a conclusão que ele chega) explica de uma forma bem simples porquê o em existe, que problemas ele resolvia e o que motivou a criação do rem- R.I.P. REM, Viva CSS Reference Pixel! por Gion Kunz, em inglês

Porém o modelo mental que mais favorece o uso do em é usá-lo quando você precisa que algo cresça junto com o tamanho da fonte. No caso de uso abaixo, quando você aumenta o font-size do botão, o padding aumenta proporcionalmente, permitindo que o botão permaneça com o mesmo aspecto independente do tamanho. O mesmo funciona com ícones, gaps e coisas similares.

`px` e outras unidades absolutas são ruins 🔗

TL;DR - skill issue

Ou "evite usar pixeis" - mas evite onde exatamente? Com pouco direcionamento do que fazer, acabamos por chutar unidades CSS sem testar ela em diferentes casos de uso, fazendo nosso layout quebrar de maneiras inimagináveis.

px são incríveis pra definir limites, pois na maioria das vezes não faz sentido o limite de algo ser relativo. Com breakpoints, max-width, min-height e outros similares.

Outro uso é definir o tamanho de coisas que não vão mudar com o contexto, como o caso de alguns border-radius ou box-shadow. Se não faz sentido aquela propriedade ser relativa a algo, não a faça relativa.

Se vai ter algo como regra, tenha não chutar. Cada coisa tem seu caso de uso, fazer de forma consciente significa também testar de forma consciente e garantir a qualidade da aplicação.

Acessibilidade é importante e nenhuma DX vale abrir mão dela. Se seu produto só pode ser usado por algumas pessoas, ou ele não está pronto, ou é só um produto ruim.

Referências 🔗

People don't change the default 16px font size in their browser (You wish!) por Nicolas Hoizey (em inglês)
Esse artigo busca sanar aquele pensamento de que não tem problema se declarar fontes com px pois a pessoa usuária média não redimensiona a fonte.

Responsive Type and Zoom por Adrian Roseli (em inglês)
Esse artigo explica como o uso de técnicas de tipografia responsiva pode ser ruim pra acessibilidade.

Addressing Accessibility Concerns With Using Fluid Type por Maxwell Barvian (em inglês)
Já esse artigo aborda a matemática por detrás da tipografia fluida e te ensina a acertar em uma que seja acessível.

PX, EM or REM Media Queries? por Zell Liew (em inglês)
Defende a opinião de que em e rem são boas unidades em media queries e que o "delay" que mexer no root font-size causa é uma feature e não um bug.

The Surprising Truth About Pixels and Accessibility por Josh Comeau (em inglês)
Esse artigo trás uma visão mais lúcida sobre as qualidades do pixel e quando e onde usá-lo.

JSBin de teste de REM
Possibilita visualizar como um container em px e outro em rem se comportam quando o usuário muda o font-size.

WCAG - Technique C14
Técnica suficiente em relação ao critério de sucesso 1.4.4 - Resize text.

R.I.P. REM, Viva CSS Reference Pixel! por Gion Kunz (em inglês)
Explica sobre reference pixel, a história do em e do rem e trás uma visão interessante (que eu não concordo) do uso do pixel.

Valores absolutos e relativos em CSS: quando usar px, % e rem por André Menezes
Uma visão super bacana do uso dessas três propriedades.

Use variáveis CSS como uma pessoa sênior com essas 5 dicas 🔥

Camilo Micheletto — Thu, 23 Nov 2023 04:58:54 +0000

Sumário

101
Design tokens
Composição de variáveis
Blocos enxutos
Variáveis como props
Variáveis privadas
Materiais de estudo

101 🔗

Repetição é bem comum no CSS, ainda mais em fontes, cores e espaçamentos. Repetição nem sempre é desperdício, se a gente quer ser consistente com o nosso design, repetição favorece a percepção de padronização das pessoas usuárias. No caso abaixo, temos um timing de transição padrão pras animações dos componentes:

.btn {
  transition: background 200ms ease-in;
}

.link {
  transition: color 200ms ease-in;
}

Pra garantir a acessibilidade, temos que possibilitar que usuários que se distraem com animações ou possuem algum tipo de sensibilidade à movimento possam desativá-los via configuração do user-agent, que no caso é o navegador:

.btn {
  transition: background 200ms ease-in;
}

@media (prefers-reduced-motion: reduce) {
  .btn {
    transition: background linear;
  }
}

Nesse caso, pra cada classe que tivesse esse timing teríamos que criar também dentro da @media pra que a pessoa usuária conseguisse mudar. E se além disso mudarmos o tema pra escuro? Teríamos que colocar todas as classes com cores dentro da @media (prefers-color-scheme: dark)?

Com variáveis CSS poderíamos fazer diferente!
Primeiro guardamos a nossa configuração de timing e easing num local que ela ficasse disponível "globalmente". Geralmente usamos :root {} que é um equivalente à html {}, mas que possuí ainda mais precedência.

:root {
  --timing: 200ms ease-in;
}

E ai podemos atualizar todas referências desse valor no código usando a função var()

.btn {
  transition: background var(--timing);
}

.link {
  transition: color var(--timing);
}

Só isso já nos daria a vantagem de, se caso for necessária a mudança de valor dessa propriedade, mudarmos em um lugar só, mas o pulo do gato não chegou ainda, se liga:

:root {
  --timing: 200ms ease-in;
  @media (prefers-reduced-motion: reduce) {
    --timing: linear;
  }
}

Se a media condition (prefers-reduced-motion: reduce) retornar true, como a variável --timing: linear foi redeclarada depois, ela vai sobrescrever a declaração --timing: 200ms ease-in;. Percebe que não só economizamos linhas de CSS com isso, mas colocamos dentro do mesmo bloco toda a lógica desse comportamento?

Design tokens 🔗

Design tokens são os átomos que compõe os componentes de uma aplicação. Um botão por exemplo é feito com um tamanho de fonte específica, cores próprias e que reagem às mudanças de estado, bordas que seguem esses padrões de cores, um padding padrão nas bordas e um gap representando um gutter em botões que também tem ícones. Todas essas configurações podem ser consistentes em outros componentes e podem ser pré-estabelecidas e guardadas em variáveis - tokens.

Um exemplo do uso de tokens é a criação de um padrão de cores a ser usada numa aplicação. Usando variáveis CSS além de defini-las com um nome apropriado, deixando elas fáceis de reproduzir, mudar e manter, podemos altera elas facilmente em diferentes condições, como a mudança pra um tema escuro.

Abaixo um exemplo do framework de variáveis CSS OpenProps usando variáveis CSS e media features pra implementar um modo escuro.

No exemplo acima foi colocado o seletor :root dentro de uma media query com prefers-color-scheme: dark. Com isso, se a media condition for true, o :root contendo as variáveis com o tema escuro irá sobrescrever o anterior contendo o tema claro padrão.

Podemos criar múltiplos temas em componentes usando o mesmo sistema:


.button {
  color: var(--btn-text, #1A1A1A);
  background: var(--btn-bg, #FAFAFA);
}

.button[danger] {
  --btn-text: #FAFAFA;
  --btn-bg: #FF0000;
}

No HTML:

<div>
  <button class="button">Tema claro</button>
  <button class="button" danger>Tema vermelho</button>
</div>

Mas e se eu quisesse alterar um tema? Pra um elemento como um alert ou callout seria interessante adicionar um pouco de opacidade à cor de fundo, mas só isso. Como você faria?

TailwindCSS resolveu isso com composição de variáveis.

Composição de variáveis 🔗

No artigo Composing the Uncomposable with CSS Variables de Adam Wathan, o criador do TailwindCSS ele aborda justamente essa questão.

TailwindCSS é um plugin de PostCSS que gera classes utilitárias on-demand à partir de um Design System. Possuindo um DS, ele também possui os tokens que eu estava falando no tópico anterior:

Vamos supor que você aplica a classe .text-blue-300 que deixa a cor do texto num tom de azul e, ao mesmo tempo, aplica a classe .text-opacity-50 que deixa a cor do texto com opacidade de 50%.

A solução de Watham foi criar uma função de cor e no argumento de opacidade incluir uma variável CSS ao invés de um valor. Dessa forma, se .text-opacity- tivesse no mesmo escopo que uma classe de cor, ela "injetaria" a variável que ela contém na classe.

Abaixo, o exemplo do artigo citado acima em que a classe de opacidade "injeta" o valor de --text-opacity quando usada em um elemento junto com a classe de cor:

.text-blue-300 {
  --text-opacity: 1;
  color: rgba(144, 205, 244, var(--text-opacity));
}

.text-opacity-50 {
  --text-opacity: 0.5;
}

Classes aplicadas ao mesmo elemento estão sob o mesmo escopo, ou seja, elas podem influenciar umas as outras através de variáveis CSS:

Dito isso, será que é possível criar diversas variantes de um componente apenas injetando variáveis neles com classes modificadoras?

É. Bootstrap 5 fez isso com maestria.

Blocos enxutos 🔗

O componente de botão do Bootstrap possui 9 variantes, sendo uma delas um link, como eles fazem?

Esse é o código fonte do bootstrap/dist/css/bootstrap.css. Algumas propriedades foram omitidas por brevidade:

.btn {
  --bs-btn-padding-x: 0.75rem;
  --bs-btn-padding-y: 0.375rem;
  --bs-btn-font-family: ;
  --bs-btn-font-size: 1rem;
  --bs-btn-font-weight: 400;
  --bs-btn-line-height: 1.5;
  --bs-btn-color: var(--bs-body-color);
  --bs-btn-bg: transparent;
  --bs-btn-border-width: var(--bs-border-width);
  --bs-btn-border-color: transparent;
  --bs-btn-border-radius: var(--bs-border-radius);
  --bs-btn-hover-border-color: transparent;
  --bs-btn-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.15), 0 1px 1px rgba(0, 0, 0, 0.075);
  --bs-btn-disabled-opacity: 0.65;
  --bs-btn-focus-box-shadow: 0 0 0 0.25rem rgba(var(--bs-btn-focus-shadow-rgb), .5);

  display: inline-block;
  padding: var(--bs-btn-padding-y) var(--bs-btn-padding-x);
  font-family: var(--bs-btn-font-family);
  font-size: var(--bs-btn-font-size);
  font-weight: var(--bs-btn-font-weight);
  line-height: var(--bs-btn-line-height);
  color: var(--bs-btn-color);
  border: var(--bs-btn-border-width) solid var(--bs-btn-border-color);
  border-radius: var(--bs-btn-border-radius);
  background-color: var(--bs-btn-bg)
}

No código acima, percebemos que:

São definidos valores padrão dentro do escopo do componente, inclusive valores que referenciam outras variáveis, dessa forma evitando a repetição de tokens com diferentes nomenclaturas, possibilitando uma referência cruzada.
Embaixo são definidas as propriedades consumindo desses tokens.

Agora vamos ver a composição da variante .btn-primary:

.btn-primary {
  --bs-btn-color: #fff;
  --bs-btn-bg: #0d6efd;
  --bs-btn-border-color: #0d6efd;
  --bs-btn-hover-color: #fff;
  --bs-btn-hover-bg: #0b5ed7;
  --bs-btn-hover-border-color: #0a58ca;
  --bs-btn-focus-shadow-rgb: 49, 132, 253;
  --bs-btn-active-color: #fff;
  --bs-btn-active-bg: #0a58ca;
  --bs-btn-active-border-color: #0a53be;
  --bs-btn-active-shadow: inset 0 3px 5px rgba(0, 0, 0, 0.125);
  --bs-btn-disabled-color: #fff;
  --bs-btn-disabled-bg: #0d6efd;
  --bs-btn-disabled-border-color: #0d6efd;
}

Só tem variáveis CSS.

Através da especificidade a variante altera os valores sem adicionar ou redeclarar nenhuma propriedade, de forma extremamente enxuta (DRY).

Agora, o que você faria se precisasse entregar um layout como o abaixo?

Usando essa mesma estratégia, criamos uma classe .card em que background-color recebe uma variável e pra cada nth-child(n)a gente muda a cor da variável:

.card {
  height: var(--size); width: var(--size);
  background-color: var(--color, gray);
  border-radius: 8px;
}

.card:nth-child(1) { --color: maroon; }
.card:nth-child(2) { --color: red; }
.card:nth-child(3) { --color: purple; }
.card:nth-child(4) { --color: fuchsia; }
.card:nth-child(5) { --color: green; }
.card:nth-child(6) { --color: lime; }
.card:nth-child(7) { --color: yellow; }
.card:nth-child(8) { --color: navy; }
.card:nth-child(9) { --color: blue; }
.card:nth-child(10) { --color: aqua; }

Mas se forem 20 cards, 30 cards? O CSS vai ficar enorme né? Se pelo menos tivesse como a gente passar as cores pelo elemento, como as props no React.

😈 e se eu te disser que tem como?

Variáveis como props 🔗

Diferente das outras estratégias, essa começa na marcação. Mantemos o código da variável .card, mas mudamos como inserimos o valor da cor:


<li class="card" style="--color: tomato"></li>

CSS inline. Podem rir de mim, fãs de Tailwind.

O conceito "parece" ruim, mas não é. Primeiro que diferente de inserir declarações de CSS (propriedade e valor), sobrescrevendo o CSS local, não sobrescrevemos ou adicionamos nada no CSS do elemento, apenas valores. Dessa forma mantemos a mesma integridade do CSS da folha de estilos, ainda com um ganho de especificidade da declaração inline.

Outro ponto é que em linguagens de templating como JSX ou afins, podemos literalmente alterar os estilos de forma lógica sem, muitas vezes, a necessidade de uma solução CSS-in-JS:

Qual a diferença disso...

<Contact color="darkgreen" />

Pra isso...

<div class="contact" style="--color: darkgreen">
  <!-- ... -->
</div>

Ou até mesmo isso...?

<div class="contact" style={{ '--color': contact.color }}>
  <!-- ... -->
</div>

Off-topic → É possível usar HTML da mesma forma que usamos props em Styled Components

O que te impede de fazer isso?

<button variant="primary" dark>Follow for more!</button>

E isso aqui?

button[variant=primary] {
   background-color: var(--background, red);
   color: var(--background, black);

   &[dark] {
      --background: darkred;
      --color: white;
   }
}

Não use se você precisar ter um código W3C compliant
'&' é CSS válido, viu?

Vamos supor que ao invés de um botão completamente limpo quiséssemos que a classe base .btn começasse com estilos padrão. Pra isso, podemos usar o segundo parâmetro da função var(), que serve como fallback caso a variável inicial não esteja declarada.

O problema dessa abordagem é que em variantes e outros estados precisamos sempre preencher com um valor padrão caso --background ou --color nunca sejam declarados:

.btn {
   background: var(--background, #FAFAFA);
   color: var(--color, #1A1A1A);
}

.btn:focus {
  outline: 1px solid var(--background, #FAFAFA);
}

Existe forma melhor de fazer isso? A membro da W3C e convidada do CSS Working Group Lea Verou veio com uma abordagem muito boa sobre.

Variáveis privadas 🔗

Algumas alternativas pro problema de redeclaração de parâmetros de fallback em variáveis CSS seriam:

1 - Declaração de fallback no escopo do componente

.btn {
   --background: #FAFAFA;
   --color: #1A1A1A;
   background: var(--background);
   color: var(--color);
}

.btn:focus {
   --background: #FAFAFA;
  outline: 1px solid var(--background);
}

Funcional, porém impede o componente de herdar --colorde um elemento pai, somente através de especificidade, o que pode se tornar difícil de gerenciar pra seletores muito complexos.

2 - Criação de uma variável de fallback usando o parâmetro default do var()

.btn {
   --background-initial: #FAFAFA;
   --color-initial: #1A1A1A;
   background: var(--background, var(--background-initial));
   color: var(--color, var(--color-initial));
}

.btn:focus {
   --background-initial: #FAFAFA;
  outline: 1px solid var(--background, var(--background-initial));
}

Nessa implementação conseguimos herdar a propriedade --background e --color do elemento pai, mesmo sem uma especificidade superior, porém é bem verbosa né?

A Lea Verou cunhou o conceito de pseudo private custom properties, que funcionam similarmente à variáveis privadas em linguagens de programação (vide o sublinhado --_ no nome.

Nesse conceito criamos uma variável de fallback como anteriormente, mas diferente dessa ela terá o próprio valor padrão:

.btn {
   --_background: var(--background, #FAFAFA);
   --_color: var(--color, #1A1A1A);
   background: var(--background);
   color: var(--color);
}

.btn:focus {
  outline: 1px solid var(--_background);
}

Dessa forma conseguimos:

Herdar as propriedades --background e --color.
Definir um fallback pra cada propriedade.
Fazê-lo de forma muito menos verbosa.

Todas essas estratégias me ajudaram a pensar e escrever CSS de forma muito mais enxuta e criativa, permitindo com que eu criasse layouts complexos com uma carga cognitiva menor e de forma mais extensível e customizável.

Um exemplo é esse bento layout responsivo com apenas 43 linhas de CSS:

Não sabe o que é um bento layout? Tá na mão.

Bento Grid layout responsivo em 40 linhas de CSS🥢 🍱

Camilo Micheletto ・ Nov 17 '23

#css #tutorial #webdev #codenewbie

Materiais de estudo 🔗

Composing the Uncomposable With CSS Variables - Adam Watham - artigo, em inglês
Custom properties with defaults - Lea Verou - artigo, em inglês
Using CSS custom properties like this is a waste - Kevin Powell - vídeo, em inglês
Bootstrap custom properites - Bootstrap Documentation - artigo, em inglês
Getting started with CSS Custom Properties - Andy Bell - artigo, em inglês
Variáveis CSS, um guia prático - Tárcio Zemel - artigo, em português

Bento Grid layout responsivo em 40 linhas de CSS🥢 🍱

Camilo Micheletto — Fri, 17 Nov 2023 14:56:35 +0000

Bento grid é uma forma de organizar a UI em pequenas caixas ocupando quantidades diferentes de células, na horizontal, vertical ou ambas, de acordo com o conteúdo.

Nesse artigo vamos fazer desenhar o layout de 2023 do Apple Watch Ultra que eu peguei do bentogrids.com. Faremos de forma crítica, e que fique fácil implementar os conceitos em qualquer tipo de bento.

Sumário

O conceito
Planejando a implementação do grid
Definindo as colunas
Definindo as linhas
Agora sim, o CSS
Código fonte no Codepen
Fontes e recursos

O conceito 🔗

Diferente de layouts baseados em cards, a área e posição de cada célula define uma ilha de funcionalidade.

Dessa forma é possível brincar com a hierarquia visual - no exemplo abaixo é possível enxergar um agrupamento natural entre itens que possuem layout compatível, mesmo ocupando espaços e posições diferentes.

Grid	Legibilidade

Fez sentido?

Planejando a implementação do grid 🔗

A construção do grid começa na ordem de leitura, que impacta completamente a construção do layout mobile. Temos duas opções pra esse layout ao meu ver:

Layout de 3 colunas
Layout denso

Pra esse exemplo pensaremos esse layout como o de 3 colunas.

No layout de 3 colunas a ordem de leitura parte da experiência de leitura mobile dos itens, empilhando as colunas de conteúdo.

Na minha opinião isso faz sentido pois olhando pra cada elemento individualmente não é possível estabelecer uma hierarquia clara.

Definindo as colunas 🔗

E como pensar as colunas do grid? Pegue lápis e papel e desenhe áreas ao redor dos itens tentando agrupá-los. Lembre-se que tem itens que podem ocupar mais de uma coluna, no exemplo abaixo, no layout à direita (em roxo) foram criadas 3 colunas - percebe como a coluna menor que fica no meio serve como uma coluna auxiliar pra elementos ocupem um espaço diferenciado no layout?

fr é uma ferramenta poderosíssima nesse caso. Se eu colocar as colunas menores dentro da maior, podemos ver que elas ocupam 1/3 e 2/3 dela, respectivamente.

Logo, nesse layout, as colunas podem ser expressas por:

Unidade	Coluna 1	Coluna 2	Coluna 3
Fração	3/6	1/6	2/6
Proporção	3fr	1fr	2fr

As outras colunas seguem proporções similares, veja como fica quando a gente agrupa as colunas por tamanho:

Definindo as linhas 🔗

Sobre as linhas, temos algumas opções.
Podemos tratar cada grid individualmente ou usar o mesmo layout de linhas pra todos.

Individualmente	Geral

💡 Viram que nem mostrei nada de código ainda?
Se você fizer esse layout sem pensar, você vai escrever pelo menos 3x mais CSS ou mais containers no HTML.

Não por acaso, as linhas seguem a mesma lógica de proporção que as colunas.

As pessoas designers também usam grid, mas no handoff deles não vem em proporção, vem em px. Se você se ater ao conceito de "pixel perfect" vai encher seu layout de media query e ele ainda vai quebrar em viewports específicos. Se quiser saber mais sobre essa visão de media query e pixel perfect, escrevi um artigo bacana sobre:

Responsividade CSS 101 - Breakpoints

Camilo Micheletto ・ Oct 3 '23

#css #webdev #braziliandevs

Agora sim, o CSS 🔗

Cê já tava achando que não ia ter código né?



.bento {
  min-block-size: 100vh;
  display: flex;
  flex-wrap: wrap;
  gap: 1ch;
  padding: 1ch;
}

Primeiro o container. Optei por flex pois só ele é capaz de alterar a quantidade de "colunas" que um elemento ocupa sem o uso de uma media query.

min-block-size: 100vh vai garantir que independente do viewport as colunas mantenham seu aspecto de "tela inteira".



.bento__container {
  display: grid;
  grid-template-rows: 3fr 1fr 1fr 2fr 2fr 3fr;
  gap: 1ch;
  min-height: inherit;
  flex: 2 0 320px;
}

Lembra que eu falei que dava pra usar as mesmas linhas pra todos os grids? Foi o que eu fiz.

O min-height: inherit; herda o 100vh do pai, fazendo com que no mobile cada coluna ocupe a tela toda verticalmente.

O flex-grow: 2; faz com que as colunas cresçam pra caber, já que sem o flex-grow, no primeiro wrap a coluna ia se manter da largura do flex-basis: 320px.

📝 No código usei o shorthand flex que é, na ordem, flex-grow, flex-shrink e flex-basis. O flex-grow define uma taxa de crescimento pros flex-items, como quero que ao quebrar pra linha de baixo a coluna ocupe toda a largura, ele é perfeito. O flex-basis: 320px faz com que nenhuma coluna .bento-container fique menor que 320px.



.bento__container[variant-1] {
  --bg: #837AED;
  grid-template-columns: 3fr 1fr 2fr;
}

.bento__container[variant-2] {
  --bg: #F272AC;
  grid-template-columns: 2fr 3fr 1fr 2fr;
}

.bento__container[variant-3] {
  --bg: #72F286;
  grid-template-columns: 1fr 1fr;
}

Criei uma classe variante pra aplicar um esquema de colunas pra cada coluna e um background diferente também.

O variant-1 é um atributo que coloquei diretamente no HTML, isso é CSS válido. É HTML válido? Se você quiser um adesivo da W3C não é não lkkkkkkkkkkk, mas esse é o único problema dessa abordagem.



.bento__item {
  height: 100%; width: 100%;
  grid-column: var(--columns, span 1);
  grid-row: var(--rows, span 1);
  background-color: var(--bg);
  border-radius: 1rem;
}

Cada item tá recebendo a linha e a coluna via variável, porque?

Pra não ficar escrevendo milhares de nth-child eu vou injetar essas informações via variável CSS diretamente no template.

Como as variáveis são escopadas no elemento, você pode as colocar na tag style sem medo de aumentar a especificidade.



<main class="bento">
  <div class="bento__container" variant-1>
    <div class="bento__item" style="--rows: span 2; --columns: 1 / -1;"></div>
    <div class="bento__item" style="--rows: span 2;"></div>
    <div class="bento__item" style="--rows: span 2; --columns: span 2;"></div>
    <div class="bento__item" style="--columns: 1 / -1;"></div>
    <div class="bento__item" style="--columns: span 2;"></div>
    <div class="bento__item"></div>
  </div>
  <div class="bento__container" variant-2>
    <div class="bento__item" style="--columns: span 2;"></div>
    <div class="bento__item" style="--columns: span 2;"></div>
    <div class="bento__item" style="--rows: span 4; --columns: 1 / -1"></div>
    <div class="bento__item"></div>
    <div class="bento__item" style="--columns: span 2;"></div>
    <div class="bento__item"></div>
  </div>
  <div class="bento__container" variant-3>
    <div class="bento__item" style="--rows: span 2; --columns: 1 / -1;"></div>
    <div class="bento__item" style="--rows: span 2;"></div>
    <div class="bento__item" style="--rows: span 2;"></div>
    <div class="bento__item" style="--columns: 1 / -1;"></div>
    <div class="bento__item" style="--columns: 1 / -1;"></div>
  </div>
</main>

🤔 Percebe como isso é quase que equivalente a uma "prop" em frameworks JS?

Código fonte no Codepen 🔗

Fim do post e codepenzinho, sintam-se livres pra fuçar, fazer forks e elaborar melhor o layout.

Dá pra pensar esse layout de outras formas também, sem separar em 3 colunas ou agrupando em mais <div> no HTML.

Como você faria?

Fontes e recursos 🔗

Recomendo demais o site do bentogrids como inspiração - Link externo, em inglês
O serviço bento.me é uma ótima fonte de inspiração também, além de possibilitar agregar seus links de forma lindíssima (não é publi, mas podia), recomendado pela Mikele Guedes lá no Twitter ✨ - Link externo, em inglês

DEV Community: Camilo Micheletto

HTML básico para estudantes de TI

Sites e documentos

A sintaxe

Semântica

Acho que podemos deixar o mobile first em 2024

Responsividade e o mobile first

Os não tão novos breakpoints

Qual o melhor jeito?

Allyhere / expert-css

Repositório contendo materiais de estudo de CSS avançado

Expert CSS

Artigos sobre CSS que explodiram minha cabeça em 2024

Cyclomatic Complexity: Logic in CSS de Harry Roberts

Conditional CSS por Ahmad Shadeed

The CSS Cascade por Amelia Wattenberger

A Brief History of CSS-in-JS: How We Got Here and Where We're Going por Dan Ward

CSS and the critical path por Stoyan Stefanov

Responsive Web Design

The future of loading CSS por Jake Archibald

5 dicas de design de um front-end pra UI Designers

1º Dica - Entre um breakpoint e outro, sempre manipule os elementos proporcionalmente

2º Dica - Existem definições de acessibilidade pra textos, evite tomar essas decisões por estética

Designing in the 8pt grid system. In this article, I have shared a mobile… | by Zack MacTavish | Bootcamp | Medium

Zack MacTavish ・ Aug 14, 2022 ・ Medium

3º Dica - Não nomeiem seus tokens de forma arbitrária

4ª Dica - Evitem criar experiências de leitura diferentes do desktop pro mobile

5ª Dica - Texto alternativo e contraste é problema de designer também

Tudo o que você precisa saber sobre a arquitetura BEM CSS

🔗 Pra que serve uma arquitetura CSS?

🔗 O que é o BEM CSS?

🔗 Categorizando elementos da UI de acordo com seu acoplamento

🔗 Expressando a relação dos componentes através do CSS

🔗 Relações de componentes complexos

🔗 Controle da especificidade com BEM

🔗 Reuso de CSS

🔗 BEM e Sass

🔗 Interações com outras arquiteturas

BEM com nesting nativo V2 - ainda mais poderoso 🔥

Camilo Micheletto ・ Jun 29

Afinal, BEM é a melhor arquitetura de CSS?

🔗 Fontes

Font-size no CSS, qual unidade usar?

A unidade relativa

rem

em

ch

ex

Não existe "melhor"

BEM with native nesting V2 - Even more powerful 🔥

Suffix and Prefix

Downsides of the Technique

BEM com nesting nativo V2 - ainda mais poderoso 🔥

Sufixo e prefixo

Pontos negativos da técnica

🔥 4 dead simple ways of customizing Bootstrap

Table of Contents

My project uses just HTML and CSS 🔗

I'm using Bootstrap 5 🔗

I'm using Bootstrap 4 🔗

My project uses Sass 🔗

I'm using Bootstrap 4 or 5 🔗

Could it be better 🔗

3 mentiras que te contaram sobre quando usar as unidades em, rem ou px no CSS 🤬

Sumário

rem é mais acessível 🔗

Valores absolutos e relativos em CSS: quando usar px, % e rem

deMenezes ・ Jul 12 '22

rem é melhor que em 🔗

px e outras unidades absolutas são ruins 🔗

Referências 🔗

Use variáveis CSS como uma pessoa sênior com essas 5 dicas 🔥

Sumário

101 🔗

Design tokens 🔗

Composição de variáveis 🔗

Blocos enxutos 🔗

Variáveis como props 🔗

Variáveis privadas 🔗

Bento Grid layout responsivo em 40 linhas de CSS🥢 🍱

Zack MacTavish ・ Aug 14, 2022 ・
Medium

`rem`

`em`

`ch`

`ex`

`rem` é mais acessível 🔗

`rem` é melhor que `em` 🔗

`px` e outras unidades absolutas são ruins 🔗