Lista de benefícios com palco ilustrado

Duas colunas, aproximadamente 7/5. À esquerda um palco: uma foto com quatro peças soltas boiando em volta dela — um cartão de patrimônio consolidado meio dentro e meio fora da imagem, uma confirmação de ação concluída no alto, um arco que sai por baixo do cartão e uma linha pontilhada que atravessa a foto ligando a confirmação ao cartão. À direita, quatro benefícios em lista: ícone em círculo, título com pílula opcional, uma frase, um link opcional com seta e um filete de 2px separando um do outro, mais um botão fechando a coluna.

O que ela resolve: a dobra "por que trabalhar com a gente" nos dois registros ao mesmo tempo. A coluna da direita argumenta; o palco da esquerda mostra. Uma foto sozinha não diz o que a assessoria entrega — vira banco de imagem com legenda. Quatro parágrafos sozinhos não têm imagem nenhuma e a dobra fica seca no meio de uma página que tem foto em todas as outras. O palco fecha esse vão sem pedir um segundo componente: as peças flutuantes são um retrato do produto — o relatório consolidado existe, o mês fecha, alguém confirma.

Zero JavaScript. A entrada é o [data-rv] do core, a boiada é uma animação CSS e o resto é layout.

Quando usar

• A dobra de diferenciais logo depois do hero, quando existe foto boa E existem quatro argumentos que precisam ser lidos.
• Quando o produto tem uma tela — relatório, portal, app — e mostrar um pedaço dela vale mais que descrevê-la.
• Quando a dobra precisa terminar em ação. O botão é parte da peça, não um enfeite: a lista constrói o argumento e ele recolhe.
• Entre três e cinco benefícios. Abaixo de três a coluna direita fica curta demais para o palco ao lado; acima de cinco o filete vira uma tabela.

Quando não usar

• Acima da dobra. Isto não é hero — não tem headline de abertura nem --nav-h na conta. O irmão de hero é hero/duas-colunas-produto.
• Sem foto que aguente peça por cima. Foto com o assunto espalhado por todo o quadro não tem onde receber cartão e confirmação. Ver a especificação de assets: se a foto não tiver duas zonas quietas, use conteudo/imagem-lista-numerada.
• Quando o dado do cartão for resultado. Rentabilidade, ganho, comparação com índice — nada disso entra. Ver Compliance.
• Quando a interface a mostrar for o assunto inteiro. Aí a dobra é conteudo/trio-cards-ui-simulada, que dá três telas em vez de uma foto.

Os irmãos, e o que cada um resolve que este não

Padrão editorial

O que mantém a peça coesa: os quatro benefícios têm de ser da mesma natureza (todos entregas, ou todos princípios) e de comprimento parecido. Um item de uma linha ao lado de outro de três desmonta o ritmo do filete, que é o que sustenta a coluna inteira.

Especificação dos assets

Uma foto, e ela é a peça que mais escolhe mal.

• Formato e dimensão mínima: paisagem, 1600×900 ou maior. O recorte final é ~1,23:1 (564×458 numa coluna de 1240) — quase quadrado, então a foto perde as laterais no object-fit:cover.
• Peso alvo: até 180 KB em WebP a 75.
• Composição: o assunto vive no terço central, na metade alta do quadro. Duas zonas têm de ficar quietas, porque é onde as peças pousam: o canto inferior esquerdo (cartão e arco, até 36% da largura e da metade da altura para baixo) e o canto superior direito (confirmação, de 69% a 87% da largura, no topo). Uma faixa diagonal entre as duas recebe a linha pontilhada.
• O que não pode ter: rosto na trajetória da linha pontilhada (a curva foi desenhada para passar por cima das cabeças desta foto — outra foto pede outra curva); texto embutido na imagem; marca, logo ou tela de instituição real; qualquer coisa que sugira retorno.

O preview usa showroom/demo/ph-wide-1.webp, que é placeholder — troque por foto do cliente ao consumir.

Como usar

<link rel="stylesheet" href="componentes/conteudo/lista-beneficios-palco/estilo.css">

Não há script.js. O core (motion.css + motion.js) já entrega a entrada.

Ganchos

Variações

