HTML puro

Front-end é tudo que roda no navegador do visitante: o que ele vê, lê e clica. Back-end é o que roda no servidor, invisível para ele: banco de dados, login, envio de e-mail, processamento de pagamento.

O exemplo que fecha a ideia é uma loja online. A vitrine com fotos, o carrinho que você vê na tela e o botão “comprar” são front-end. Quando você clica em comprar, quem confere estoque, calcula frete, cobra o cartão e grava o pedido é o back-end.

UI (User Interface) é o desenho: cores, tipografia, espaçamento, ícones, o formato do botão. UX (User Experience) é a experiência de usar: se a pessoa entende onde clicar, se o caminho até o objetivo é curto, se ela não fica perdida.

São independentes. Dá pra ter UI lindo com UX péssimo — um site premiado onde ninguém acha o telefone. E o contrário: uma página feia, sem graça, mas que resolve o problema da pessoa em dois cliques.

Numa landing page, a decisão mais cara costuma ser de UX, não de UI: quantos campos o formulário tem, se o botão de WhatsApp aparece antes ou depois da rolagem, se a pessoa precisa entender a oferta antes de agir. Cada campo a mais no formulário derruba conversão — isso é decisão de UX, e nenhuma escolha de cor conserta.

Front-end é feito de três linguagens com papéis separados. Elas não competem — se empilham.

O teste que mostra a separação: desligue o CSS de um site e ele vira um documento sem estilo, mas legível — o conteúdo continua lá. Desligue o JavaScript e ele fica estático, mas ainda navegável. É por isso que a regra “a página funciona com JS desligado” é razoável de exigir: o essencial não deveria depender da terceira camada.

<!-- HTML: a estrutura, sem estilo nenhum -->
<button class="cta">Falar no WhatsApp</button>

/* CSS: como esse botão aparece */
.cta {
  background: #7A1C30;
  color: #fff;
  padding: 14px 28px;
  border: 0;
  border-radius: 4px;
  cursor: pointer;
}

// JS: o que acontece quando clicam nele
document.querySelector('.cta').addEventListener('click', () => {
  window.open('https://wa.me/5567999999999', '_blank', 'noopener');
});

Framework é uma estrutura de código pronta que já resolve os problemas comuns de um tipo de projeto, para você não escrever tudo do zero.

A diferença para uma biblioteca está em quem manda no fluxo. Numa biblioteca, você chama ela quando precisa — uma função de formatar data, por exemplo; o controle é seu. Num framework, ele chama você: define a estrutura do projeto, as pastas, o ciclo de vida, e o seu código se encaixa nas regras dele.

Isso tem um nome clássico: inversão de controle. Biblioteca é ferramenta na sua mão. Framework é a oficina — você trabalha dentro dela.

Todos resolvem o mesmo problema central: manter a tela em sincronia com os dados sem você atualizar cada pedaço na mão.

A relação React → Next.js é de camada, não de rivalidade: Next.js é construído em cima do React. Trocar um pelo outro não é migração de linguagem, é reorganização de estrutura.

Um detalhe que explica a confusão nas listas de ferramentas: quando um app te deixa escolher entre “React, Next.js, Angular e Android”, os três primeiros são web e o quarto é uma plataforma de celular. Estão na mesma lista porque são destinos possíveis do código gerado, não porque sejam a mesma categoria de coisa.

Antes do Node, JavaScript só rodava dentro do navegador. O Node pegou o motor que o Chrome usa para executar JS (o V8) e passou a rodá-lo fora do navegador — no seu computador ou num servidor. Com isso, JavaScript virou uma linguagem que também serve para back-end.

Node não é framework: é o ambiente onde o código roda. A hierarquia fica assim:

JavaScript  ← a linguagem
   │
   ├── roda no navegador   →  front-end (React, Vue, ou JS puro)
   │
   └── roda no Node.js     →  back-end
                                 └── Express, NestJS, Fastify (frameworks)

Vale saber mesmo sem fazer back-end: quase toda ferramenta moderna de desenvolvimento roda sobre Node. Se um dia você instalar o Tailwind, um compilador de Sass ou um minificador, é o Node que executa essas ferramentas na sua máquina — mesmo que o site entregue não tenha uma linha de Node.

