/* ==========================================================================
   PAGAMENTO DA ASSINATURA DENTRO DO PAINEL
   ==========================================================================

   Uma tela só usa este arquivo: `/admin/assinatura/pendente`, onde a escola
   paga o SurfApp sem ser jogada para fora do sistema.

   POR QUE UM ARQUIVO PRÓPRIO, e não mais regras no `<style>` de
   `admin/partials/styles.blade.php`: aquele bloco é carregado por TODAS as
   telas customizadas do painel, e o que está aqui só faz sentido em uma. Um
   seletor de meio de pagamento e uma caixa de campo seguro não têm por que
   pesar no dashboard.

   E POR QUE NÃO SE REUSA `public/css/site.css`, que já desenha exatamente isto
   no checkout do aluno: aquele arquivo não é carregado no painel — nem deve
   ser. Ele traz a paleta inteira do site público, a tipografia da landing e
   centenas de regras de seções que não existem aqui; puxá-lo para o Backpack
   redesenharia o painel por acidente. O que se repete são cinco componentes, e
   eles estão reescritos aqui em cima dos tokens do Tabler.

   O QUE VEM DE GRAÇA DO BOOTSTRAP e por isso não aparece neste arquivo:
   cartões, botões, alertas, `.form-control`, `.form-label`, `.form-text`,
   grade. Só está aqui o que o painel não tem.

   Carregado por `config/backpack/theme-tabler.php`, DEPOIS de tudo — como os
   demais arquivos nossos, para vencer o tema por ordem de cascata em vez de
   `!important`. Lembre que o CSS do painel é servido SEM versão na URL: depois
   de editar, `php artisan basset:clear` e recarga forçada. */

/* --------------------------------------------------------------------------
   Seletor de meio — um pagamento por vez
   --------------------------------------------------------------------------

   PRÉ-SELETOR, E NÃO ABAS `role="tablist"`. Isto é uma ESCOLHA (com o que eu
   vou pagar), e não navegação entre vistas do mesmo conteúdo: um grupo de rádio
   dentro de `<fieldset>` diz exatamente isso a quem lê por voz, já vem com as
   setas do teclado do próprio navegador e não exige gestão de foco em
   JavaScript. Mesmo desenho do checkout do aluno.

   E É SÓ CSS: `input[type=radio]` + `:has()` no invólucro. Numa tela de
   pagamento, um seletor que depende de JavaScript é um seletor que às vezes não
   funciona — e aqui o script que importa é o da tokenização. */

/* `auto-fit` + `minmax`, e não `repeat(3, 1fr)`: são três formas de pagamento,
   e em coluna estreita — o painel tem uma coluna lateral — três caixas fixas
   espremeriam "Transferência" em duas linhas com o prazo cortado. Assim elas
   quebram sozinhas para duas e depois para uma, sem media query e sem número
   de colunas escrito em lugar nenhum. */
.surf-pagamento__abas {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(10.5rem, 1fr));
    gap: .5rem;
    margin-bottom: 1rem;
}

