/* Não é CSS do legado — acabamento pedido pelo Gustavo na sessão de
 * fechamento de 2026-08-22, na página do case (`/ml/[slug]`): os boxes da
 * barra lateral (Material/Chemistry/Application/Product/Properties/
 * Microstructure/Observations) tinham 5px de margem vertical entre si
 * (`.sidebar-block { margin: 5px 0 0 0 }`, view-material.legacy.css) contra
 * 30px de gutter horizontal nos pares lado a lado (Bootstrap `col-*-6`,
 * `padding: 0 15px` de cada lado) — arejamento bem diferente em cada
 * direção. Padronizado em 5px nas duas direções (o vertical já era esse
 * valor no legado — é o horizontal que precisava encolher pra bater; 24px
 * foi tentado primeiro e ficou espaçoso demais ao vivo), com cantos
 * arredondados discretos (6px — 12px também ficou grande demais). O bloco
 * branco atrás do rótulo (M/C/Ap/...) sobrepondo a borda é intencional
 * (conexão visual entre os boxes) — não mexer nisso, só no espaçamento e
 * no raio. Mesmo padrão de arquivo de correção à parte de
 * `header-visible-fix.css`/`header-polish.css` — não edita o legado
 * vendorizado, carrega DEPOIS dele na página.
 *
 * Padding interno também padronizado: o legado dava `25px 20px 15px`
 * (topo/base diferentes) — 20px iguais nos quatro lados, pedido do
 * Gustavo depois de ver os dois valores lado a lado.
 */
.container .sidebar .row .sidebar-block {
  border-radius: 6px;
  margin: 5px 0 0 0;
  padding: 20px;
}
/* Achado 2a, sessão de alinhamento (2026-09-07): `.block-head` é
 * `position:absolute; top:-28px` (view-material.legacy.css) — medido ao
 * vivo (Playwright, `getBoundingClientRect`, `/ml/<slug>` real, todas as
 * 7 caixas): o rótulo sobe 26px acima do próprio box (não os 28px
 * literais do CSS — diferença é o `border:2.5px` do próprio box, cujo
 * `getBoundingClientRect` já inclui). O vão vertical entre caixas é 5px
 * (`margin-top` abaixo) — 26 > 5, então 21px do rótulo pousam DENTRO da
 * caixa anterior, furando a borda dela por baixo.
 *
 * Duas saídas possíveis (vão maior, ou rótulo que não saia da caixa) —
 * tentada primeiro a segunda (`top: -6px`, saliência ~4px < vão de 5px):
 * MEDIU sem invasão, mas capturada ao vivo (`shots`, 1024px) mostrou uma
 * invasão NOVA, pior — o próprio conteúdo da caixa (não só a borda): o
 * rótulo é `display:flex; align-items:center` sobre um `font-size:29px`
 * fixo (ícone+texto), então a altura do box não é ajustável por
 * `min-height` (o conteúdo já pede mais do que qualquer `min-height`
 * menor que ~41-47px) — encolher a saliência ACIMA empurra a mesma
 * altura de conteúdo MAIS PRA DENTRO da própria caixa, e o texto do
 * rótulo passou a cortar o `<h4>` (Material/Chemistry/...) logo abaixo
 * do padding-top de 20px. Piorou o que devia consertar.
 *
 * Escolha final: vão maior. `margin-top` de `.sidebar-block` sobe de 5px
 * pra 28px (>= 26px de saliência, com folga de 2px) — o rótulo volta à
 * geometria ORIGINAL (sem mexer em `.block-head`), que já era
 * comprovadamente segura (nenhuma invasão de conteúdo, ver captura
 * "antes"), só com mais espaço acima pra caber. Desfaz a simetria 5px/5px
 * entre vertical e horizontal que a sessão de 2026-08-22 tinha fechado
 * (ver comentário do topo do arquivo) — registrado como troca
 * deliberada, não descuido: a simetria não sobrevive à correção de uma
 * invasão real medida. */
