Hero em slideshow cinematográfico

Abertura de tela cheia com três slides. Cada slide é uma foto sangrada que entra em fusão com desfoque e passa os sete segundos seguintes num zoom lento — o Ken Burns —, com olho, headline que entra palavra a palavra, apoio e botão próprios. No pé da dobra, uma barra de três abas numeradas reparte a largura da coluna: a aba ativa tem uma linha de progresso que enche exatamente no tempo do slide, e é ela que diz quanto falta. Clicar numa aba, apertar as setas do teclado ou arrastar o dedo troca na hora. O relógio para quando o ponteiro entra no texto ou nas abas, quando o foco entra na seção, quando a aba do navegador é escondida, quando a dobra sai da tela e quando alguém aperta o botão de pausa — e retoma do ponto exato em que parou, nunca do começo.

Resolve o hero de quem tem três promessas do mesmo tamanho e não consegue eleger uma. É o caso comum da assessoria: sucessão, internacional e carteira não são etapas de um funil, são três portas — e escolher uma para o topo da home significa esconder duas. A alternativa honesta seria uma lista de três cards, que não abre página nenhuma; o slideshow dá a cada porta uma tela inteira, com foto e botão próprios, e devolve o controle a quem chega pela barra de abas em vez de obrigar a esperar.

Quando usar

• Home com três frentes de negócio equivalentes, cada uma com foto editorial e um caminho adiante diferente.
• Página que aguenta uma dobra de tela cheia e cujo assunto sustenta três fotos com a mesma direção de arte.
• Quando existe material real para todas as três: foto, promessa curta e um CTA que leva a lugares distintos.

Quando não usar

• Uma promessa central. Use hero/full-bleed-media: mesma linguagem de foto sangrada e scrim, sem o custo de três fotos e sem pedir tempo a quem chega. Este componente substitui aquele só quando as frentes são três e nenhuma pode ser a primeira.
• Produto digital, onde o que convence é a frase e não a imagem. hero/centrado-prova-social.
• Quando o topo precisa mostrar interface. hero/duas-colunas-produto tem o palco com cards flutuando sobre a foto.
• Quando as três frentes são conteúdo de miolo, e não abertura. listas/leque-paineis mostra as três ao mesmo tempo, sem relógio e sem esconder nada — é quase sempre a escolha certa fora do topo.
• Mais de quatro frentes. Vira menu, não hero: midia/galeria-scroll-horizontal.
• Quando o conteúdo é prova social ou depoimento. prova/carrossel-depoimentos atravessa sem pedir clique.
• Quando a página tem um formulário acima da dobra. Uma dobra que se move ao lado de um campo de texto rouba a atenção do campo.

Padrão editorial

O que mantém a dobra coesa é o paralelismo entre os três slides: mesma quantidade de palavras na headline (±2), apoio do mesmo tamanho, botões com a mesma forma verbal. Como as três cópias ocupam a mesma célula do grid e são alinhadas pela base, uma headline de três linhas ao lado de duas de uma linha faz o bloco de texto pular de altura visualmente a cada troca — o botão fica parado, o título é que sobe.

A onda de palavras é o que dá o ritmo, e ela tem prazo: 8 palavras × 54ms + 0,9s de transição = 1,4s até a frase inteira estar em pé. Com 20 palavras seriam 2,0s de um slide de 7s só montando a frase.

Especificação dos assets

• Formato e dimensão mínima: paisagem, WebP, mínimo 2400 × 1350, ideal 3000 × 1688. A foto cobre a tela inteira, e num monitor de 2560px uma imagem de 1600 aparece esticada.
• Peso alvo: até 220 KB por foto, e isso é um teto duro. As três carregam de uma vez (loading="eager", sem lazy) porque a primeira troca acontece 7s depois de abrir, e foto que começa a baixar na hora da fusão pisca. São ~660 KB antes de a dobra assentar; a primeira é o LCP da página. Com fotos mais pesadas que isso, troque o teto por dois slides.
• Composição: assunto fora do terço esquerdo — o gradiente horizontal escurece a esquerda, que é onde o texto mora. Cada foto declara o seu corte em --cine-pos no style do <img>; o valor decide o que sobra em 390px, onde só ~26% da largura da foto fica visível.
• Direção de arte igual nas três: mesma hora do dia, mesma temperatura de cor, mesma profundidade. Três fotos de bancos diferentes lidas em sequência de 7s denunciam o banco.
• O que não pode ter: texto embutido, logo, marca d'água, rosto olhando para a câmera no terço esquerdo (fica atrás da headline) e foto clara demais para aguentar texto branco — o scrim ajuda, não salva.