• palco sem peças — apague os quatro .benf-slot. Sobra a foto na proporção do palco, e a dobra vira duas colunas comuns. É a versão mais barata do componente, e é exatamente o que sobra sozinho abaixo de 640px. Estável.
• peças em outra pose — troque --benf-x/--benf-y/--benf-w. Cartão e confirmação são independentes; a linha pontilhada não é — a geometria dela é combinada com as duas pontas. Estável.
• três benefícios — apague um <li>. O filete se ajusta sozinho, e a coluna esquerda continua alta porque a altura dela vem do palco, não da lista. Estável.
• palco à direita — inverta a ordem dos dois filhos do .benf-grid. Nada mais muda: o palco não sabe de que lado está. Serve para alternar com a dobra vizinha. Estável.
• em dobra clara — troque .sec-dark por .sec-paper. A lista acompanha sozinha, mas as peças de papel deixam de contrastar com o fundo: inverta o escopo delas para .sec-dark e revise a sombra, que é calculada para peça clara sobre escuro. Experimental — não foi exercitada.

Gotchas

• data-rv no invólucro, peça por dentro — e isso não é preferência, é a única forma que funciona. Cada peça boia com transform próprio. O core termina o reveal com [data-rv].in{transform:none}, seletor de especificidade (0,2,0) contra a (0,1,0) de .benf-piece. Com os dois atributos no mesmo nó, o transform:none vence assim que a dobra entra: o @keyframes continua rodando, nenhum erro aparece no console, e a boiada simplesmente deixa de existir. Por isso o data-rv mora em .benf-slot, que só posiciona, e o .benf-piece fica livre por dentro. Medido no preview depois da entrada: os quatro .benf-slot computam transform: none (a entrada terminou) enquanto os quatro .benf-piece computam matrizes vivas (matrix(1,0,0,1,0,-5.78) e vizinhas). Mesma separação de efeitos/inclinacao-3d com .tilt-card-slot.

• left/right/top/bottom + width:auto não dimensiona uma <img>. Elemento substituído com dimensão automática resolve pelo tamanho intrínseco do arquivo; o right/bottom viram excesso e o navegador os descarta. Medido no Chrome com uma foto 1600×900 num palco de 602×458: a imagem saiu 602×339 — a largura toda (pelo max-width:100% do core) e só 74% da altura, com as peças de baixo boiando sobre fundo vazio. A regra tem width:calc(100% - var(--benf-photo-inset)) e height:100% justamente por isso. Trocar por inset "para simplificar" traz o bug de volta.

• A boiada é @keyframes, e não um laço em requestAnimationFrame. O §5 pede animação por tempo, com dt limitado — a regra existe porque um laço que anda por quadro acelera em 120Hz e salta ao voltar de uma aba em segundo plano. Animação CSS já é por tempo na origem: o navegador interpola pelo relógio do documento, pausa junto com a aba e não tem dt nenhum a limitar. Escrever o equivalente em JS seria mais código para chegar ao mesmo lugar com mais jeitos de errar. Precedente: o stageBob de hero/duas-colunas-produto.

• As quatro peças têm fases diferentes, e isso é o efeito. Em fase igual elas sobem e descem juntas, a foto inteira parece respirar e o truque aparece. Os --benf-bob-delay negativos existem para cada uma nascer no meio do próprio balanço, em vez de as quatro partirem paradas do mesmo ponto. "Padronizar os tempos" mata a peça.

• A linha pontilhada é desenhada duas vezes. A de baixo é um halo escuro mais largo (.benf-link-halo, em rgba(var(--dark-rgb),.5)). Sem ele, um pontilhado de 3px em --accent some na metade clara de qualquer foto — e a linha é justamente a peça que atravessa a imagem inteira, encontrando céu, terra e sombra no mesmo caminho. Apagar o halo devolve a linha invisível.

• A curva da linha sobe antes de descer. Em sag suave ela passava por cima dos rostos do casal do preview — medido, o traço cortava a cabeça do homem. A curva atual corre pelo alto do quadro e só mergulha no último terço. Foto com o assunto em outra posição pede outra curva: o d do <path> é conteúdo, não infraestrutura.

• O botão mora fora do <ul>. Dentro, ele seria o último <li>, e .benf-item:last-child deixaria de casar com o quarto benefício — o filete voltaria justamente onde ele não pode existir. Fora, a regra é uma linha só, sem :has() nem :nth-last-child a contar irmãos.

• O canto das peças é do tema, não da peça. A referência mede 12px, mas --benf-piece-radius nasce em var(--radius-media): em projeto flat (Liberta, Tarvos) as peças saem de canto vivo, e está certo — quem decide a forma é o tema (§10). Quem quiser o arredondado da referência num tema flat troca a variável no consumidor, sem tocar em regra.

