/* Weex Design System — Responsivo: breakpoints & esqueletos de página */ /* BREAKPOINTS CANÔNICOS (contrato — CSS vars NÃO funcionam dentro de @media, então estes números são definidos SOMENTE aqui e documentados na guideline "Responsivo". Nunca invente um terceiro número numa tela.) COMPACT ≤ 680px telefone — paddings encolhem, nav vira linha rolável MEDIUM 681–960px tablet / janela estreita — rail desce, sidebar admin vira trilho WIDE > 960px desktop — layout de referência (como as telas foram desenhadas) Por que classes e não inline: media query não existe em style="" — estas classes vivem no CSS global (styles.css), que toda tela já carrega no , então pintam imediatamente (sem custo de streaming do DC). */ /* ── ESQUELETO DE PÁGINA DO PARTICIPANTE ── Container + grid principal (conteúdo + rail 308px). Substitui o par inline `max-width:1180px …` + `grid-template-columns: 1fr 308px` repetido nas telas. */ .weex-page { max-width: 1180px; margin: 0 auto; padding: var(--space-24) var(--space-32) var(--space-64); /* Trava anti-scroll-lateral: popovers de hover (tooltips de conquista) e afins ficam no layout mesmo escondidos e, num rail estreito, ultrapassam a borda. `clip` corta só a horizontal SEM virar contêiner de rolagem — logo não quebra o position:sticky (ao contrário de overflow:hidden). */ overflow-x: clip; } .weex-page-grid { display: grid; grid-template-columns: minmax(0, 1fr) 308px; gap: var(--space-24); align-items: start; } .weex-page-grid > * { min-width: 0; } /* colunas sempre podem encolher */ /* ── ESQUELETO "EDITOR COM PRÉVIA" (admin) ── Editor à esquerda + prévia do participante à direita. Vale para o template de configuração de atividade e para a Configuração do Game, que nasceu copiando dele. POR QUE VIROU ESQUELETO COMPARTILHADO: as duas telas repetiam o mesmo par inline (`max-width:1360` + `display:flex; gap:24` + prévia `flexShrink:0; sticky; top:84`) e por isso repetiam os mesmos defeitos — o `top: 84` é resto da topbar que morreu quando o editor passou a abrir sempre embutido (`?embed=1`), e a prévia rígida comia a coluna de edição. A CONTA QUE JUSTIFICA A LARGURA: o editor abre num AzDrawer de `min(960px, 94vw)`. Com prévia de 512, sobravam 912 − 512 − 24 = 376px para escrever, num monitor de 27 polegadas. A prévia é 412 porque o conteúdo dela sempre foi 412 (390 de tela do participante + 11+11 de moldura); os outros 100 eram ar de centralização. A edição passou a 476. Ao mexer aqui, refaça a conta com a largura do drawer. MEDIUM (≤880) é ARRANJO: a prévia desce. `align-items` TEM de virar `stretch`, senão ele alinha no eixo cruzado (que em coluna é o horizontal) e o formulário encolhe para a largura do próprio conteúdo. COMPACT (≤680) é DENSIDADE: só o respiro muda. */ .weex-editor-page { max-width: 1360px; margin: 0 auto; padding-top: var(--space-24); padding-inline: var(--space-24); padding-bottom: 96px; } /* UMA TELA, UM SCROLLER — E O SCROLLER É O FORMULÁRIO (ago/2026). A prévia da direita tinha de ficar à vista enquanto se edita um campo do fim da coluna da esquerda. Tentei três vezes com `position: sticky` e falhou fora daqui, porque sticky depende de duas coisas que o editor NÃO controla: qual elemento é o scroller (ele abre embutido num painel lateral, dentro de um iframe) e até onde vai o container do painel. A solução deixa de fazer a pergunta: a PÁGINA não rola (quadro de altura fixa), rola a COLUNA DA ESQUERDA. A prévia não "volta" com a rolagem — ela nunca sai. Se algum dia precisar voltar ao fluxo normal da página, tire `.weex-editor-frame` do elemento: as duas colunas voltam a rolar juntas, sem depender de sticky. */ .weex-editor-page.weex-editor-frame { height: 100dvh; max-height: 100dvh; overflow: hidden; padding-bottom: 0; display: flex; flex-direction: column; } .weex-editor-frame > .weex-editor-split { flex: 1; min-height: 0; align-items: stretch; } .weex-editor-frame .weex-editor-preview { max-height: 100%; min-height: 0; } /* No quadro a prévia não pode passar da altura disponível: não há rolagem de página para revelar o resto. Cada prévia cede pela ALTURA, e nas duas telas que existem hoje isso quer dizer o aparelho encurtando pela escala, nunca pela forma. */ .weex-editor-split { display: flex; gap: var(--space-24); align-items: flex-start; } .weex-editor-form { flex: 1; min-width: 0; } .weex-editor-frame .weex-editor-form { min-height: 0; overflow-y: auto; overscroll-behavior: contain; padding-bottom: 96px; scrollbar-width: thin; scrollbar-color: rgba(15, 8, 30, .18) transparent; } /* COLUNA QUE ROLA É COLUNA FLEX DE ALTURA FIXA — E ENTÃO OS FILHOS ENCOLHEM. Num `flex-direction: column` com altura definida, o padrão `flex-shrink: 1` faz cada filho ceder para o conteúdo "caber", em vez de a caixa rolar. Quem tem texto se defende pelo min-content; quem é `overflow: hidden` (o acordeão das Configurações avançadas) tem min-content 0 e **desaba para a altura das próprias bordas** — 2px, aberto ou fechado. Foi o que sumiu quando o quadro entrou. Filho de scroller não encolhe. O segundo seletor existe porque o mount do `x-import` é `display: contents`: o filho real é que vira item flex, e `> *` sozinho acerta o invólucro, não o componente. */ .weex-editor-frame .weex-editor-form > *, .weex-editor-frame .weex-editor-form > .sc-host-x > * { flex-shrink: 0; } /* BARRA DE ROLAGEM MINIMALISTA — mesma gramática da navegação do Index (fio fino, trilho transparente, polegar translúcido que escurece no hover), traduzida para superfície clara. A borda transparente com background-clip é o que dá o ar em volta do fio sem pintar trilho. */ .weex-editor-frame .weex-editor-form::-webkit-scrollbar { width: 8px; } .weex-editor-frame .weex-editor-form::-webkit-scrollbar-track { background: transparent; } .weex-editor-frame .weex-editor-form::-webkit-scrollbar-thumb { background: rgba(15, 8, 30, .18); border-radius: var(--radius-full); border: 2px solid transparent; background-clip: padding-box; } .weex-editor-frame .weex-editor-form::-webkit-scrollbar-thumb:hover { background: rgba(15, 8, 30, .32); background-clip: padding-box; } /* 308px = a moldura de 382 (360 de tela + 11+11) exibida a .806 — ver o palco mobile do template de configuração. O viewport da prévia segue 360px, celular convencional; só a exibição encolhe, porque 1px de CSS no monitor é físico e no celular é ~1/3 — 1:1 o aparelho desenhado fica com ~10cm de largura e deixa de ler como celular. A coluna é o conteúdo real, nunca ar de centralização (ver SPEC do platform). */ .weex-editor-preview { width: 308px; flex-shrink: 0; align-self: flex-start; display: flex; flex-direction: column; gap: 12px; } /* No quadro a prévia é estática e está sempre na tela — nada de sticky, nada de teto de altura calculado contra a viewport. Fora do quadro (uma página que role inteira) ela ainda se agarra, agora como cortesia e não como mecanismo. ALTURA encurta, LARGURA não: largura é o que a prévia está provando. */ .weex-editor-page:not(.weex-editor-frame) .weex-editor-preview { position: sticky; top: var(--space-16); max-height: calc(100dvh - var(--space-16) - var(--space-16)); } @media (max-width: 880px) { /* 880 NÃO É BREAKPOINT DE DISPOSITIVO, é a largura em que o par deixa de caber — e por isso não usa o MEDIUM canônico. O editor abre num drawer de `min(960px, 94vw)`, que dá EXATAMENTE 960 em qualquer monitor: com `max-width: 960px` (inclusiva) o caso principal do desktop empilhava. A conta: prévia 412 + gap 24 + mínimo utilizável de edição ~380 + padding 48 = 864, arredondado para 880. Em 960 sobram 476 para escrever, que era o objetivo da mudança. */ /* NO ESTREITO O QUADRO SE DESFAZ: rolagem única da página, prévia embaixo. Scroller dentro de scroller no celular é pior que rolar a página — e com a prévia empilhada não há coluna vizinha para manter à vista. */ .weex-editor-page.weex-editor-frame { height: auto; max-height: none; overflow: visible; display: block; padding-bottom: 96px; } .weex-editor-frame .weex-editor-form { overflow: visible; padding-bottom: 0; } .weex-editor-split { flex-direction: column; align-items: stretch; } .weex-editor-preview { width: 100%; position: static; max-height: none; } } @media (max-width: 680px) { /* LONGHAND DE PROPÓSITO: com `padding` shorthand, qualquer tela que precise só do rodapé (barra fixa mais alta no compact, por exemplo) tem o override resetado em silêncio pela regra compartilhada. Ao editar aqui, não volte para o atalho. */ .weex-editor-page { padding-top: var(--space-16); padding-inline: var(--space-16); } } /* ── MOLDURA DE APARELHO DA PRÉVIA (390 × 844, escala derivada --mb-k) ── UMA RÉGUA SÓ DE MOBILE: o mesmo aparelho do `DEVS.mobile` do launcher de dispositivo e do harness do participante. Nasceu no helmet do template de configuração de atividade e virou folha compartilhada em ago/2026, quando o "Cadastro do Game" passou a precisar dela — moldura desenhada duas vezes é a definição do drift que esta folha existe para impedir. APARELHO INTEIRO, SEMPRE: quando falta espaço quem cede é a ESCALA, nunca a forma. Cortar altura entrega ~1:1,4 onde um celular é 1:2,16, e lê como aparelho cortado. 412 = 390 + 11 + 11 de moldura · 866 = 844 + 11 + 11. Fallback .7476 = 308/412. Quem escreve --mb-k é o JS que mede o painel (nunca uma divisão por var() dentro de calc: o lado direito de `/` tem de ser número, e o motor que recusa mata a altura). */ .weex-mb-palco { position: relative; width: 100%; height: calc(866px * var(--mb-k, .7476)); } .weex-mb-aparelho { position: absolute; top: 0; left: 50%; width: 412px; padding: 11px; background: #1b0b34; border-radius: 46px; box-shadow: 0 16px 44px rgba(20, 8, 40, .28); transform: translateX(-50%) scale(var(--mb-k, .7476)); transform-origin: top center; } .weex-mb-tela { position: relative; width: 100%; height: 844px; border-radius: 36px; overflow: hidden; background: var(--color-bg-brand); } .weex-mb-tela iframe { width: 100%; height: 100%; border: 0; display: block; } /* ── GRIDS ESTRUTURAIS REUTILIZÁVEIS ── */ /* 2 colunas iguais (admin e participante) — empilha no COMPACT */ .weex-grid-2 { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: var(--space-16); } /* fileira de KPIs do admin — 4 → 2 no MEDIUM (2×2 segura bem até o telefone) */ .weex-grid-kpi { display: grid; grid-template-columns: repeat(4, minmax(0, 1fr)); gap: 12px; } /* ── PRÉVIA DA CONFIGURAÇÃO: SEM PERCURSO ── A tela da atividade embutida com `?percurso=0` esconde o rail (o Percurso é o único ocupante dele em todas as 9 telas de atividade). Motivo: na prévia do editor o painel de percurso fala do DIA — blocos, gate, frações de outras atividades — e nada disso é configurável ali; quem configura quer ver a atividade. Esconder o CONTAINER, e não apenas o componente, evita a coluna de 308px vazia na prévia desktop. O atributo é escrito pelo participant-harness.js, dono do contrato `?deviceframe=1`. */ html[data-weex-percurso="off"] .weex-rail { display: none !important; } /* `display:none` esconde o ITEM, não apaga a TRACK: a grade declara `1fr 308px`, então sem esta linha a atividade ficava presa em 784px com 332px de gutter vazio (medido). Grade explícita precisa de colapso explícito. */ html[data-weex-percurso="off"] .weex-page-grid { grid-template-columns: minmax(0, 1fr); } /* ── MEDIUM (≤ 960px) ── */ @media (max-width: 960px) { .weex-page-grid { grid-template-columns: minmax(0, 1fr); } /* rail desce para baixo do conteúdo */ /* Rail marcado como .weex-rail (o Percurso das telas de atividade): em coluna única ele fica SEMPRE DEPOIS do conteúdo (order:1, independente da ordem do DOM). Acima da atividade, ocupando a primeira tela, ele passa a parecer a atividade em si — o contexto se disfarça de conteúdo. Sai do sticky para não flutuar sobre o conteúdo; o próprio componente nasce colapsado numa linha em ≤960, então o rodapé fica curto. */ .weex-page-grid > .weex-rail { order: 1; position: static !important; } .weex-grid-kpi { grid-template-columns: repeat(2, minmax(0, 1fr)); } .weex-hide-medium { display: none !important; } } /* ── COMPACT (≤ 680px) ── */ @media (max-width: 680px) { .weex-page { padding: var(--space-16) var(--space-16) var(--space-48); } .weex-grid-2 { grid-template-columns: minmax(0, 1fr); } .weex-hide-compact { display: none !important; } } /* Visível SÓ no compact (ex.: atalho mobile). Use com moderação. */ .weex-only-compact { display: none !important; } @media (max-width: 680px) { .weex-only-compact { display: revert !important; } } /* Tabelas densas do admin nunca espremem colunas: rolam na horizontal. */ .weex-scroll-x { overflow-x: auto; -webkit-overflow-scrolling: touch; } /* Tabelas com cabeçalho fixo (DS Table com stickyHeader) dentro de .weex-tbl-hscroll. LARGURA (set/2026): a passa a table-layout:fixed. No layout automático o texto sem quebra das células (área "Sudeste › Fábrica São Paulo", CPF) ditava a largura mínima de cada coluna, o text-overflow:ellipsis nunca agia e a tabela (~720px de conteúdo) estourava o cartão e a página em qualquer janela abaixo de ~850px (iPad em pé, celular deitado). No layout fixo as colunas com `width` ficam com ela, as demais (Nome, Área) dividem o que sobra e truncam: a tabela nunca passa dos 100% do cartão. ROLAGEM: abaixo do TABLET (960px, onde o casco já recolhe a sidebar) a caixa de rolagem lateral é o wrapper INTERNO da Table (o div que contém a
), não o cartão — borda, fundo e rodapé de paginação ficam na largura da página e só as linhas rolam. Rolando o cartão inteiro, as células passavam da moldura. `!important` porque esse wrapper leva overflow:visible inline (é o que deixa o sticky escapar no desktop). Nessa faixa o sticky do cabeçalho é sacrificado de propósito em troca da rolagem lateral, como já era no compact. No desktop fica tudo overflow:visible pro position:sticky do cabeçalho funcionar — overflow-x:auto criaria uma caixa de scroll que rouba o sticky (ver Table.prompt.md). */ .weex-tbl-hscroll { overflow: visible; } .weex-tbl-hscroll table { table-layout: fixed; } @media (max-width: 960px) { .weex-tbl-hscroll div:has(> table) { overflow-x: auto !important; -webkit-overflow-scrolling: touch; } .weex-tbl-hscroll table { min-width: 680px; } } /* Bancada de importação (grade virtualizada): no compact a caixa rola na horizontal e as duas faixas (cabeçalho + corpo) recebem largura mínima pra rolarem juntas. */ @media (max-width: 680px) { .weex-bancada-x { overflow-x: auto !important; -webkit-overflow-scrolling: touch; } .weex-bancada-x > div { min-width: 620px; } } /* ── ATIVIDADE DE ABERTURA (a porta do dia, na trilha do participante) ── A faixa é UMA linha flex com dois blocos rígidos: ícone (42+16) e pílula do CTA (105–117+16). MEDIDO NA PEÇA VIVA (Home, dia 5): os dois comem 179–195px, que num telefone de 360 são ~52% da largura — sobravam 131px para três blocos de texto, a etiqueta quebrava em duas linhas, o título em 3–5, e a faixa ia de 93px (desktop) para 171–266px. A porta do dia empurrava fora da tela justamente o que ela libera. NO COMPACT A PÍLULA SAI DA LINHA DO TEXTO: linha 1 = ícone + texto (a coluna passa de 131–161 para ~260–290px), linha 2 = o CTA. `!important` é obrigatório aqui — o componente é inline (padding, 42×42 e flex vêm do objeto de estilo) e folha não vence inline sem ele. Densidade de compact junto: respiro lateral 24 → 16 e ícone 42 → 36, que devolvem 22px ao texto de graça. Duas defesas valem em TODA largura (não são de arranjo, são de integridade do texto). */ .weex-abertura-eb { white-space: nowrap; } .weex-abertura-ti { overflow-wrap: break-word; } /* A seta é conteúdo da FAIXA DE AÇÃO do compact — na pílula do desktop ela não tem o que fazer. */ .weex-abertura-chev { display: none; } @media (max-width: 680px) { /* `gap` vale nos DOIS eixos, e a segunda linha não precisa dos mesmos 16px que separam ícone e texto: `row-gap` mais curto é o que paga a linha nova (o título cai de 3 linhas para 2). A PÍLULA SE DISSOLVE NUMA FAIXA DE AÇÃO, E ISSO É COMPOSIÇÃO — duas tentativas antes falharam pelo mesmo motivo: uma linha de 343px com UM objeto de 105px sobra ~230px de gradiente chapado, e alinhar à esquerda ou à direita só troca o canto vazio de endereço. Full-bleed no rodapé (margens negativas comendo o respiro da raiz), verbo à esquerda e seta à direita: o objeto PASSA A SER a linha, e ela ganha peso nas duas pontas. É a gramática da `.cta-foot` do mega botão da Home, mesma família de peça. `!important` em quase tudo porque a pílula é inline (fundo, raio, sombra, padding). */ .weex-atividade-abertura { flex-wrap: wrap; row-gap: var(--space-10); padding: var(--space-16) !important; } .weex-abertura-ic { width: 36px !important; height: 36px !important; } /* A LARGURA É DA PÍLULA, NÃO DO INVÓLUCRO, e há motivo: no invólucro, `flex-basis: 100%` (o que faz a linha nova existir) vence qualquer `width`, e trocar a base por `calc(100% + 32px)` dentro do atalho `flex` foi pior — a declaração caiu, o item voltou a `flex: 0 0 auto`, nada quebrou linha e o texto encolheu para 128px (faixa de 156 a 299px de altura, medido). Então: o invólucro pede a LINHA e a pílula SANGRA os 16+16 do respiro da raiz com margem negativa. O `overflow: hidden` da raiz segura o resto. */ .weex-abertura-cta { flex: 0 0 100% !important; } .weex-abertura-pill { display: flex !important; width: calc(100% + 2 * var(--space-16)); margin: 0 calc(-1 * var(--space-16)) calc(-1 * var(--space-16)); align-items: center; gap: var(--space-10) !important; padding: 13px var(--space-16) !important; background: var(--color-on-brand-fill) !important; color: var(--color-on-brand) !important; border: 0 !important; border-top: 1px solid var(--color-on-brand-line) !important; border-radius: 0 !important; box-shadow: none !important; } .weex-abertura-chev { display: block; margin-left: auto; } } /* InsightBanner (admin) — no compact empilha: ícone (linha 1), texto de lado a lado (linha 2) e ação logo abaixo (linha 3). */ @media (max-width: 680px) { .weex-insight { flex-wrap: wrap; align-items: flex-start !important; } .weex-insight .weex-insight-body { flex-basis: 100%; } .weex-insight .weex-insight-action { flex-basis: 100%; } }