Em cima do Node

Em outras linguagens

Para o seu trabalho, o momento em que um deles entra é bem definido: quando o cliente precisar de algo que não cabe no navegador — área de aluno com login, catálogo que ele edita sozinho, cobrança recorrente, envio de e-mail pelo próprio site.

O gatilho não é o número de páginas. Sete páginas estáticas continuam sendo sete arquivos HTML. O gatilho é a origem do conteúdo e a existência de estado compartilhado.

O conteúdo muda sem você editar o código?
  ├── NÃO → HTML puro resolve. Mesmo com 20 páginas.
  └── SIM ↓

Precisa de login, banco de dados ou pagamento?
  ├── SIM → back-end + framework. Sem alternativa.
  └── NÃO ↓

É muito item repetido com o mesmo layout
(catálogo, blog, portfólio grande)?
  ├── SIM → gerador de site estático ou Next.js
  └── NÃO → HTML puro ainda ganha.

Sobre o caminho de migração: vanilla → React é reescrita, não upgrade. O React trabalha com componentes e estado, uma lógica diferente da manipulação direta do DOM; o CSS aproveita bastante, a lógica não. Já React → Next.js é tranquilo, porque um é construído sobre o outro: muda a organização de pastas e o roteamento, não a lógica dos componentes.

npm (Node Package Manager) é o instalador de pacotes do mundo JavaScript. Você pede uma biblioteca pelo nome e ele baixa ela e tudo de que ela depende.

O package.json é a ficha do projeto: nome, versão, lista de dependências e atalhos de comando. É o arquivo que permite outra pessoa clonar seu projeto, rodar um comando e ter exatamente o mesmo ambiente.

npm init -y              # cria o package.json
npm install nome-do-pacote   # instala e anota na lista
npm run dev              # roda um atalho definido em "scripts"

A pasta node_modules que aparece guarda os pacotes baixados. Ela é gigante e nunca vai pro Git nem pro servidor — o package.json é que descreve o que precisa ser reinstalado.

Um bundler (empacotador) pega dezenas de arquivos de código-fonte e produz poucos arquivos otimizados para o navegador: junta, remove o que não é usado, minifica, converte sintaxe nova para versões que navegadores antigos entendem.

Webpack é o veterano: poderoso, configurável e trabalhoso. Vite é a geração seguinte: praticamente sem configuração, com recarga instantânea durante o desenvolvimento. Hoje, projeto novo começa com Vite.

É aqui que mora a palavra build. “Precisa de build” significa: o código que você escreve não é o código que vai pro ar — existe uma etapa de processamento no meio.

TypeScript é JavaScript com tipos declarados. Você diz que uma variável é texto ou número, e o editor avisa antes de rodar quando algo não bate.

// JavaScript — só descobre o erro rodando
function calcularFrete(peso) {
  return peso * 12.5;
}
calcularFrete("dois quilos");   // NaN, silenciosamente

// TypeScript — o editor acusa antes de rodar
function calcularFrete(peso: number): number {
  return peso * 12.5;
}
calcularFrete("dois quilos");   // erro apontado na hora

O navegador não entende TypeScript — ele é convertido para JavaScript antes de ir pro ar. Ou seja: exige build.

Compensa em projeto grande, com várias pessoas, onde um erro de tipo custa caro. Em landing page de uma página, o custo da etapa de build supera o benefício.

Todo arquivo HTML tem duas partes: o <head>, que ninguém vê mas os robôs leem, e o <body>, que é a página visível.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Título que aparece na aba e no Google</title>
  <meta name="description" content="Resumo de até 155 caracteres.">
</head>
<body>
  <!-- tudo que a pessoa vê -->
</body>
</html>

Semântico significa usar a tag que descreve o que aquilo é, em vez de <div> para tudo. Visualmente dá no mesmo — mas Google, leitores de tela e navegação por teclado leem a diferença.

<div class="topo">
  <div class="menu">...</div>
</div>
<div class="conteudo">
  <div class="titulo-grande">Bar de drinks</div>
</div>
<div class="rodape">...</div>

<header>
  <nav>...</nav>
</header>
<main>
  <h1>Bar de drinks</h1>
  <section>...</section>
</main>
<footer>...</footer>