• O arco vai antes do cartão no markup. Quatro absolutos irmãos empilham na ordem do DOM, e é assim que o arco fica atrás e a linha pontilhada fica à frente. Reordenar o HTML "por legibilidade" põe o arco por cima do cartão e o ponto da linha por baixo dele — nenhum z-index está envolvido, de propósito.

• A entrada da confirmação é data-d="2" e a da linha data-d="3", mesmo a linha vindo antes no markup. Uma ligação só faz sentido depois das duas pontas existirem. O data-d controla o tempo; a ordem do DOM controla o empilhamento. As duas coisas são independentes aqui.

Compliance

A dobra mostra um número. Antes de publicar, o consumidor tem de trocar ou apagar:

As três regras que decidem a forma, e não só o texto:

1. Estoque e composição, nunca resultado. Patrimônio consolidado é quanto existe; rentabilidade é quanto rendeu. A peça só pode dizer a primeira coisa. "Sua carteira rendeu X" quebra a dobra no sentido que importa, e nenhum validador vai reclamar.
2. A ressalva fica onde a pessoa lê o número. A pílula ilustrativo é a primeira linha do cartão, e não uma nota de rodapé que ninguém desce para ver. Precedente: dados/painel-patrimonio.
3. Nenhum nome real. Sem cliente, sem instituição, sem logo — nem na foto, nem no cartão.

Acessibilidade e compliance se encontram aqui: as quatro peças são aria-hidden="true". São ornamento, e ler "R$ 12 mi" fora de contexto num leitor de tela transformaria uma ilustração numa afirmação. O argumento inteiro mora na lista ao lado, que é conteúdo de verdade. É a mesma decisão de conteudo/trio-cards-ui-simulada e dados/painel-patrimonio para interface simulada — e é o que torna legítimo escondê-las inteiras no celular.

Sem captura de dado e sem localStorage. A dobra não guarda nada de ninguém.

Celular — a decisão de forma, e por que ela é essa

Abaixo de 640px as quatro peças saem e a foto fica.

A referência esconde o palco inteiro (m:hidden no contêiner). Esconder as peças é inegociável e a referência está certa nisso: quatro objetos absolutos sobre 350px de largura viram sopa, e o cartão — 36% do palco — ficaria mais largo que a metade útil da foto. Mas levar a foto junto seria jogar fora a única metade da composição que atravessa intacta, e a dobra "por que trabalhar com a gente" sem imagem nenhuma vira uma lista comum — que a biblioteca já tem, em conteudo/imagem-lista-numerada.

A terceira via só é honesta porque não se perde conteúdo: as peças são aria-hidden justamente por serem ornamento. Se algum dia o cartão carregar informação que não esteja na lista, esconder deixa de ser aceitável e a peça precisa reempilhar.

Ao esconder as peças, duas coisas mudam junto: a calha da esquerda (--benf-photo-inset) vai a zero, porque não há mais o que pousar nela, e o palco fica mais baixo (16/11), porque em largura cheia o 696/530 empurra a lista para fora da primeira tela.

Entre 640 e 980px a dobra já é de uma coluna, mas o palco não ganha a largura inteira: ele tem teto de 560px e centraliza. As peças são dimensionadas em vw e a caixa em %, então um palco de 900px produziria um cartão de 320px com tipografia de 17px — esparso e errado.

Histórico

Origem: clone de referência visual, não origem de código. A URL acima é registro do que foi visto, nunca de onde veio arquivo. Licença de site no ar nunca é clara, e a regra do §11 decide sozinha: não se copia — se reescreve. Da referência vieram a ideia da composição, a proporção das duas colunas, o tamanho relativo das peças e o ritmo da lista. Nenhuma linha de HTML, CSS ou JS atravessou. Registro consolidado em projetos/referencias-externas.md, seção Clones.

Medidas de partida, do mapa da referência: coluna de 1264 em 12 colunas, com .destaque de 696 e .itens de 488 (~7/5); palco .mulher de 696×530 com a foto de 652×530 recuada 44 à esquerda; cartão 248×140 no canto inferior esquerdo (raio 12, sombra 0 10 20), toast 112×97 no alto à direita (raio 12, sombra 0 14 29), arco de 190×95 embaixo à esquerda, linha pontilhada de 61×60 e um ponto de 14 abaixo do toast; à direita ul com gap 40, ícone 52×52, h3 20/26 com badge "Novo", p 16/24, bloco com borda inferior de 2px, e botão 252×56 com mt-40.