.container .sidebar .row .sidebar-block {
  margin-top: 28px;
}
/* view-material.legacy.css tem uma regra só pra ≤991px com `!important`
 * (`.sidebar-block { margin: 30px 0 0 0 !important }`) — sem isto, o
 * espaçamento volta a ficar desigual em qualquer janela/tela mais estreita
 * que 991px (é exatamente essa regra que o Gustavo viu ao vivo). Precisa
 * de `!important` + mesma especificidade maior pra ganhar da regra
 * legada, que também usa `!important`.
 *
 * Achado 2a (mesma sessão, 2026-09-07): valor trocado de 5px pra 28px
 * junto com o `margin-top` do desktop acima — mesma razão (saliência do
 * rótulo de 26px), medida igual em 390/768/1024px quanto em 1440/1920 (a
 * caixa do rótulo não muda de tamanho por breakpoint). Convenientemente
 * o legado já tinha 30px !important só aqui pra ≤991px — bem perto do
 * 28px do desktop; manter os dois EXPLICITAMENTE iguais (28px nos dois)
 * evita reintroduzir a inconsistência de 2px entre breakpoints que a
 * sessão de 2026-09-03 tinha corrigido por outro motivo (rodapé duplo
 * arredondando diferente — não se aplica aqui, mas a memória de manter
 * um valor só, sem depender de differences por largura, ainda vale). */
@media (max-width: 991px) {
  .container .sidebar .row .sidebar-block {
    margin: 28px 0 0 0 !important;
  }
}
/* Sessão 2026-09-03 — pedido do Gustavo com screenshot: "as bordas dos
 * elementos devem sempre ficar alinhadas, sem buracos", confirmado depois
 * como "mesma largura vertical e horizontal". Medido ao vivo (Playwright,
 * `getBoundingClientRect`) antes desta mudança: os dois vãos já batiam em
 * 5px exatos no Chromium — mas chegavam lá por caminhos DIFERENTES. O vão
 * vertical (`.sidebar-block{margin:5px 0 0 0}`, acima) é um valor inteiro
 * só, numa caixa só. O horizontal somava DOIS valores fracionários de
 * 2,5px, arredondados de forma INDEPENDENTE em caixas diferentes
 * (`margin-left/right:-2.5px` no `.row.flex` + `padding-left/right:2.5px`
 * em CADA `.block-item`) — exatamente o tipo de conta que Chromium e
 * Safari (ou uma tela de densidade de pixel diferente) podem arredondar
 * cada metade pro lado oposto, abrindo um vão de 4px ou 6px em vez de 5px
 * mesmo com o número "certo" no CSS. Trocado por `gap: 5px` no
 * `.row.flex` — mesmo mecanismo de valor inteiro único que o vertical já
 * usa, sem nenhuma fração pra arredondar de jeito nenhum. */
/* Achado 2b/2c, sessão de alinhamento (2026-09-07): o clearfix do
 * Bootstrap (`.row:before,.row:after{display:table;content:" "}`,
 * bootstrap.min.css) gera DOIS pseudo-elementos reais (têm `content`) em
 * toda `.row` — inclusive `.row.flex`. Dentro de um container
 * `display:flex`, um pseudo-elemento com `content` vira item flex de
 * verdade (blockificado), não desaparece. Resultado, medido ao vivo: 4
 * itens flex nesta linha (`::before`, os 2 `.block-item` reais,
 * `::after`), 3 vãos de `gap:5px` entre eles, não 1 — os dois vãos
 * fantasmas (antes do primeiro item, depois do último) que abriam a borda
 * 5px pra dentro dos dois lados (achado 2b) e comiam ~10px do espaço que
 * devia ir pros dois `.block-item` reais (raiz do achado 2c em várias
 * larguras). `content: none` remove o pseudo-elemento por completo (não
 * só esconde) — sem caixa, sem item flex, sem gap fantasma. */