As tags que resolvem 90% dos casos

Hierarquia de títulos

Um <h1> por página — é o título principal, e o Google usa ele com peso. Os demais descem em ordem: h2 para seções, h3 para subseções. Não pule níveis para conseguir um tamanho de fonte: tamanho é trabalho do CSS, hierarquia é trabalho do HTML.

<img src="bar-montado.webp"
     alt="Bar montado em festa de casamento ao ar livre"
     width="1200" height="800"
     loading="lazy">

Sobre data-*: é a ponte oficial entre HTML e JS. Você guarda o valor no HTML e lê pelo dataset — sem precisar escrever o número dentro do JavaScript.

// <span class="contador" data-num="300">0</span>
const alvo = document.querySelector('.contador');
console.log(alvo.dataset.num);   // "300"

O navegador já valida formulário sozinho, em português, sem uma linha de JavaScript. Muita gente reimplementa isso à toa.

<form id="orcamento">
  <label for="nome">Seu nome</label>
  <input id="nome" name="nome" type="text" required
         minlength="3" autocomplete="name">

  <label for="fone">WhatsApp</label>
  <input id="fone" name="fone" type="tel" required
         inputmode="numeric" autocomplete="tel">

  <label for="data">Data do evento</label>
  <input id="data" name="data" type="date" required>

  <label for="pessoas">Convidados</label>
  <input id="pessoas" name="pessoas" type="number"
         min="10" step="10" required>

  <button type="submit">Pedir orçamento</button>
</form>

O <label> não é opcional

O for do label tem que bater com o id do campo. Isso faz o clique no texto focar o campo, permite o leitor de tela anunciar o rótulo, e aumenta a área de toque no celular. Usar só placeholder como rótulo é um erro: ele some quando a pessoa começa a digitar.

// Deixa o navegador validar; só depois monta a mensagem
form.addEventListener('submit', (e) => {
  e.preventDefault();
  if (!form.reportValidity()) return;   // mostra os erros nativos

  const d = new FormData(form);
  const msg = `Olá! Vim pelo site.\n\n`
            + `Nome: ${d.get('nome')}\n`
            + `Convidados: ${d.get('pessoas')}`;

  window.open(`https://wa.me/5567999999999?text=${encodeURIComponent(msg)}`,
              '_blank', 'noopener');
});

Acessibilidade não é recurso extra: é o site funcionar para quem usa leitor de tela, navega por teclado, enxerga pouco contraste ou está no sol com o brilho no mínimo. E o que resolve a maior parte é barato.

<!-- botão só com ícone precisa de nome acessível -->
<button aria-label="Abrir menu" aria-expanded="false"
        aria-controls="painel-menu">☰</button>

<!-- link de WhatsApp: o texto já descreve, não precisa de aria -->
<a href="https://wa.me/5567999999999">Falar no WhatsApp</a>

Todo elemento é uma caixa com quatro camadas, de dentro para fora: conteúdo, padding (espaço interno), border (borda) e margin (espaço externo).

┌─────────── margin ────────────┐   ← empurra os vizinhos
│  ┌──────── border ─────────┐  │
│  │  ┌───── padding ─────┐  │  │   ← afasta o conteúdo da borda
│  │  │                   │  │  │
│  │  │     conteúdo      │  │  │
│  │  │                   │  │  │
│  │  └───────────────────┘  │  │
│  └─────────────────────────┘  │
└───────────────────────────────┘

A linha que você sempre escreve (e por quê)

Por padrão, width: 300px define a largura só do conteúdo. Se você somar padding e borda, a caixa fica maior que 300px — e o layout estoura. O border-box muda isso: a largura passa a incluir padding e borda.

* { box-sizing: border-box; }

/* Agora isto ocupa exatamente 300px, não 340px: */
.card {
  width: 300px;
  padding: 20px;   /* 20px de cada lado */
}

Colapso de margem

Duas margens verticais que se encostam não somam — vence a maior. Margem de 30px embaixo de um elemento e 20px em cima do próximo resultam em 30px, não 50px. É a causa mais comum de “o espaçamento não está batendo”. Usar gap no flex ou grid evita o problema inteiro.

