/* ============================================================================ Transições de página — o app é multi-página renderizado no servidor (Django), sem SPA router: toda navegação entre telas é um DOCUMENTO NOVO. Este arquivo é compartilhado pelos três "shells" HTML independentes do produto (base.html, registration/base_onboarding.html, registration/login.html) — por isso não depende de nenhum token de design-tokens.css (só o base.html carrega esse arquivo; os outros dois definem a própria paleta local). A única variável reaproveitada é --accent, que os três shells definem. Duas peças, cobrindo os dois pedidos ("transições suaves" e "carregamento suave"): 1. View Transitions API nativa (@view-transition, Chrome/Edge 126+, Safari 18+) — o navegador tira um retrato da página que está saindo e da que está entrando e cruza (crossfade) sozinho, sem JS e sem tocar em nenhum dos ~970 templates existentes. Navegador sem suporte ignora a at-rule e navega normal — progressive enhancement, sem fallback quebrado. 2. Barra de progresso no topo (padrão nprogress/Turbolinks, ver page_transitions.js) — como cada navegação é um documento novo, não existe evento de "progresso real" pra escutar; a barra rasteja até ~75% enquanto o documento carrega e completa pra 100% no fim. Ao SAIR da página, beforeunload reinicia a rasteira — nunca fica "morta" entre o clique e a próxima página assumir. Reduced-motion: a barra e o fallback de fade usam `transition`/`animation` normais em elementos comuns do DOM, então caem sob a regra global de prefers-reduced-motion já replicada nos três shells (zera toda duração via seletor `*`). A view-transition nativa vive numa árvore de pseudo-elementos separada (top-layer, `*` não alcança) — por isso ganha o guard @media próprio abaixo. ============================================================================ */ @media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } } /* Barra de progresso -------------------------------------------------------- */ #pt-page-progress { position: fixed; top: 0; left: 0; height: 2.5px; width: 100%; /* 9999 de propósito: precisa vencer tanto a escala numerada do Bootstrap (base.html — modal-backdrop 1050, toast 1090) quanto as escalas pequenas e locais dos shells de login/onboarding (máx. usado ali: 60) — sem ficar amarrado a nenhuma das duas. */ z-index: 9999; pointer-events: none; } #pt-page-progress::before { content: ''; display: block; height: 100%; width: 0%; background: var(--accent); opacity: 1; } html.pt-loading #pt-page-progress::before { width: 75%; /* Ease-out desacelerando: não afirma um fim que não conhecemos — é um documento novo carregando, sem evento de progresso real por trás. */ transition: width 3.5s cubic-bezier(.1, .6, .2, 1); } html.pt-loaded #pt-page-progress::before { width: 100%; opacity: 0; transition: width .2s ease, opacity .3s ease .15s; } /* Entrada do conteúdo (fallback) -------------------------------------------- Só roda em navegador SEM a View Transitions API nativa (classe .pt-no-vt, ver page_transitions.js) — com a API nativa ativa, o navegador já cruza a página anterior com esta; animar o body por cima duplicaria o fade. */ html.pt-no-vt body { /* `backwards`, não `both` — mesma armadilha documentada em design-system.css (.content-wrapper): fill pra frente numa animação de `opacity` deixa o elemento criando contexto de empilhamento pra sempre. Aqui o alvo é o , que contém TANTO o modal quanto o `.modal-backdrop`, então não invertia a ordem dos dois — mas fica `backwards` por consistência, pra ninguém herdar o padrão errado. */ animation: pt-body-entrada .22s ease backwards; } @keyframes pt-body-entrada { from { opacity: 0; } to { opacity: 1; } }