.container .sidebar .row.flex::before,
.container .sidebar .row.flex::after {
  content: none;
}
.container .sidebar .row.flex {
  margin-left: 0;
  margin-right: 0;
  gap: 5px;
  /* Achado seguinte, mesma sessão (2026-09-03): o Gustavo mandou uma
   * screenshot real (Chrome/Mac) onde `Pr`/`Mc` saem com ALTURA diferente
   * — a borda de baixo de `Mc` continua depois da de `Pr` e invade o
   * espaço do bloco `Obs` seguinte. Nem Chromium nem WebKit (Playwright,
   * `--env`, mesmo dado do caso real) reproduzem isso — os dois esticam
   * `Pr`/`Mc` pra mesma altura sem essa regra, porque `align-items:normal`
   * já EQUIVALE a `stretch` dentro de flex por especificação. `stretch`
   * explícito aqui não muda nada em navegador compatível com a spec — é
   * rede de segurança barata contra a hipótese não confirmada (perfil do
   * Chrome do Gustavo: zoom de página, extensão, ou CSS antigo em cache
   * de antes do deploy anterior desta mesma sessão). Se persistir depois
   * disso, o próximo passo é um `align-items` != stretch vindo de outra
   * regra que nenhuma das duas leituras estáticas achou. */
  align-items: stretch;
}
.container .sidebar .row.flex .block-item {
  padding-left: 0;
  padding-right: 0;
  /* `.block-item { padding-top: 10px }` do legado somava aos 5px de
   * margin-top do `.sidebar-block` (Ap/P/Pr/Mc chegavam a 15px de gap,
   * contra 5px de M/C/Obs, que não passam por `.block-item`). Zerado —
   * o espaçamento vertical fica só por conta do `.sidebar-block`. */
  padding-top: 0;
  /* Ver comentário em `.row.flex` acima — mesma rede de segurança, um
   * nível mais fundo (`.block-item` também é `display:flex`, um filho só,
   * `.sidebar-block`). */
  align-items: stretch;
  /* Achado 2b/2c, sessão de alinhamento (2026-09-07): `.block-item` herda
   * `width:50%` de `.col-lg-6`/`.col-md-6` (Bootstrap) e vira flex-basis
   * `auto` dentro do `.row.flex`. Medido ao vivo (Playwright,
   * `getBoundingClientRect`) em 390/768/1024/1440/1920px: com
   * `gap:5px` no pai, essa combinação (basis percentual + shrink
   * default) não fecha as contas — sobra ~10px de espaço não
   * reivindicado por nenhum item, que o Chromium reparte como 5px de
   * vão ANTES do primeiro item e 5px DEPOIS do último (fora do `gap`
   * do meio, que já é os 5px certos) — as bordas de fora da barra saem
   * 5px pra dentro dos dois lados, e a largura real de cada caixa passa
   * a depender do sobra residual, não de "metade exata", explicando
   * também a divergência de largura entre colunas do achado 2c (Ap 273 x
   * Pr 245 x Mc 273 em 1920px, medido antes deste conserto). `flex: 1 1
   * 0` ignora o `width:50%` do Bootstrap (flex-basis vira 0, não o
   * `auto` que lê `width`) e força os dois itens a dividirem o espaço
   * disponível em partes SEMPRE iguais, sem sobra pros cantos — mesmo
   * `gap:5px` do vertical, resolvido de um jeito que não deixa resto.
   * Confirmado sem sobra em nenhuma das 5 larguras depois do conserto.
   *
   * `flex: 1 1 0` sozinho não bastou em 1024px: `Pr`/`Mc` (mesmo par,
   * mesmo `.row.flex`, mesmo `flex-basis:0`/`flex-grow:1` nos dois)
   * saíam 133px x 148px — `min-width:auto` (padrão de item flex) deixa o
   * conteúdo (um `<li>` sem quebra dentro da lista de `Mc`) vencer o
   * rateio igual e forçar a própria caixa pra cima do que sobraria pro
   * vizinho, que encolhe pra compensar. `min-width: 0` desliga esse piso
   * — o texto pode quebrar linha em vez de esticar a caixa — e as duas
   * colunas voltam a ficar exatamente iguais, confirmado nas 5 larguras. */
  flex: 1 1 0;
  min-width: 0;
}
/* Consequência do `flex: 1 1 0` acima: o `.sidebar-block` (filho único de
 * `.block-item`, ele mesmo sem largura própria — sizing por conteúdo,
 * `flex:0 1 auto` implícito) precisa preencher a largura nova do pai, ou
 * a caixa visível (borda/fundo) fica menor que a coluna que ela ocupa,
 * reabrindo o achado 2c por outro caminho. Só o eixo horizontal — a
 * vertical continua por conta do `align-items: stretch` já testado acima
 * (`height: 100%` seria a mesma tentativa descartada, ver comentário). */
