Card que expande para tela cheia

Um trilho horizontal de cards retrato: foto, categoria em cor de marca e título dentro da imagem. No clique, o card não abre um modal centralizado — ele cresce do lugar exato onde está até cobrir a tela, com o raio da quina indo a zero, e só quando termina de crescer o conteúdo entra: foto cheia de um lado, categoria, título, texto, tags e CTA do outro.

O que resolve editorialmente: uma coleção de casos em que cada item merece meia página de leitura, mas nenhum merece uma página inteira. A grade comum obriga a escolher entre mostrar tudo (e virar parede de texto) ou mostrar só o título (e não convencer ninguém). Aqui o card mostra o mínimo, o overlay mostra o suficiente, e a transição entre os dois deixa claro que é o mesmo item — que é a coisa que um modal centralizado nunca consegue dizer.

É o primeiro componente da categoria sobreposições.

Quando usar

• Coleção de 4 a 10 casos, projetos ou serviços em que cada item tem foto, uma categoria e 35 a 55 palavras de explicação.
• Quando existe foto boa de cada item. O componente é 70% imagem: sem foto ele não tem o que expandir.
• Quando o site ainda não tem (nem vai ter) uma página por caso. Se cada caso já tem página própria, o card deve virar link — veja a variação.
• Como respiro depois de uma dobra densa de texto: o trilho é a única coisa da página que rola na horizontal, e isso sozinho já muda o ritmo da leitura.

Quando não usar

• Quando o conteúdo passa de 60 palavras ou pede subtítulo, lista ou segunda foto. O overlay tem um slot de parágrafo, não um corpo de artigo. Passando disso, o card vira link para uma página de caso.
• Quando os itens precisam ser comparados lado a lado. O trilho mostra três por vez e o overlay mostra um; nenhum dos dois compara nada. Para comparar, use conteudo/grid-entidades.
• Quando os itens não têm foto, ou têm foto de qualidade desigual. Uma foto ruim no meio do trilho derruba as outras cinco.
• Como último bloco antes do rodapé. O overlay cobre a tela inteira; fechá-lo devolve a pessoa a um ponto da página onde só resta ir embora.

Padrão editorial

Use de 4 a 10 cards. Com 3 o trilho não transborda em desktop, a barra de progresso some sozinha e o gesto de rolar lateralmente nunca acontece — a seção fica prometendo um movimento que não existe. Acima de 10, ninguém chega ao fim.

Especificação das imagens

data-img existe para apontar uma versão maior da mesma foto: o card pode carregar um recorte leve e o overlay a imagem cheia. Quando as duas são a mesma, pode omitir — o script cai na foto do card. O script pré-carrega a versão grande no primeiro hover ou foco do card, então ela chega antes da animação terminar.

Como usar

<link rel="stylesheet" href="componentes/overlay/card-expansivel-fullscreen/estilo.css">
<script src="componentes/overlay/card-expansivel-fullscreen/script.js"></script>

Cole markup.html, estilo.css e script.js. Depende do core (tokens, base, motion) e de mais nada.

Card novo é só mais um <li>. Todo o conteúdo do overlay mora nos data-* do card; não existe um segundo bloco de HTML por caso, e não há nada para manter em sincronia.

<li class="exp-item">
  <button class="exp-card" type="button" data-exp-card aria-haspopup="dialog"
          data-img="img/caso-1-grande.webp"
          data-cat="Consultoria"
          data-title="Título do caso"
          data-desc="Parágrafo de 35 a 55 palavras."
          data-tags="Uma,Duas,Três">
    <img class="exp-card-img" src="img/caso-1.webp" alt="Descrição da foto" loading="lazy" decoding="async">
    ...
  </button>
</li>

Ganchos

Atributos do card

Variações

Gotchas

• O data-rv vai no .exp-track, nunca no .exp. O reveal do core aplica filter: blur(), e filter cria bloco de contenção para descendentes position:fixed — inclusive com blur(0), que continua sendo um filtro. Subindo o data-rv um nível, o overlay para de cobrir a tela e passa a viver dentro do trilho, sem erro nenhum no console. Vale para qualquer ancestral: nada acima do overlay pode ter transform, filter, perspective, backdrop-filter ou will-change desses.

• O overlay tem de continuar dentro da <section>. É de lá que ele herda o escopo de tom (--bg, --fg, --fg-2). Custom property herda pela árvore do DOM, não pelo layout, então position:fixed não atrapalha — mas mover o bloco para fora da seção, sim.

• A escala é não uniforme e distorce o que estiver dentro. É por isso que o conteúdo só entra depois que a caixa para: durante o crescimento, o overlay é uma superfície vazia, e não há o que distorcer. Se você fizer o conteúdo aparecer junto, ele entra esticado. O encadeamento por transitionend não é enfeite.

• A escala é medida contra o próprio overlay, nunca contra documentElement.clientWidth. Com o scrollbar-gutter:stable do core/base.css, o bloco de contenção de um position:fixed é 15px mais estreito que o clientWidth que o documento reporta com o scroll travado. Usando o clientWidth, a caixa nasce ~4px fora do card — visível, e sem nenhum sintoma que aponte a causa. O script mede overlay.offsetWidth/offsetHeight: o elemento que vai animar não tem como divergir de si mesmo.