.surf-pagamento__aba {
    display: flex;
    flex-direction: column;
    gap: .1rem;
    padding: .6rem .85rem;
    border: 1.5px solid var(--tblr-border-color, #dadfe5);
    border-radius: var(--tblr-border-radius, .25rem);
    background: var(--tblr-bg-surface, #fff);
    cursor: pointer;
    transition: border-color .15s ease, background-color .15s ease;
}

.surf-pagamento__aba-titulo {
    font-weight: 600;
    line-height: 1.2;
}

.surf-pagamento__aba-apoio {
    font-size: .78rem;
    color: var(--tblr-secondary, #6c757d);
    line-height: 1.2;
}

/* O rádio é escondido só para o olho e continua focável: é nele que o teclado
   navega, e é por isso que o anel de foco é pintado no rótulo irmão. */
.surf-pagamento__radio:focus-visible + .surf-pagamento__abas .surf-pagamento__aba,
.surf-pagamento__abas .surf-pagamento__aba:focus-visible {
    outline: 2px solid var(--tblr-primary, #206bc4);
    outline-offset: 2px;
}

.surf-pagamento:has(#assinatura-meio-pix:checked) [for='assinatura-meio-pix'],
.surf-pagamento:has(#assinatura-meio-cartao:checked) [for='assinatura-meio-cartao'],
.surf-pagamento:has(#assinatura-meio-assinatura:checked) [for='assinatura-meio-assinatura'],
.surf-pagamento:has(#assinatura-meio-transferencia:checked) [for='assinatura-meio-transferencia'] {
    border-color: var(--tblr-primary, #206bc4);
    background: var(--tblr-primary-lt, #e9f0f9);
}

/* O QUE SEPARA AS DUAS RÁPIDAS DA LENTA.

   A linha de apoio das que liberam sozinhas vem em verde, e a da transferência
   fica no cinza de texto secundário. É a única diferença visual entre elas, e é
   de propósito: a transferência não é desencorajada nem escondida — ela é uma
   escolha legítima de quem paga por fora —, mas quem chega a esta tela está
   BLOQUEADO, e o dado que decide é quando o acesso volta.

   Verde semântico, e não a cor da escola: aqui a cor significa "rápido", não
   "nossa marca". Cor de tenant nesta linha diria coisa nenhuma, e ainda cairia
   na regra do contraste (ver `ReadableColor`). */
.surf-pagamento__aba--rapida .surf-pagamento__aba-apoio {
    /* Verde ESCRITO, e não `var(--tblr-success…)`.

       Primeira tentativa foi `--tblr-success-fg`, e ela saiu quase branca na
       tela: no Tabler o sufixo `-fg` é a cor do texto que vai SOBRE o verde, não
       o verde. E `--tblr-success` puro (#2fb344) sobre fundo claro dá cerca de
       2,8:1 — reprova para texto pequeno, que é justamente o tamanho desta
       linha.

       Este tom dá 5,23:1 sobre o branco do cartão e 4,56:1 sobre o azul claro
       da aba selecionada — medido pela fórmula da WCAG, não estimado. O verde
       do tema daria 2,74:1 e 2,39:1 nos mesmos fundos. É a mesma decisão já tomada
       em `surfapp-avisos.css`, e pelo mesmo motivo. */
    color: #2f7a4d;
    font-weight: 500;
}

/* A COBRANÇA AUTOMÁTICA NÃO É "RÁPIDA", E NÃO PODE PARECER.

   O verde acima significa uma coisa só: o acesso volta agora. É a única
   promessa que esta opção não pode fazer — nela a escola AUTORIZA, o provedor
   debita em seguida, e o painel abre quando o débito for confirmado. Pintá-la
   de verde ao lado do Pix seria vender a mesma coisa com outro nome.

   Azul do próprio tema, e não uma cor nova: ela é a opção de compromisso mais
   longo, não a mais urgente. O tom escrito à mão é o do texto do Tabler sobre
   fundo claro (5,9:1 no branco do cartão e 5,1:1 no azul claro da aba
   selecionada); `--tblr-primary` puro daria 3,9:1, que reprova para o tamanho
   desta linha. Mesma decisão do verde logo acima, e pelo mesmo motivo. */
.surf-pagamento__aba--assinatura .surf-pagamento__aba-apoio {
    color: #1a5490;
    font-weight: 500;
}

/* --------------------------------------------------------------------------
   Os dois modos do formulário de cartão
   --------------------------------------------------------------------------

   UM FORMULÁRIO, DOIS COMPROMISSOS. O mesmo cartão pode virar um pagamento
   avulso ou um mandato de cobrança automática, e o que muda entre os dois é
   texto e botão — os campos são os mesmos.

   POR QUE NÃO SÃO DOIS FORMULÁRIOS: número, validade e CVV são iframes que o
   SDK do provedor monta e tokeniza através da instância que os criou.
   `createCardToken()` tokeniza os campos DA INSTÂNCIA, não os de um formulário;
   com dois `cardNumber` montados na página não haveria como dizer qual
   tokenizar. Ver o comentário longo em `partials/pagamento.blade.php`.

   AQUI `display: none` É SEGURO, ao contrário do que vale para os painéis: o
   que estas regras escondem é texto, o select de parcelas e um botão. Nenhum
   iframe do provedor está dentro de um bloco `--avulso` ou `--recorrente`, e
   nenhum pode passar a estar — esconder um campo seguro com `display: none` o
   quebra, e o modo de falhar é silencioso. */
.surf-pagamento:has(#assinatura-meio-assinatura:checked) .surf-pagamento__modo--avulso,
.surf-pagamento:has(#assinatura-meio-cartao:checked) .surf-pagamento__modo--recorrente {
    display: none;
}

/* Os dois botões só convivem no navegador sem `:has()` (ver o `@supports` mais
   abaixo). O espaço existe para esse caso, e não custa nada nos demais. */
.surf-pagamento__painel--cartao .btn + .btn {
    margin-left: .5rem;
}

/* --------------------------------------------------------------------------
   Painéis
   --------------------------------------------------------------------------

   OS PAINÉIS NUNCA SÃO DESMONTADOS, e esta é a regra mais importante do
   arquivo. Os campos de cartão são iframes de OUTRA ORIGEM
   (`secure-fields.mercadopago.com`) montados pelo SDK: escondê-los com
   `display: none` — ou tirá-los do DOM — os quebra, e o modo de falhar é
   silencioso (três caixas impecáveis que não aceitam digitação).

   Por isso o painel inativo sai de cena por `position: absolute` +
   `visibility: hidden`, que mantém caixa, largura e iframes vivos. */

.surf-pagamento__paineis {
    position: relative;
}

.surf-pagamento--abas .surf-pagamento__painel {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    visibility: hidden;
    opacity: 0;
    pointer-events: none;
}

/* O painel do cartão atende DUAS opções do seletor — é o mesmo formulário,
   com dois destinos. Ver o bloco "Os dois modos do formulário de cartão". */
.surf-pagamento--abas:has(#assinatura-meio-pix:checked) .surf-pagamento__painel--pix,
.surf-pagamento--abas:has(#assinatura-meio-cartao:checked) .surf-pagamento__painel--cartao,
.surf-pagamento--abas:has(#assinatura-meio-assinatura:checked) .surf-pagamento__painel--cartao,
.surf-pagamento--abas:has(#assinatura-meio-transferencia:checked) .surf-pagamento__painel--transferencia {
    position: static;
    visibility: visible;
    opacity: 1;
    pointer-events: auto;
}

/* Queda para navegador sem `:has()`: os dois meios voltam a aparecer
   empilhados, na ordem do HTML e com um filete entre eles. Perde-se a aba e não
   se perde nenhum meio de pagamento — que é a degradação certa numa tela de
   cobrança. */
@supports not selector(:has(*)) {
    .surf-pagamento--abas .surf-pagamento__painel {
        position: static;
        visibility: visible;
        opacity: 1;
        pointer-events: auto;
    }

    .surf-pagamento--abas .surf-pagamento__painel ~ .surf-pagamento__painel {
        margin-top: 1.25rem;
        padding-top: 1.25rem;
        border-top: 1px solid var(--tblr-border-color, #dadfe5);
    }

    .surf-pagamento__abas,
    .surf-pagamento__escolha {
        display: none;
    }

    /* NADA A DESFAZER PARA OS DOIS MODOS DO CARTÃO, e vale registrar por quê:
       as regras que escondem `--avulso` e `--recorrente` são escritas com
       `:has()`, e um navegador sem `:has()` descarta o seletor inteiro. Elas
       simplesmente não existem aqui, e cada bloco fica com o seu próprio
       `display` — o que uma regra de reversão escrita à mão estragaria, porque
       o selo é `flex` e o campo de parcelas é coluna da grade.

       O resultado é o texto da cobrança automática, o campo de parcelas e os
       DOIS botões na tela ao mesmo tempo. Não é bonito e é a degradação certa:
       cada botão leva ao seu destino pelo `formaction`, e nenhuma forma de
       pagar desaparece. */

    /* Sem a trilha, o título de cada meio volta a ser a única coisa que diz
       "isto aqui é o Pix" — ele só estava escondido porque a aba já escrevia o
       nome logo acima. */
    .surf-pagamento__painel > .surf-pagamento__titulo.visually-hidden {
        position: static !important;
        width: auto !important;
        height: auto !important;
        margin: 0 0 .5rem !important;
        overflow: visible !important;
        clip: auto !important;
        clip-path: none !important;
        white-space: normal !important;
    }
}

/* --------------------------------------------------------------------------
   Campo seguro — a caixa onde o iframe do provedor é montado
   --------------------------------------------------------------------------

   Desenhada para ser indistinguível de um `.form-control` do Tabler, porque
   para quem digita ela É um campo. O que muda é que o `<input>` de verdade
   pertence a outro documento: nem o nosso CSS nem o nosso JavaScript entram
   nele — quem formata o conteúdo é o SDK, com o estilo passado na montagem.

   A BORDA DE FOCO TEM DE SER ACESA POR EVENTO (`.is-focado`, ligada pelo
   script): `:focus-within` não atravessa iframe, e sem isso o campo focado
   ficaria visualmente igual ao campo em repouso. */

.surf-pagamento__campo-seguro {
    display: block;
    width: 100%;
    max-width: 100%;
    min-height: 2.375rem;
    padding: 0 .75rem;
    background: var(--tblr-bg-forms, #fff);
    border: 1px solid var(--tblr-border-color, #dadfe5);
    border-radius: var(--tblr-border-radius, .25rem);
    transition: border-color .15s ease, box-shadow .15s ease;
}

.surf-pagamento__campo-seguro.is-focado {
    border-color: var(--tblr-primary, #206bc4);
    box-shadow: 0 0 0 .25rem rgba(32, 107, 196, .25);
}

.surf-pagamento__campo-seguro iframe {
    display: block;
    width: 100%;
    height: 2.25rem;
    border: 0;
}

/* --------------------------------------------------------------------------
   Pix
   -------------------------------------------------------------------------- */

.surf-pagamento__qr {
    display: flex;
    justify-content: center;
    padding: .75rem;
    background: #fff;
    border: 1px solid var(--tblr-border-color, #dadfe5);
    border-radius: var(--tblr-border-radius, .25rem);
}

/* O QR é lido por câmera: nunca reduzir abaixo do que a leitura exige, e nunca
   deixar passar da largura do cartão. */
.surf-pagamento__qr img {
    width: 220px;
    height: 220px;
    max-width: 100%;
    image-rendering: pixelated;
}

.surf-pagamento__copia {
    display: flex;
    gap: .5rem;
    align-items: stretch;
}

/* O código copia-e-cola tem mais de cem caracteres: em monoespaçada, quem
   confere os primeiros dígitos consegue. */
.surf-pagamento__copia input {
    font-family: var(--tblr-font-monospace, ui-monospace, SFMono-Regular, monospace);
    font-size: .8rem;
}

.surf-pagamento__copia .btn {
    white-space: nowrap;
}

/* --------------------------------------------------------------------------
   Selo de pagamento seguro
   --------------------------------------------------------------------------

   Bloco de LEITURA entre o último campo e o botão. NÃO É UM ALERTA: `.alert`
   daria o desenho de graça e foi descartado, porque alerta significa "aconteceu
   alguma coisa" e vem com `role="alert"` — quem lê por voz seria interrompido
   por uma informação que está na página desde que ela abriu.

   Calmo de propósito. Selo de pagamento é o lugar clássico do exagero (cadeado
   enorme, borda verde, "100% seguro"), e exagero num formulário de cartão
   produz o efeito contrário do pretendido. */

.surf-pagamento__selo {
    display: flex;
    gap: .65rem;
    align-items: flex-start;
    padding: .75rem .85rem;
    background: var(--tblr-bg-surface-secondary, #f7f8fa);
    border: 1px solid var(--tblr-border-color, #dadfe5);
    border-radius: var(--tblr-border-radius, .25rem);
}

.surf-pagamento__selo i {
    flex: 0 0 auto;
    font-size: 1.15rem;
    line-height: 1.2;
    color: var(--tblr-secondary, #6c757d);
}

.surf-pagamento__selo-titulo {
    display: block;
    font-weight: 600;
    margin-bottom: .15rem;
}

.surf-pagamento__selo p {
    margin: 0;
    font-size: .82rem;
    line-height: 1.45;
    color: var(--tblr-secondary, #6c757d);
}

/* A caixa de erro da tokenização nasce escondida e só aparece quando o provedor
   recusa os dados do cartão. `.alert` declara `display: block` por classe, e o
   atributo `hidden` do navegador perde para qualquer regra de autor — sem esta
   linha ela apareceria vazia desde o primeiro render. */
.alert[hidden] {
    display: none !important;
}

/* --------------------------------------------------------------------------
   Telas estreitas
   -------------------------------------------------------------------------- */

@media (max-width: 575.98px) {
    .surf-pagamento__copia {
        flex-direction: column;
    }

    .surf-pagamento__copia .btn {
        width: 100%;
    }
}

/* --------------------------------------------------------------------------
   A saída alternativa, com um Pix em aberto
   --------------------------------------------------------------------------

   Recolhida de propósito: quem está olhando um QR válido quase sempre vai pagar
   por ele, e um campo de arquivo aberto logo abaixo competiria com o código. O
   `<details>` nativo resolve sem uma linha de JavaScript e já vem com teclado e
   leitor de tela. */
.surf-pagamento__alternativa {
    border-top: 1px solid var(--tblr-border-color, #dadfe5);
    padding-top: 1rem;
}

.surf-pagamento__alternativa > summary {
    cursor: pointer;
    font-size: .85rem;
    color: var(--tblr-secondary, #6c757d);
}

.surf-pagamento__alternativa > summary:focus-visible {
    outline: 2px solid var(--tblr-primary, #206bc4);
    outline-offset: 2px;
    border-radius: var(--tblr-border-radius, .25rem);
}

/* ---------------------------------------------------------------------------
   RESUMO DOS VALORES
   ---------------------------------------------------------------------------
   Tres linhas: o que se compra, o que o emissor cobra por parcelar, e o total.

   Separadas de proposito, em vez de so mostrar o total maior. Os juros nao sao
   nossos — sao do banco de quem parcela — e um numero que aparece do nada,
   maior que o anunciado, parece taxa da plataforma. Nomear a diferenca e o que
   evita a pergunta que vira chamado de suporte.

   O total repete o peso do botao logo abaixo, porque e o mesmo numero: e o que
   compromete o limite do cartao, e e o que vai na fatura. */
.surf-resumo {
    border: 1px solid var(--tblr-border-color, #dadfe5);
    border-radius: var(--tblr-border-radius, .25rem);
    padding: .65rem .85rem;
    background: var(--tblr-bg-surface-secondary, #f7f8f9);
}

.surf-resumo__linha {
    display: flex;
    align-items: baseline;
    justify-content: space-between;
    gap: 1rem;
    font-size: .875rem;
    line-height: 1.5;
}

.surf-resumo__linha + .surf-resumo__linha {
    margin-top: .15rem;
}

/* Os juros ficam no tom de texto secundario: e informacao de contexto, nao o
   numero que a pessoa precisa decidir. */
.surf-resumo__linha--juros {
    color: var(--tblr-secondary, #6c757d);
}

.surf-resumo__linha--total {
    margin-top: .4rem;
    padding-top: .4rem;
    border-top: 1px solid var(--tblr-border-color, #dadfe5);
    font-size: .95rem;
}

/* ---------------------------------------------------------------------------
   Formulario congelado enquanto o pagamento e processado
   ---------------------------------------------------------------------------
   Os campos comuns ficam `disabled` pelo script, e o navegador ja os apaga
   sozinho. Esta regra existe pelos OUTROS: os campos de cartao sao <iframe> de
   `secure-fields.mercadopago.com`, de outro dominio, e `disabled` nao os
   alcanca — quem os trava e `pointer-events`.

   O cursor de espera vale para o formulario inteiro. Sem ele o congelamento
   parece travamento: a pessoa clica, nada responde, e ela clica de novo. */
.surf-form--processando {
    cursor: progress;
}

.surf-form--processando .surf-pagamento__campo-seguro,
.surf-form--processando iframe {
    pointer-events: none;
}

/* Opacidade so nos campos, e nao no formulario inteiro: o botao precisa
   continuar legivel para mostrar "Processando…", e o resumo de valores e
   justamente o que a pessoa quer reler enquanto espera. */
.surf-form--processando .form-control:disabled,
.surf-form--processando .form-select:disabled,
.surf-form--processando .surf-pagamento__campo-seguro {
    opacity: .65;
}