.container .sidebar .row.flex .sidebar-block {
  width: 100%;
}
/* `height: 100%` no `.sidebar-block` (filho único de `.block-item`) foi
 * cogitado como o "último elo" da rede de segurança acima — testado ao
 * vivo e DESCARTADO: quebra o `margin-top: 5px` do próprio
 * `.sidebar-block` (o filho passa a ocupar 100% da altura do item JÁ
 * esticado, e o margin vira excedente por cima disso, comendo o vão de
 * 5px entre fileiras — medido: virou 0px entre `Ap/P` e `Pr/Mc`, e entre
 * `Pr/Mc` e `Obs`). `align-items: stretch` sozinho, nos dois níveis
 * acima, já é suficiente — sem regressão nenhuma medida (`Pr`/`Mc`
 * continuam na mesma altura de antes, `104px`, vão de `5px` preservado
 * em todo lugar).
 */

/* Mesmo achado nas "associated images" (grade de casos relacionados, fim
 * da página): 20px de margem vertical entre thumbnails
 * (`.material-box-item { margin-bottom: 20px }`) contra 30px de gutter
 * horizontal (mesmo mecanismo do Bootstrap acima). Os círculos já são
 * arredondados (`.item-thumb { border-radius: 50% }`) — só o espaçamento
 * precisa padronizar, mesmo valor de 5px do ajuste acima. */
.container .associated .material-box .material-box-item {
  margin-bottom: 5px;
  padding-left: 2.5px;
  padding-right: 2.5px;
}

/* Sessão noturna de 2026-08-31 — `.view-buttons { right: -16px }`
 * (styles.legacy.css) posiciona os botões de download/zoom da imagem
 * principal 16px pra fora da borda direita de `.box-image` de propósito
 * (flourish do legado, folga sobrando em telas largas). Abaixo de 768px
 * não sobra: o card ocupa a largura útil inteira e os 16px empurram
 * `.view-buttons` (55px) 1px além do viewport (medido em 390px,
 * `npm run shots`) — estoura o documento inteiro em 1px, mesmo
 * comportamento já visto e corrigido pro grid de imagens (achados 6-9,
 * docs/34-AUDITORIA-INTERFACE.md). `right: -15px` mantém o mesmo desenho
 * "pra fora da borda" com 1px a menos de saliência — imperceptível, sem
 * recuar pro 0 flush que mudaria a moldura visual. */
@media (max-width: 767px) {
  .box-image .view-buttons {
    right: -15px;
  }
}

