/* Visão do Campo — largura: a lateral da área cresce arrastando a borda esquerda. Só acima de 700 px: abaixo disso a lateral é a folha que sobe de baixo. O MÍNIMO MORA AQUI, não no JavaScript: `max()` entre a largura de sempre e a pedida. Medir o mínimo em JS deu errado na primeira versão — a lateral nasce `hidden`, mede 0 px, e o zero ia parar na variável e esmagava a lateral. */ @media (min-width: 901px) { /* O TETO É 58vw, NÃO 70. O mapa tem `min-width: 42%` (estilo.css, `.mapa-area`) e é item flex que não encolhe além disso: com 70vw pedidos aqui, 42 + 70 = 112% — a lateral não cabia e era EMPURRADA PARA FORA da janela. Medido: numa janela de 1800 px ela ia de 756 a 1956, ou seja 156 px atrás da borda direita, e a última coluna de medidas aparecia cortada. Os dois números têm de somar 100. */ /* ABRE COM METADE DA TELA (dono, 2026-09-22: "por padrão quando clicar coloque para ocupar metade da tela mesmo, acho que fica melhor assim, mais informação útil"). São 50vw no LUGAR DO PADRÃO da variável, não no mínimo: quem arrastar para menos continua podendo, até o piso de sempre. Em 50vw a lateral já entra em duas colunas (o limiar é 820 px numa tela de 1640 para cima), que é justamente onde ela mostra mais e rola menos. */ .sidebar-direita { position: relative; width: max(clamp(300px, 34%, 440px), min(var(--largura-lateral, 50vw), 58vw)); } /* O TETO DESCONTA A BARRA DE FERRAMENTAS (80 px). 58vw + 42% do mapa somavam 100% SEM ela; com ela a lateral arrastada ao máximo ia 75 px além da borda direita da janela — "Mover", o select e o fim dos campos ficavam cortados (dono, 2026-10-04, com o print). O `%` aqui é da largura do `.corpo`. */ .sidebar-direita { max-width: calc(58% - var(--barra-largura, 0px)); } .com-ferramentas { --barra-largura: 80px; } /* TABLET EM PAISAGEM (901–1200 px): metade da tela deixaria o mapa com ~430 px e os filtros sobre ele. Abre com 40vw; quem arrastou a alça continua mandando (`--largura-lateral`). Auditoria D-01/D-14. */ @media (max-width: 1200px) { .sidebar-direita { width: max(clamp(300px, 34%, 440px), min(var(--largura-lateral, 40vw), 58vw)); } } /* A ALÇA É VISÍVEL PARADA (dono, 2026-09-22: "deve ter aquele detalhe de onde puxar"). Ela existia desde sempre, mas o `::after` nascia `transparent` e só aparecia no hover: quem não sabia que ela estava ali não tinha como descobrir. Agora são três tracinhos no meio da borda — o mesmo desenho que todo painel redimensionável usa —, discretos parados e firmes sob o ponteiro. A ÁREA DE PEGA continua com 8 px de largura, maior que o desenho: alvo de ponteiro pequeno demais é o que faz a pessoa errar e arrastar o mapa. */ .alca-largura { position: absolute; left: 0; top: 0; bottom: 0; width: 16px; margin-left: -8px; z-index: 5; cursor: col-resize; touch-action: none; } /* a linha fina, do alto a baixo: diz ONDE a borda é agarrável */ .alca-largura::before { content: ''; position: absolute; left: 4px; top: 0; bottom: 0; width: 2px; background: transparent; transition: background 0.12s; } /* o punho: três tracinhos no meio vertical */ /* MAIOR E MAIS VISÍVEL (dono, 2026-09-22). O punho era de 6 x 34 px e passava despercebido; agora são 12 x 56, com fundo cheio e os tracinhos com contraste de verdade. A área de pega (16 px) continua maior que o desenho, senão a pessoa erra e arrasta o mapa. */ .alca-largura::after { content: ''; position: absolute; left: 2px; top: 50%; width: 12px; height: 56px; margin-top: -28px; border-radius: var(--r-s); background: var(--superficie); border: 1px solid var(--linha-forte); box-shadow: 0 1px 4px rgba(14,17,15,0.16); background-image: linear-gradient(var(--tinta-2) 1.5px, transparent 1.5px); background-size: 100% 5px; background-position: center; background-repeat: repeat-y; background-clip: content-box; padding: 16px 3px; box-sizing: border-box; transition: border-color 0.12s, box-shadow 0.12s; } .alca-largura:hover::before, .alca-largura:focus-visible::before { background: var(--linha-forte); } .alca-largura:hover::after, .alca-largura:focus-visible::after { border-color: var(--verde); box-shadow: 0 1px 8px rgba(14,17,15,0.26); } .alca-largura:focus-visible { outline: none; } body.arrastando-largura { user-select: none; cursor: col-resize; } body.arrastando-largura .alca-largura::before { background: var(--verde); } body.arrastando-largura .alca-largura::after { border-color: var(--verde); } /* o mapa não pode roubar o ponteiro no meio do arrasto */ body.arrastando-largura #agro-map, body.arrastando-largura #agro-pixels { pointer-events: none; } } @media (max-width: 900px) { .alca-largura { display: none; } } /* -------------------------------------------------------------------------- A LATERAL SE REORGANIZA AO SER PUXADA (dono, 2026-09-22: "está apenas ampliando a largura das coisas… a imagem está ficando grande e os indicadores também e não está reorganizando de forma a ficar tudo na tela"). Antes o corpo era UMA coluna: a foto é `width: 100%` com `aspect-ratio: 1/1`, então puxar para 900 px fazia um quadrado de 900 × 900, e as sete medidas esticavam junto — mais largura virava MAIS rolagem, não menos. A consulta é `@container`, não `@media`: quem muda de tamanho é a lateral, não a janela. Com `@media` a tela larga já abriria em duas colunas mesmo com a lateral estreita, que é o contrário do que se quer. Só acima de 700 px. No celular a lateral é a folha que sobe de baixo, e `container-type` aplica contenção de layout — não é para mexer nela ali. */ @media (min-width: 901px) { .sidebar-direita { container-type: inline-size; container-name: lateral; } /* 1. A FOTO NUNCA CRESCE ALÉM DISTO, em qualquer largura e mesmo em uma coluna só. São 260 px de imagem (65 px de satélite a 2,5 m): passando daqui ela só fica maior sem mostrar mais nada, e era ela quem empurrava tudo para baixo. */ .col-foto { max-width: 420px; } /* 2. A COLUNA DOS DADOS precisa poder ENCOLHER. Item de grid nasce com `min-width: auto`, que é o tamanho do conteúdo: sem esta linha uma medida larga empurra a coluna e a grade inteira estoura para fora da lateral. */ .col-dados { min-width: 0; } /* QUANTAS COLUNAS CABEM, quem decide é o navegador: `auto-fit` com um MÍNIMO. Com limiares fixos (duas colunas aqui, três ali) a conta era minha e eu errava: a 1200 px davam três colunas de ~225 px e o nome do índice mais o valor não cabiam — a terceira coluna saía cortada na borda direita. Com `minmax(240px, 1fr)` nenhuma coluna nasce estreita demais para o conteúdo (240 é o que o nome do índice mais o valor precisam; a 225 px cortava), e o número delas acompanha a largura sozinho. `min-width: 0` na medida porque item de grid não encolhe além do conteúdo por padrão, e uma régua larga voltaria a estourar a coluna. */ .medidas-grade { display: grid; grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); column-gap: 22px; } .medidas-grade > .medida { min-width: 0; } /* 3. OS INDICADORES FICAM AO LADO DA FOTO ASSIM QUE COUBEREM — e a foto é que cede, não eles (dono, 2026-09-22: "com uma imagem apenas ela fica com um espaço vazio grande no lado porque a imagem fica maior, e os índices somem; se não tiver duas imagens deve apenas aquela imagem ocupar o tamanho das duas, e os indicadores ficarem do lado da mesma forma"). O QUE ESTAVA ERRADO. O limiar era 820 px e abaixo dele o corpo não era grid: a foto ficava com os 420 px do `max-width` dentro de uma lateral de 659 a 774 px de conteúdo — sobrava um vazio alto à direita dela — e os indicadores iam para BAIXO, fora da vista. Com DUAS fotos o mesmo acontecia, só que o bloco é metade da altura (258 px contra 420), e por isso incomodava menos: o defeito era o mesmo nos dois casos. O 820 tinha uma razão que não valia mais: "a 620 px a foto ficava ao lado de uma coluna de dados de 180 px". Aqueles 180 px vinham de a foto levar 360 — é a LARGURA DA FOTO que fazia a conta não fechar, não a da lateral. Com a coluna da foto em 200–260 px, a 620 px de lateral sobram ~340 para os dados, e 340 comporta uma coluna de medidas (o mínimo delas é 240). Com a coluna da foto de largura FIXA, uma foto e duas ocupam o mesmo lugar — que é o que o dono pediu. Uma foto sozinha continua sendo um quadrado mais alto que o par lado a lado; o que sumiu foi o vazio, porque agora é ali que os indicadores ficam. */ /* A FOTO SÓ ENGORDA QUANDO O QUE SOBRA AINDA DÁ DUAS COLUNAS DE MEDIDA. A conta é sempre a mesma: `container − 22 de vão − foto` tem de chegar a 502 px, que é o que duas colunas de 240 mais o vão delas pedem. Foi medindo que isto apareceu: com a foto em 260 px, a 815 px de lateral a rolagem SUBIU de 1759 para 2059 — ao empilhar, as medidas pegavam os 774 px inteiros e saíam em três colunas; ao lado da foto sobravam 492, uma coluna só. Pôr os indicadores ao lado não pode custar mais rolagem do que empilhar. E a largura útil NÃO é a do container: `#corpo-area` tem ~40 px de padding, então `útil = container − 40`. Errei isso na primeira conta e o degrau de 790 caiu no lugar errado — a 800 px de lateral a foto já engordava para 260 e os dados voltavam a uma coluna só. Os degraus abaixo já descontam. container 620 → foto 200, dados 358 → 1 coluna (não há largura para duas) container 720 → foto 200, dados 458 → 1 coluna (faltam 44 px) container 830 → foto 260, dados 508 → 2 colunas container 890 → foto 320, dados 508 → 2 colunas container 1000 → foto 420, dados 518 → 2 colunas Cada degrau é o primeiro lugar em que a foto MAIOR ainda deixa as duas colunas de pé (`container ≥ 564 + foto`), não um número escolhido a dedo. ONDE ISTO CUSTA. Abaixo de 764 px de container os dados ficam em UMA coluna ao lado da foto, e empilhar rolaria menos (medido a 700 px: 1561 px empilhado contra 2059 ao lado) — nessa faixa não existe largura para as duas colunas de jeito nenhum. Fica ao lado assim mesmo porque foi o que o dono pediu ao ver a tela, e o que ele viu de errado não foi a rolagem: foi o vazio ao lado da foto e os indicadores sumindo por baixo dela. */ /* SÓ O CORPO QUE TEM FOTO vira duas colunas (`:has(> .col-foto)`, que `agruparColunas` monta). O formulário de "Nova área"/"Editar área" e a tela de coleta também moram em `#corpo-area`, e com a lateral larga os campos dele caíam em colunas alternadas de 200 px e do resto — campo encostando na borda, select cortado, "Mover" fora da lateral (dono, 2026-10-04, com o print). */ @container lateral (min-width: 620px) { #corpo-area:has(> .col-foto) { display: grid; grid-template-columns: minmax(170px, 200px) minmax(0, 1fr); column-gap: 22px; align-items: start; /* sem isto uma coluna de dados com conteúdo largo empurra a grade para fora da lateral, e o que sobra fica escondido atrás da borda */ overflow-x: clip; } } @container lateral (min-width: 830px) { #corpo-area:has(> .col-foto) { grid-template-columns: minmax(200px, 260px) minmax(0, 1fr); } } @container lateral (min-width: 890px) { #corpo-area:has(> .col-foto) { grid-template-columns: minmax(240px, 320px) minmax(0, 1fr); } } @container lateral (min-width: 1000px) { #corpo-area:has(> .col-foto) { grid-template-columns: minmax(300px, 420px) minmax(0, 1fr); } } } /* -------------------------------------------------------------------------- TABLET EM PÉ (601–900 px): a lateral é a folha de baixo, e a foto, que é `width: 100%`, virava um quadrado de 700 px que empurrava as medidas para fora da primeira tela (auditoria de 2026-10-04). Aqui a foto volta a uma coluna de 260 px e as medidas ficam ao lado, como no computador. Abaixo de 601 px (celular) a coluna única continua valendo. */ @media (min-width: 601px) and (max-width: 900px) { #corpo-area:has(> .col-foto) { display: grid; grid-template-columns: minmax(200px, 260px) minmax(0, 1fr); column-gap: 20px; align-items: start; overflow-x: clip; } .col-foto { max-width: 260px; } .col-dados { min-width: 0; } }