O que mudou na tradução:

• Px viraram porcentagem do palco. A referência crava posição em pixel; aqui as quatro peças leem % de .benf-stage, e é isso que faz a composição sobreviver a qualquer largura de coluna.
• A linha pontilhada passou a ligar de fato. Na referência ela termina num ponto solto abaixo do toast, sem tocar o cartão. Aqui a curva vai da confirmação até a borda direita do cartão — a peça deixou de ser floreio e virou uma relação.
• As peças ganharam boiada contínua e dessincronizada, que a referência não tem. É o que as faz ler como objetos soltos em vez de adesivos colados.
• O disco de ícone escuro virou véu do acento. A referência é dobra clara; esta é escura, e um disco escuro sobre escuro desapareceria.
• O conteúdo trocou de assunto por inteiro. Despesa doméstica virou assessoria: relatório consolidado, carteira acompanhada, acesso ao assessor, independência de remuneração. O "Chega de planilhas" da referência não sobreviveu de propósito — a voz é outra.
• O número ganhou ressalva na própria peça e passou a ser estoque e distribuição, nunca resultado.
• O celular ficou no meio-termo: a referência esconde o palco inteiro, aqui a foto fica e só as peças saem.
• Não atravessaram: as fontes (Jakarta e Inter da referência — aqui --display/--sans do tema), os ícones proprietários (redesenhados aqui em traço simples), a foto e as cores de marca (--accent/--accent-2 do tema, zero cor crua).

Normalizações aplicadas na extração: prefixo benf- em toda classe; toda cor por token, sem exceção; entrada pelo [data-rv]/data-d do core em vez de observer próprio; .wrap, .sec-pad, .eyebrow, .sec-title, .pill, .pill-accent, .btn/.btn-primary consumidos do core sem recópia; escopo de tom .sec-light declarado nas peças claras em vez de cor de texto escrita à mão; peças decorativas em aria-hidden e focusable="false" nos SVG; @media(prefers-reduced-motion) colado a cada regra que ele desliga; media queries de largura no fim do arquivo.

Divergências conhecidas vs. a referência: o ritmo da lista fechou de 40 para 34 (gap) e de 24 para 21 (respiro do filete) — o título desta dobra corre uma linha a mais que o dela, e com os valores originais a lista terminava 139px abaixo do pé da foto, com o botão pendurado no vazio. Depois do ajuste a diferença é de 103px numa dobra de 1049, e a coluna esquerda é a mais curta das duas (na referência é a mais longa).

Verificação (Chrome headless, bin/medir.js).

1440×900 — seção 1049px, palco 602×458 (proporção 1,314), foto 564×458 preenchendo o palco, grade 602px 430px (7/5 exato). As quatro peças dentro dos limites do palco, em % dele (posição de repouso, sem a boiada): arco 1–51% × 63–88,6%; cartão 0–36% × 51–78,1%; linha 34–68% × 30–55,5%; confirmação 69–87% × 8–29,1%. Zero overflow horizontal, console limpo, nenhuma imagem sem pintar. Três focáveis, na ordem do DOM (dois links de item, depois o botão), com anel de 2px e offset 3px; nada focável dentro de aria-hidden.

Rolando a dobra (--scroll=0.6) — a prova da armadilha do data-rv: os quatro .benf-slot com classe .in, opacidade 1 e transform: none (a entrada terminou), enquanto os quatro .benf-piece computam matriz viva (matrix(1,0,0,1,0,-3.19), -5.79, -4.87, -8.46) com animation-name: benfBob. Com os dois atributos no mesmo nó, a segunda linha leria none.

--reduce — animation-name: none e transform: none nas quatro peças, todas inteiras, legíveis e na posição de repouso declarada. Nada de movimento contínuo; nada escondido.

390×844 — uma coluna, palco 350×241 com a foto preenchendo, as quatro peças em display:none, zero overflow horizontal, console limpo.

Varredura de largura (1920, 1280, 1100, 1000, 900, 768, 700, 660, 640, 560, 390, 360) — zero overflow horizontal em todas, e em todas as larguras de composição visível (1920 a 660) as quatro peças permanecem dentro do palco. O palco vai de 614×468 (em 1280, onde a coluna é mais larga) a 489×373 (em 1000, o menor da faixa de duas colunas) e fica travado em 560×426 entre 980 e 660. A partir de 640 as peças somem, como previsto.