• A classe .is-measuring existe por causa dessa medição. Para medir, o overlay precisa sair do [hidden] — e nesse instante ele já está em tela cheia. Sem desligar a transição na janela entre medir e posicionar, o efeito roda ao contrário: a caixa aparece cheia e encolhe até o card. São quatro recálculos de estilo em sequência no abrir(), cada um comentado no script; não reordene sem entender os quatro.

• O raio inicial é --radius-media, não 16px. O script lê o border-radius computado do próprio card. Em tema flat (--radius-media:0) não há raio para animar e o crescimento sai reto — que é o certo, não um bug. O calc(--exp-r / --exp-sx) do CSS existe porque um raio dentro de uma caixa escalada em .22 sairia com 3,5px na tela: dividir antes é o que faz o começo bater com o card.

• Clique no fundo fecha, mas "fundo" aqui é literal. O script compara o alvo por identidade com o overlay, a grade e a coluna de texto. Clicar no parágrafo, na foto, numa tag ou no CTA não fecha. Em tela larga o espaço vazio acima e abaixo do texto é o alvo real; em tela estreita quase não existe, e as saídas de verdade são o X e o Esc. É deliberado: um "fecha se clicar fora do conteúdo" fecharia ao arrastar para selecionar texto.

• A barra de rolagem do sistema está escondida. Em fundo escuro ela corta a composição. Em troca, o .exp-rail devolve a informação de quanto ainda falta — esconder sem repor seria esconder. Se o projeto preferir a barra nativa, apague scrollbar-width:none e o bloco ::-webkit-scrollbar, e apague a barra junto: as duas ao mesmo tempo ficam redundantes.

• A trava de rolagem é a do core. LIB.travarRolagem() / LIB.soltarRolagem(), com contador compartilhado por todas as sobreposições da página. Foi deste componente que o contador veio: ele já tinha o seu, mas privado, e um contador privado não conversa com o drawer nem com o modal. O travado local continua, para que cada trilho abra e feche a sua trava uma vez só.

• A compensação por padding-right foi embora, e isso foi medido. Até 2026-09 a trava daqui media a largura útil antes e depois de esconder o overflow e repunha a diferença como padding-right no body, para a página não saltar para o lado no meio da animação. Com a trava no <html> e o scrollbar-gutter:stable do core/base.css, o salto não existe: a calha de 15px continua reservada com o overflow:hidden aplicado. Medido em Chrome 1440x900 com barra clássica forçada — largura útil do body 1425 → 1425, calha 15 → 15, borda direita do .wrap 1332,5 → 1332,5 e do primeiro card 464,5 → 464,5, travado e solto. A prova de que a calha era real e não uma barra sobreposta de zero pixel: trocando para scrollbar-gutter:auto na mesma máquina, o .wrap vai a 1340 — os 15px reaparecem. Se algum dia o salto voltar (tema que apague o scrollbar-gutter, ou navegador que não o implemente), a conta certa é medir antes e depois, nunca chutar 15px fixo: em máquina com barra sobreposta um valor fixo empurra a página para o lado sem motivo. E não meça por documentElement.clientWidth — este Chrome reporta 1440 nos dois estados, com a calha reservada ou não, o que fazia a compensação antiga dar zero por acidente e não por acerto. A largura que se move é a da caixa do body.

• Trava e medição, nessa ordem. O retângulo do card é medido depois de travar a rolagem. A trava do core não mexe no layout (é o parágrafo acima), então hoje a ordem é seguro barato e não requisito — mas medir a página antes de mudar o estado dela é a ordem certa de qualquer jeito, e inverter não compra nada.

• Em prefers-reduced-motion não há FLIP. O script pula a medição e o overlay simplesmente aparece inteiro. As durações do CSS caem para .01ms em vez de none, de propósito: assim o transitionend continua disparando e o encadeamento do script segue por um caminho só, em vez de ter dois.

• Esc é escutado no document, não no overlay. Diferente do midia/galeria-pasta, aqui isso é o certo: um diálogo modal tem de fechar com Esc esteja o foco onde estiver. Cada trilho registra um listener e ele só age quando aquele overlay está aberto.

• Foco preso, mas só nos focáveis que existem. A busca é refeita a cada Tab porque o CTA muda de href e o bloco de tags pode estar hidden. Com o overlay fechado o hidden tira tudo da ordem de tabulação — não apague esse atributo do markup.

• A foto do overlay não tem src no HTML. Um src="" dispara um pedido para a própria página. Quem preenche é o script, sempre antes de tirar o [hidden].

• --exp-gutter reproduz a borda da coluna fora do .wrap. O trilho sangra até a borda de propósito (contrato §4: quem sangra sai do .wrap), e a conta max(0px,(100% - --max)/2) + --pad é o que alinha a primeira foto com o título. Trocando --max ou --pad no tema, o alinhamento acompanha sozinho.

Histórico

Calibragem no primeiro uso. Foi bastante reescrito na travessia, e a abertura a partir da posição exata do card é a parte sensível: espere ajuste se o trilho mudar de altura.