Como usar

<link rel="stylesheet" href="componentes/hero/slideshow-cinematico/estilo.css">
<script src="componentes/hero/slideshow-cinematico/script.js"></script>

Cole o markup.html como primeiro filho do <body>, troque as três fotos, os três --cine-pos e o texto. Precisa do core/tokens.css, do core/base.css e — desde 2026-09-21 — do core/motion.js: é dele que vem o LIB.pausavel, a fiação do botão de pausa. Sem ele a dobra ainda abre e troca sozinha (o script lê LIB.reduce quando existe e cai no matchMedia quando não), mas o botão fica [hidden], e é ele que a WCAG 2.2.2 exige.

Ganchos

Variações

• dois ou quatro slides — acrescente ou tire um <li>, uma .cine-copy e uma aba, sempre os três juntos e na mesma ordem.
• sem troca automática — deixe um slide só: com menos de dois o script sai em silêncio e a dobra vira um hero estático, sem barra de abas.
• ritmo de vitrine — --cine-dur:5s e --cine-swap:.8s, com headlines de até cinco palavras.
• sem zoom — --cine-zoom:1, para fotos que já têm movimento próprio.
• banner de página interna — min-height:62svh na seção e no .cine-body, --cine-title menor, sem o apoio.

Gotchas

• animation … forwards não segura nada depois que a regra deixa de casar. Tirar .is-on da foto que sai apagaria o animation-name, e ela voltaria ao transform de repouso — encolheria 0,08 em um quadro, no meio da fusão. Por isso existe o .is-out: a mesma regra casa com .is-on e com .is-out, o zoom continua correndo enquanto a foto esmaece, e o script só tira a classe depois de --cine-swap. Quem "limpar" essa duplicação de seletor devolve o pulo.
• A volta rápida precisa de um layout forçado, e isso foi medido. Se a foto voltar a ser a ativa antes de a fusão terminar (dois cliques seguidos na barra), o animation-name nunca chegou a mudar — e o navegador não recomeça uma animação que já está rodando. Medido: currentTime em 2629ms; escrevendo animation:none e devolvendo animation:'' na sequência, continua 2629ms; com uma leitura de offsetWidth entre as duas escritas, volta a 0. Custo do layout forçado: 0,016ms por troca (média de 200), contra 0,002ms sem ele. É a única razão de o void el.offsetWidth estar lá — não apague.
• A pausa precisa vencer a shorthand animation em especificidade. animation:cineKen … é uma shorthand e zera todas as longhands dela, inclusive animation-play-state. A regra que aplica o zoom tem quatro classes (.cine.in .cine-slide.is-on .cine-img); a regra de pausa tem cinco (.cine.is-paused.in …) exatamente por isso. Escrita com menos, o botão de pausa "não funcionaria" — sem erro nenhum no console.
• O relógio guarda o que falta, não o que já passou. Cada pausa desconta Date.now() - t0 de restante, e a retomada agenda só o restante. Sem isso, um hover de meio segundo devolveria 7s cheios ao setTimeout enquanto a linha de progresso continuaria de onde parou, e as duas se descolariam a cada pausa — o slide trocaria com a barra pela metade.
• Aba oculta pausa de verdade, e não é firula. setTimeout em aba de segundo plano não para: o navegador apenas o afrouxa para no mínimo 1s. Sem tratar visibilitychange, quem volta depois de um minuto encontra a dobra oito slides adiante, sem ter visto nenhum. Medido: escondendo a aba, .is-paused entra no mesmo instante, o slide continua o mesmo depois de 9s, e ao voltar o relógio retoma do restante — não do começo.
• O --cine-blur cai pela metade no celular, e o número explica. A/B da mesma troca em 1440×900, headless sem GPU dedicada: com 16px, média de 4,66ms por quadro e pior quadro de 54,2ms; com 8px, média 4,21ms e pior quadro 16,8ms; sem desfoque, 4,17ms e 4,6ms. O custo é quase todo no primeiro quadro da fusão, quando o navegador precisa montar a camada desfocada de tela inteira. Em desktop, um quadro perdido no início de uma transição de 1,2s não se vê; num aparelho de entrada, se vê. Se a dobra estiver picotando no celular, baixe --cine-blur antes de mexer em qualquer outra coisa.
• O slide inativo é visibility:hidden, e não só opacity:0. Três retângulos de tela cheia com filter:blur() permanente custam memória de camada mesmo invisíveis. O visibility só troca depois da fusão (transição de 0s com atraso igual a --cine-swap), senão a foto que sai desapareceria de uma vez em vez de esmaecer. O mesmo vale para as cópias — e ali ele tem um segundo papel: tirar o botão do slide antigo da ordem de tabulação.
• inert é recente, e por isso não está sozinho. Cada cópia inativa recebe aria-hidden, inert e tabindex="-1" nos links. Medido no Chrome atual: 'inert' in HTMLElement.prototype é true, então ali as três travas são redundantes — mas inert só chegou no Chrome 102, no Safari 15.5 e no Firefox 112, e o tabindex é o que segura o resto. Sem alguma delas, o Tab entra num painel invisível e o foco some da tela.
• .is-live é o que faz a dobra existir sem JavaScript. Ele é escrito na primeira linha da inicialização, antes da primeira pintura, e faz duas coisas opostas: esconde o texto (para a coreografia ter de onde sair) e acende a barra de abas. Sem script, nenhuma das duas acontece — a dobra abre inteira, com o primeiro slide pronto e sem três botões que não levam a lugar nenhum. Se alguém "simplificar" pondo o estado inicial direto no .cine-w, a página sem JS fica com a headline invisível.
• min-height aparece duas vezes, com valores diferentes, e está certo. 100vh e logo abaixo 100svh: onde svh existe, a segunda linha vence e a dobra para de vazar um pedaço sob a barra do navegador no celular; onde não existe, a primeira continua valendo. Não dá para resolver isso com uma variável — custom property aceita qualquer token, então --h:100svh seria aceita em um navegador antigo e só falharia no var(), deixando a altura em auto.
• O relógio começa na abertura, não no window.load. Esperar as três fotos atrasaria a headline no primeiro acesso, e o load pode nunca chegar se um recurso qualquer da página travar. A consequência assumida: em conexão ruim, o zoom da primeira foto pode começar antes de ela pintar. O que o load garantiria — não trocar de slide no instante em que a página abre — já está garantido de outro jeito: a primeira troca é sempre --cine-dur depois da abertura.
• A pausa por ponteiro é só no texto e nas abas. Na seção inteira seria pior que não ter: a dobra ocupa a tela toda, e um ponteiro parado em qualquer canto congelaria o carrossel para sempre — sem que ninguém entendesse por quê.
• O arrasto não captura o ponteiro e não cancela nada. setPointerCapture retargetaria o clique para a seção e o botão do slide deixaria de abrir no toque; preventDefault mataria a rolagem vertical da página. O navegador resolve sozinho: num gesto vertical ele começa a rolar e dispara pointercancel. O limiar é 40px e domínio horizontal (|dx| > |dy|) — sem a segunda condição, rolar com o dedo trocaria de slide.
• A seta do teclado leva o foco para a aba do slide novo, sempre. Quem apertou → estando no botão do slide anterior ficaria com o foco dentro de uma cópia que acabou de sair da árvore, e o navegador o devolveria ao <body> — a pessoa perde o lugar na página. Home/End, ao contrário das setas, só valem com o foco numa aba: fora dali, elas pertencem à página.
• O botão de pausa não é enfeite de acessibilidade. A dobra troca sozinha por mais de cinco segundos, e a WCAG 2.2.2 pede um jeito explícito de parar. Hover não conta (não existe no toque) e foco não conta (quem usa leitor de tela em modo de leitura não move o foco). Com movimento reduzido o botão some, porque aí não há troca automática para pausar.