/* Revisão datada 2026-09-14 — pedido do Gustavo, quatro acabamentos novos
 * nesta mesma página.
 *
 * 1) Entalhe do rótulo por `clip-path`, não retângulo branco. `.block-head`
 * (view-material.legacy.css) cobria a borda superior do box com
 * `background:#fff` posicionado por cima (`position:absolute;top:-28px`,
 * conectando visualmente os boxes) — funciona, mas é um retângulo opaco
 * flutuando por cima de qualquer coisa que esteja atrás.
 *
 * Primeira tentativa (descartada, capturada ao vivo): `clip-path` direto em
 * `.sidebar-block` — errado, porque `clip-path` recorta TODOS os
 * descendentes ao box do próprio elemento, `position:absolute` ou não. O
 * `.block-head` mora de -28px a +22px (relativo ao topo da caixa) bem de
 * propósito — a maior parte dele fica ACIMA de y:0, fora dos 0–100% que
 * `clip-path` cobre —, então o próprio rótulo sumia (só a fatia que
 * mergulha na caixa continuava visível, por cima do `<h4>`).
 *
 * Versão corrigida: a borda vira um `::before` — elemento PRÓPRIO, sem o
 * rótulo como descendente —, e é ESSE pseudo-elemento que leva o
 * `clip-path`. `.sidebar-block` perde a borda real (o pseudo desenha a
 * borda no lugar, mesmo `inset:0`); `.block-head` continua fora de
 * qualquer clip, livre pra flutuar por cima como sempre flutuou — só sem
 * fundo branco, porque não sobra borda/fundo ali embaixo pra esconder.
 */
.container .sidebar .row .sidebar-block {
  border: none;
  position: relative;
}
.container .sidebar .row .sidebar-block::before {
  content: '';
  position: absolute;
  inset: 0;
  border: 2.5px solid #deff02;
  border-radius: 6px;
  /* Faixa cortada (26px de altura, 100px de largura, canto superior
   * esquerdo) generosa de propósito: cobre o par mais largo (ícone +
   * sigla de 2 letras, "Ap"/"Pr"/"Mc"/"Ds") sem precisar calcular por
   * bloco — sobra nos blocos de sigla única (M/C) só corta a BORDA nesse
   * trecho, sem tocar em conteúdo (o pseudo não tem filho nenhum). */
  clip-path: polygon(0 26px, 100px 26px, 100px 0, 100% 0, 100% 100%, 0 100%);
  pointer-events: none;
}
.container .sidebar .row .sidebar-block .block-head {
  background: none;
}

/* 2) Setas de navegação da imagem principal (`.arrow-img`) — trocaram de
 * caractere de texto (‹ ›, view-material.legacy.css: font-size 50px,
 * padding-left 18px pra compensar o glifo assimétrico) pra ícone lucide
 * (`ChevronLeft`/`ChevronRight`, SVG) em `case-view.tsx`. Centralização
 * aqui, não em Tailwind: `.arrow-img{display:inline-block}` do legado é
 * regra sem camada, sempre vence a utilitária `flex` do Tailwind (mesmo
 * mecanismo de `image-grid-system.css`, topo deste arquivo). `padding-
 * left`/`font-size` do legado zerados — existiam só pra empurrar o glifo
 * de texto, sem função com um SVG já centralizado por flex.
 */
.container .first-row .col-1 .box-image .img-navigation .arrow-img {
  display: flex;
  align-items: center;
  justify-content: center;
  padding-left: 0;
  font-size: 0;
  color: #fff;
}

/* 3) Download/zoom sobre a imagem principal (`.view-icons`) — mesmos
 * ícones fonte (icomoon) trocados por SVG lucide (`Download`/`ZoomIn`) em
 * `case-view.tsx`/`image-zoom-viewer.tsx`: o glifo de fonte não
 * centralizava de verdade dentro do círculo (bearing assimétrico da
 * própria fonte, "descentralizado" — pedido do Gustavo) e saía grande
 * (35px numa área útil de ~37px). Cor/hover do legado miravam `span`
 * (`enable-icon span`/`disable-icon span`) — não batem mais com o ícone
 * novo; refeitos aqui pro `svg`, mesmas cores de sempre. `add-to-
 * collection-button.tsx` continua com `span`/ícone de fonte (fora do
 * pedido) — as regras abaixo não têm efeito lá (não existe `svg` pra
 * bater), sem regressão.
 */
.enable-icon svg {
  color: #979797;
}
.enable-icon:hover svg {
  color: #deff02;
}
.disable-icon svg {
  color: #979797;
}