Quando duas regras mandam na mesma propriedade, vence a mais específica — não a que veio depois. Esta é a resposta para “editei a cor e não mudou nada”.

.botao        { background: red; }    /* peso 10  */
#cta .botao   { background: blue; }   /* peso 110 — vence */

/* Mesmo escrevendo a regra vermelha depois, azul continua ganhando */

Seletores que vale conhecer

.card .titulo      { }   /* descendente: título dentro de card */
.card > .titulo    { }   /* filho direto apenas */
.card + .card      { }   /* um card imediatamente após outro */
.card:not(.ativo)  { }   /* todos menos os ativos */
a[href^="https"]   { }   /* link cujo href começa com https */
a[href$=".pdf"]    { }   /* link cujo href termina em .pdf */

Você declara um valor num lugar só e usa em todo o arquivo. Mudar a paleta do cliente vira editar cinco linhas em vez de caçar hexadecimais.

:root {
  --marsala:   #7A1C30;
  --preto:     #0B0B0B;
  --off:       #F9F8F6;
  --espaco:    24px;
}

.botao {
  background: var(--marsala);
  color: var(--off);
  padding: calc(var(--espaco) / 2) var(--espaco);
}

/* valor reserva, caso a variável não exista */
.card { border-color: var(--linha, #ddd); }

Diferente das variáveis do Sass, estas são lidas pelo navegador em tempo real — o JavaScript consegue trocar uma e a página inteira muda na hora. É assim que se faz tema claro/escuro sem duplicar CSS.

document.documentElement.style.setProperty('--marsala', '#0D6B62');

clamp() — tipografia que se ajusta sozinha

Define mínimo, valor ideal e máximo numa linha só. Substitui várias media queries para tamanho de fonte.

h1 {
  /* nunca menor que 32px, nunca maior que 64px,
     entre os dois acompanha a largura da tela */
  font-size: clamp(32px, 6vw, 64px);
}

Organiza elementos numa direção — linha ou coluna — e distribui o espaço entre eles. É a ferramenta para menu, barra de botões, card com ícone ao lado do texto.

.menu {
  display: flex;
  align-items: center;        /* alinha no eixo vertical  */
  justify-content: space-between;  /* distribui no horizontal */
  gap: 24px;                  /* espaço entre os filhos   */
  flex-wrap: wrap;            /* quebra linha se faltar espaço */
}

.linha {
  display: flex;
  gap: 10px;
  justify-content: space-between;   /* flex-start · center · space-between · space-evenly */
}

Organiza em duas dimensões — linhas e colunas ao mesmo tempo. É a ferramenta para grade de cards, galeria, layout de página com barra lateral.

.galeria {
  display: grid;
  grid-template-columns: repeat(3, 1fr);  /* 3 colunas iguais */
  gap: 24px;
}

/* Grade que se adapta sozinha, sem media query:
   cada card tem no mínimo 260px; cabem quantos couberem */
.galeria-auto {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(260px, 1fr));
  gap: 24px;
}

.grade {
  display: grid;
  gap: 8px;
  /* quantas colunas de 64px couberem; o que sobra, divide igual */
  grid-template-columns: repeat(auto-fit, minmax(64px, 1fr));
}

Aquele auto-fit com minmax é o padrão mais útil do Grid: resolve responsividade de galeria sem escrever uma media query. Vale decorar.

Flex ou Grid?

Mobile-first significa escrever o CSS base para a tela pequena e ir adicionando o que muda conforme a tela cresce. Fica menos código, porque o layout de celular é quase sempre o mais simples: tudo empilhado numa coluna.

/* base: celular — uma coluna */
.secao {
  padding: 48px 16px;
}
.cards {
  display: grid;
  gap: 16px;
}

/* tablet pra cima */
@media (min-width: 700px) {
  .cards { grid-template-columns: repeat(2, 1fr); }
}

/* desktop */
@media (min-width: 1024px) {
  .secao { padding: 96px 24px; }
  .cards { grid-template-columns: repeat(3, 1fr); gap: 24px; }
}

Breakpoints que funcionam na prática

Não persiga modelos de aparelho. Escolha o ponto onde o seu layout começa a ficar feio — esse é o breakpoint certo, mesmo que seja 843px.

Outras media queries úteis

@media (prefers-reduced-motion: reduce) { /* desliga animação   */ }
@media (prefers-color-scheme: dark)     { /* tema escuro do SO  */ }
@media (hover: none)                    { /* telas sem mouse    */ }
@media print                            { /* versão impressa    */ }

Pseudo-classe (um :) estiliza um estado do elemento. Pseudo-elemento (dois ::) cria uma parte visual que não existe no HTML.

/* estados */
.botao:hover        { background: #5A1827; }
.botao:focus-visible{ outline: 2px solid #C9A66B; outline-offset: 2px; }
.botao:disabled     { opacity: .5; cursor: not-allowed; }
.campo:invalid      { border-color: #B8461F; }

/* posição na lista */
.card:first-child   { }
.card:last-child    { }
.card:nth-child(2n) { }   /* os pares */

/* partes criadas pelo CSS */
.rotulo::before {
  content: "";
  display: inline-block;
  width: 28px; height: 1px;
  background: currentColor;
  margin-right: 12px;
}

O ::before e o ::after precisam de content para existir, nem que seja vazio. São a forma de criar detalhes gráficos — filetes, aspas decorativas, marcadores — sem sujar o HTML com <div> vazia.

Transição suaviza a mudança entre dois estados. Animação (@keyframes) define uma sequência própria, que roda sozinha.

/* transição: do estado normal para o hover */
.botao {
  background: #7A1C30;
  transition: background .2s ease, transform .2s ease;
}
.botao:hover {
  background: #5A1827;
  transform: translateY(-2px);
}

/* animação própria */
@keyframes surgir {
  from { opacity: 0; transform: translateY(18px); }
  to   { opacity: 1; transform: translateY(0); }
}
.card { animation: surgir .6s cubic-bezier(.22,.61,.36,1) both; }

.cena { perspective: 700px; }          /* a distância do olho: dá a profundidade */
.cubo {
  --l: 96px;
  width: var(--l); height: var(--l);
  position: relative;
  transform-style: preserve-3d;        /* os filhos ficam no 3D, não achatados */
  animation: gira 9s linear infinite;  /* movimento constante: linear */
}
.cubo span { position: absolute; inset: 0; }
.f1 { transform: translateZ(calc(var(--l) / 2)); }
.f2 { transform: rotateY(180deg) translateZ(calc(var(--l) / 2)); }
.f3 { transform: rotateY(90deg)  translateZ(calc(var(--l) / 2)); }
.f4 { transform: rotateY(-90deg) translateZ(calc(var(--l) / 2)); }
.f5 { transform: rotateX(90deg)  translateZ(calc(var(--l) / 2)); }
.f6 { transform: rotateX(-90deg) translateZ(calc(var(--l) / 2)); }

@keyframes gira {
  from { transform: rotateX(-22deg) rotateY(0deg); }
  to   { transform: rotateX(-22deg) rotateY(360deg); }
}
@media (prefers-reduced-motion: reduce) {
  .cubo { animation: none; transform: rotateX(-22deg) rotateY(38deg); }
}

Anime só duas propriedades

transform e opacity são processadas pela placa de vídeo e não forçam o navegador a recalcular o layout. Animar width, height, top ou margin trava em celular. Precisa mover algo? Use transform: translate(), não top.

Opções de animação

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: .01ms !important;
    transition-duration: .01ms !important;
  }
}

Quando o navegador lê seu HTML, ele monta na memória uma árvore de objetos representando cada elemento. Essa árvore é o DOM (Document Object Model). O JavaScript não mexe no arquivo HTML — ele mexe nessa árvore, e o navegador redesenha a tela.

<body>                    document
  <header>                  └── html
    <h1>Art Bar</h1>             ├── head
  </header>                      └── body
  <main>                              ├── header
    <p>Drinks</p>                    │     └── h1 → "Art Bar"
  </main>                             └── main
</body>                                     └── p  → "Drinks"

Duas consequências práticas. Primeira: se o seu <script> roda antes do elemento existir na árvore, ele não acha nada — por isso o script vai no fim do <body>. Segunda: alterações no DOM são temporárias. Recarregou a página, voltou tudo ao HTML original.

Evento é “algo aconteceu”: um clique, uma tecla, uma rolagem, um formulário enviado. Você registra uma função que roda quando isso acontece.

botao.addEventListener('click', (e) => {
  console.log('clicaram em', e.target);
});

Delegação de eventos

Em vez de registrar um ouvinte em cada card, registre um só no container e descubra quem foi clicado. Funciona inclusive para elementos criados depois.

galeria.addEventListener('click', (e) => {
  const card = e.target.closest('.card');
  if (!card) return;
  abrirLightbox(card.dataset.foto);
});

Scroll sem travar

O evento scroll dispara dezenas de vezes por segundo. Trabalho pesado direto nele engasga a rolagem — a solução é agrupar dentro de requestAnimationFrame.

let agendado = false;
window.addEventListener('scroll', () => {
  if (agendado) return;
  agendado = true;
  requestAnimationFrame(() => {
    menu.classList.toggle('is-solid', window.scrollY > 80);
    agendado = false;
  });
});

Avisa quando um elemento entra ou sai da tela, sem você ficar calculando posição no scroll. É a ferramenta certa para animação de entrada, contador que começa ao aparecer e menu que destaca a seção atual.

const observador = new IntersectionObserver((entradas) => {
  entradas.forEach(entrada => {
    if (entrada.isIntersecting) {
      entrada.target.classList.add('is-in');
      observador.unobserve(entrada.target);   // anima uma vez só
    }
  });
}, { threshold: .15 });   // 15% visível já conta

document.querySelectorAll('[data-reveal]')
  .forEach(el => observador.observe(el));

O threshold é a fração do elemento que precisa estar visível para disparar. O unobserve é o que impede a animação de repetir a cada rolagem — e libera memória.

Buscar algo na internet leva tempo, e o JavaScript não fica parado esperando. Uma Promise é a promessa de um resultado que chega depois. O async/await é a forma legível de escrever isso.

async function buscarCep(cep) {
  try {
    const resposta = await fetch(`https://viacep.com.br/ws/${cep}/json/`);
    if (!resposta.ok) throw new Error('CEP não encontrado');

    const dados = await resposta.json();
    return dados.localidade;      // "Campo Grande"
  } catch (erro) {
    console.error(erro);
    return null;
  }
}

// usando
const cidade = await buscarCep('79000000');

JSON é um formato de texto para representar dados. É o que quase toda API devolve e o que você usa para separar conteúdo de código.

const DADOS = {
  drinks: [
    { nome: "Negroni de Cerrado", alcool: true,
      ingredientes: ["gin", "campari", "vermute"] },
    { nome: "Pantanal Sem Álcool", alcool: false,
      ingredientes: ["maracujá", "hortelã", "tônica"] }
  ]
};

// gerar HTML a partir dos dados
const html = DADOS.drinks.map(d => `
  <article class="card">
    <h3>${d.nome}</h3>
    <p>${d.ingredientes.join(' · ')}</p>
  </article>
`).join('');

document.querySelector('.carta').innerHTML = html;

Guarda pequenos textos no navegador da pessoa, e eles sobrevivem ao fechar a aba. Serve para preferências: tema escolhido, aviso de cookie já dispensado, formulário parcialmente preenchido.

// sempre dentro de try/catch: pode estar bloqueado
try {
  localStorage.setItem('tema', 'escuro');
  const tema = localStorage.getItem('tema');   // "escuro" ou null
  localStorage.removeItem('tema');
} catch (e) {
  // aba anônima ou cookies bloqueados — a página segue funcionando
}

// guardando objeto: precisa virar texto
localStorage.setItem('rascunho', JSON.stringify({ nome: 'Ana' }));
const rascunho = JSON.parse(localStorage.getItem('rascunho') || '{}');

Durante vinte anos o CSS só olhava para baixo: você estilizava um filho, nunca o pai. O :has() inverte isso — estiliza um elemento com base no que existe dentro dele.

/* card que TEM imagem ganha layout diferente */
.card:has(img) {
  grid-template-columns: 120px 1fr;
}

/* campo preenchido: esconde o rótulo flutuante */
.campo:has(input:not(:placeholder-shown)) .rotulo {
  opacity: 0;
}

/* o formulário inteiro reage a um checkbox marcado */
form:has(#outro:checked) .campo-extra {
  display: block;
}

/* menu aberto trava a rolagem — sem tocar no JS */
body:has(.menu-painel.is-aberto) {
  overflow: hidden;
}

Aquele último exemplo merece atenção: é um caso em que você provavelmente escreve document.body.style.overflow = 'hidden' no JavaScript. Com :has(), o CSS reage sozinho à classe que já existe.

Media query pergunta “qual o tamanho da tela?”. Container query pergunta “qual o tamanho do espaço onde eu estou?”. A diferença é grande: o mesmo card pode aparecer largo numa seção e estreito numa barra lateral, e se adaptar sozinho aos dois.

/* 1. declara que este elemento é um container mensurável */
.coluna {
  container-type: inline-size;
  container-name: coluna;
}

/* 2. o filho reage à largura DA COLUNA, não da tela */
@container coluna (min-width: 420px) {
  .card {
    display: grid;
    grid-template-columns: 140px 1fr;
    gap: 16px;
  }
}

Por que isso muda o jeito de pensar: com media query, um componente precisa saber em que ponto da página ele foi colocado. Com container query, ele se vira sozinho em qualquer lugar. É o que torna um componente de verdade reutilizável.

O CSS agora aninha regras sem pré-processador. Era o principal motivo de usar Sass — e ele sumiu.

.card {
  padding: 20px;
  border: 1px solid var(--linha);

  &:hover { border-color: var(--destaque); }

  .titulo {
    font-size: 20px;
    margin-bottom: 8px;
  }

  @media (min-width: 700px) {
    padding: 32px;
  }
}

O & representa o próprio seletor pai. Dentro do aninhamento você também pode colocar media queries, o que mantém tudo sobre um componente no mesmo bloco.

@layer — resolvendo brigas de especificidade

Camadas definem a ordem de prioridade independentemente da especificidade. Uma regra numa camada posterior vence uma regra mais específica de uma camada anterior. É a solução estrutural para o problema que hoje se resolve com !important.

@layer base, componentes, utilidades;

@layer base {
  #conteudo p { color: gray; }   /* especificidade alta */
}

@layer utilidades {
  .texto-escuro { color: black; }  /* especificidade baixa... e vence */
}

Hexadecimal não tem lógica interna: #7A1C30 não te diz nada, e “clarear 10%” vira tentativa e erro. O oklch() descreve a cor em três números que fazem sentido — Luminosidade, Croma (saturação) e Hue (matiz, em graus).

:root {
  --marca-h: 345;   /* o matiz do marsala, em graus */

  --marca:       oklch(38% 0.13 var(--marca-h));
  --marca-clara: oklch(58% 0.13 var(--marca-h));  /* só a luz mudou */
  --marca-escura:oklch(26% 0.13 var(--marca-h));
}

A vantagem prática: a paleta inteira do cliente sai de um número. Mudou o matiz, mudou tudo de forma coerente — e a diferença de luminosidade é perceptualmente uniforme, coisa que o HSL não garante.

color-mix() — misturar sem calculadora

/* a cor da marca com 15% de transparência */
.aviso { background: color-mix(in srgb, var(--marca) 15%, transparent); }

/* a cor da marca puxada para o branco */
.suave  { background: color-mix(in srgb, var(--marca) 20%, white); }

Seguir o tema do sistema é fácil: um @media (prefers-color-scheme: dark) resolve quando o cliente não pede botão nenhum. O problema aparece quando ele pede — alternador manual, escolha lembrada na próxima visita, e a página sem piscar clara antes de escurecer.

Primeiro: declare que a página sabe lidar com os dois temas

<meta name="color-scheme" content="light dark">

Sem essa declaração, o navegador trata a página como só-clara: barra de rolagem, campo de formulário e seletor de data continuam com aparência clara mesmo que o seu fundo seja escuro. Com ela, esses elementos nativos acompanham o tema. A propriedade color-scheme no CSS faz o mesmo; a meta tag tem a vantagem de ser lida antes do CSS carregar, o que ajuda a evitar um clarão branco no início.

light-dark() — as duas cores num lugar só

Antes, cada cor que muda de tema pedia duas declarações: uma no :root e outra dentro do @media (prefers-color-scheme: dark), repetidas para cada variável. A função light-dark() junta as duas.

:root {
  color-scheme: light dark;

  --fundo: light-dark(#FFFFFF, #0D1514);
  --texto: light-dark(#1A1A1A, #E8E8E8);
  --marca: light-dark(oklch(38% 0.13 345), oklch(58% 0.13 345));
}

body {
  background: var(--fundo);
  color: var(--texto);
}

.card {
  color-scheme: light;   /* dark, ou "light dark" para seguir o sistema */
  background: light-dark(#FFFCF7, #16181C);
  color:      light-dark(#3F444D, #E8E6E1);
  border: 1px solid light-dark(#E6E2DA, #2E3236);
}
.card .botao {
  background: light-dark(#7A1C30, #D9869A);
  color:      light-dark(#FFFFFF, #16181C);
}

Com color-scheme: light dark no :root, o navegador usa o primeiro valor de cada light-dark() quando o sistema está no claro e o segundo quando está no escuro — sem media query. Aproveite para escolher cada par com oklch(): mesma cor, só a luminosidade muda.

O alternador manual: vencer a escolha do sistema

Quando o cliente quer um botão de sol/lua, ele precisa sobrescrever a preferência do sistema. Um atributo no <html> troca o color-scheme dali, e o light-dark() acompanha sozinho.

:root {
  color-scheme: light dark; /* segue o sistema por padrão */
}

html[data-tema="claro"]  { color-scheme: light; }
html[data-tema="escuro"] { color-scheme: dark;  }

const botao = document.querySelector('.alternador-tema');
if (botao) {
  botao.addEventListener('click', () => {
    const raiz = document.documentElement;
    // sem escolha salva, o "atual" é o que o sistema está mostrando
    const escuroAgora = raiz.dataset.tema
      ? raiz.dataset.tema === 'escuro'
      : matchMedia('(prefers-color-scheme: dark)').matches;
    const novo = escuroAgora ? 'claro' : 'escuro';
    raiz.dataset.tema = novo;
    try { localStorage.setItem('tema', novo); } catch (e) {}
  });
}

A checagem com matchMedia não é enfeite: sem ela, quem está com o sistema no escuro clicaria no botão e nada mudaria na primeira vez, porque o "próximo" tema calculado seria o que já está na tela.

O flash de tema errado — e como evitar

Se você lê o localStorage só depois que a página carregou, o visitante vê a página abrir no tema padrão e trocar de repente para o salvo. A saída é aplicar o atributo antes do CSS renderizar, com um script inline no <head>, antes de qualquer <link rel="stylesheet">.

<script>
  try {
    const salvo = localStorage.getItem('tema');
    if (salvo) document.documentElement.dataset.tema = salvo;
  } catch (e) {}
</script>

A meta tag e o light-dark() funcionam sozinhos, seguindo o sistema. O alternador e o script inline só fazem sentido juntos, e só se o cliente pediu o botão — sem esse pedido, pare no light-dark().

Aquele reveal ao rolar que hoje exige IntersectionObserver — ou a biblioteca AOS — virou CSS puro. E roda na thread de composição, então não trava nem em celular fraco.

@keyframes surgir {
  from { opacity: 0; transform: translateY(24px); }
  to   { opacity: 1; transform: translateY(0); }
}

.secao {
  animation: surgir linear both;
  animation-timeline: view();          /* atrelada à entrada na tela */
  animation-range: entry 10% cover 35%; /* começo e fim do movimento */
}

/* barra de progresso de leitura, no topo da página */
.progresso {
  animation: encher linear;
  animation-timeline: scroll();   /* atrelada à rolagem da página */
}
@keyframes encher { to { width: 100%; } }

Transição animada entre estados — ou entre páginas diferentes — com o navegador cuidando do trabalho pesado. É o efeito que antes só existia em aplicativo nativo ou em SPA com framework.

/* transição suave entre páginas do mesmo site */
@view-transition { navigation: auto; }

/* elemento que "viaja" de uma página para a outra */
.hero-foto { view-transition-name: foto-principal; }

Com esse nome igual nas duas páginas, o navegador entende que é o mesmo elemento e anima a transformação entre uma posição e a outra — a foto do card cresce e vira a foto do topo da página seguinte.