Histórico

Origem. Componente autoral (contrato §11): não é clone de uma referência, é a tradução de um padrão de interação que aparece em muito site premium — o herói rotativo das plataformas de streaming, com a fileira de abas e a barra que enche; as páginas de produto da Apple e da Nike, com foto de tela cheia em zoom lento; os templates de hero premiados no Awwwards e vendidos em Framer e Webflow. Não há URL de referência e não há uma linha copiada: o arquivo nasceu aqui, em token, prefixo, primitiva do core e padrão ARIA. Status externo: nunca rodou em produção nossa. O primeiro site que usar promove, e esta ficha registra qual foi. O registro consolidado vai em projetos/autorais.md.

Decisões de tradução para o contrato:

• Um relógio só. O padrão de mercado costuma ter o tempo do slide no JavaScript e a duração da barra no CSS, e os dois desandam na primeira revisão. Aqui existe --cine-dur, e o script a lê com getComputedStyle — o zoom, a barra de progresso e o setTimeout nunca podem discordar.
• Nada entra seco (§5). A fusão do original de mercado é opacity pura. Aqui a foto que entra vem de blur(16px) a zero e a que sai faz o caminho contrário; a headline entra palavra a palavra, com blur e subida.
• Palavra a palavra por span com índice, não por data-split. O gancho do core quebra o texto em .w e dispara uma vez, quando o bloco entra na tela; aqui a mesma frase precisa reentrar a cada troca. É a mesma decisão do hero/centrado-prova-social, e pelo mesmo motivo adicional: .w é classe do core, que componente não pode estilizar — sem poder estilizar, não há como escalonar.
• Cor por token. Scrim em rgba(var(--dark-rgb),…), texto e abas em --light com color-mix (a dobra é uma ilha escura, então lê --light e não --fg, e continua legível numa página de escopo claro), linha de progresso em --accent, grão pela primitiva .grain do core.
• Medida por variável. Duração, fusão, desfoque, escala do zoom, passo da onda e corpo do título viraram --cine-* na raiz do componente; o corte de cada foto é --cine-pos inline, como em midia/carrossel-perfis.
• Acessibilidade que o padrão de mercado quase nunca tem: padrão "carousel with tabbed slide picker" do W3C APG, com aria-roledescription="carrossel" na seção e "slide" em cada painel; role="tablist" de verdade com roving tabindex (uma parada de Tab para a barra inteira); aria-controls/aria-labelledby amarrados pelo script, com ids únicos por instância, porque id em markup de biblioteca colide na primeira página que repetir a dobra; aria-live que só liga quando o relógio está desligado, para o leitor de tela não ser interrompido a cada 7s; pausa explícita por botão (WCAG 2.2.2) somada à pausa por ponteiro, por foco, por aba oculta e por saída da tela; e o desligamento completo do relógio em movimento reduzido, com as abas continuando a funcionar.
• Movimento reduzido desliga o relógio, não a dobra. Medido com prefers-reduced-motion: reduce: nada troca sozinho em 8,6s (a aba ativa continua sendo a 0), animation-name do <img> é none, a foto fica em scale(1), a barra da aba ativa fica cheia (vira marcador estático em vez de mentir que está contando), as palavras entram juntas e sem blur, e o botão de pausa não chega a ser ligado: o script não chama o LIB.pausavel e o botão fica [hidden] como nasceu (display:none, sem data-pausado). Botão que não comanda nada é pior que botão nenhum. As abas continuam trocando de slide — gesto pedido pela pessoa não é movimento imposto a ela.
• A copy dos rótulos mora no markup, não no script. Até 2026-09-21 as duas frases ("Pausar a troca automática" / "Retomar a troca automática") eram strings dentro do script.js — copy em JavaScript, onde nenhum redator vai procurar. Hoje são data-rot-pausar e data-rot-tocar no <button>, e quem as escreve no aria-label é o core.
• Não há aria-pressed no botão, e é decisão. O rótulo troca, que é o padrão de controle de mídia; somar aria-pressed a um nome que muda produz o anúncio duplo e contraditório "Retomar, pressionado". O estado mora no nome ou no atributo, nunca nos dois — está explicado no comentário do .btn-play no core/base.css.