vaza e o canto vira um quadrado. Popover de filtro/menu do MudDataGrid não é clipado: renderiza fora,
no MudPopoverProvider. */
.sis-data-grid.mud-table {
border: 1px solid var(--mud-palette-lines-default);
border-radius: var(--mud-default-borderradius, 8px);
overflow: hidden;
}
/* 🔒 A SOMBRA DE ROLAGEM — o que faz a última coluna deixar de sumir sem aviso em 1024×768.
⚠️ O diagnóstico que circulava ("o SisDataGrid CORTA colunas em 1024") estava ERRADO, e a diferença muda o
conserto: medido no navegador, o `.mud-table-container` já tem `overflow-x: auto` e JÁ rola (969px de
conteúdo em 718px de caixa, na Consulta de Consignações). Nenhuma coluna é inalcançável. O que faltava era
o operador SABER que há mais à direita: `offsetHeight - clientHeight` dava ZERO, ou seja, a barra é
overlay — aparece enquanto se arrasta e some parada. Na tela isso vira uma Situação fatiada pela borda do
card e uma coluna de Ações que simplesmente não existe.
🔴 A primeira tentativa foi devolver a barra CLÁSSICA com `::-webkit-scrollbar { height }`. Ficou INERTE, e
a medição vale registrar: quando `scrollbar-width` está declarado no elemento (o MudBlazor declara `thin`),
o Chromium IGNORA os pseudo-elementos `::-webkit-scrollbar` inteiros. A regra existia no arquivo servido
(conferido por `curl`) e o `offsetHeight - clientHeight` continuou zero — o mesmo formato de defeito do
padding da grade de itens: presente, e sem efeito.
A saída é PINTURA, que não depende de como a plataforma desenha barra: quatro gradientes, dois `local`
(viajam com o conteúdo e TAPAM a sombra quando aquela ponta está à vista) e dois `scroll` (fixos na caixa,
são a sombra). O resultado é uma sombra que só aparece do lado em que há conteúdo escondido, e desaparece
sozinha na consulta que cabe na tela — sem uma linha de JavaScript e sem medir largura.
⛔ Não é `overflow-x: scroll`: desenharia trilho em TODA consulta do repo, inclusive nas que cabem, comendo
altura numa tela onde falta altura (a ordem de sacrifício do catálogo de design).
⛔ Também não é coluna de Ações fixa (`position: sticky`): seria mais confortável, mas exige fundo opaco na
célula e atropelaria o realce da linha selecionada e do hover, que é o outro mecanismo desta grade. Fica
registrado como possibilidade, não como omissão. */
.sis-data-grid .mud-table-container {
background-image:
linear-gradient(to right, var(--mud-palette-surface) 60%, rgba(0, 0, 0, 0)),
linear-gradient(to left, var(--mud-palette-surface) 60%, rgba(0, 0, 0, 0)),
linear-gradient(to right, color-mix(in srgb, var(--mud-palette-text-primary) 30%, transparent), rgba(0, 0, 0, 0)),
linear-gradient(to left, color-mix(in srgb, var(--mud-palette-text-primary) 30%, transparent), rgba(0, 0, 0, 0));
background-position: left center, right center, left center, right center;
background-repeat: no-repeat;
background-size: 28px 100%, 28px 100%, 22px 100%, 22px 100%;
background-attachment: local, local, scroll, scroll;
}
/* -------------------------------------------------------------------------
A barra de rolagem horizontal do TOPO do grid (ver grid.js,
acoplarBarraDoTopo; o markup é do SisDataGrid.razor).
A barra nativa mora no RODAPÉ da área rolável, e numa consulta longa o
operador precisa descer a página inteira só para deslocar as colunas de
volta.
🔑 E por isso ela é PEGAJOSA: a dor da issue é ALCANCE, não posição. Uma
faixa fixa no topo do grid só ajudaria enquanto o topo estivesse na tela —
no meio de uma lista longa as DUAS barras ficam fora da vista. Grudada sob
a app bar, ela segue o operador lista abaixo.
⛔ Nasce com altura ZERO e só cresce com transbordo: trilho permanente numa
grade que cabe na tela é ruído, e é a mesma razão pela qual `overflow-x:
scroll` já tinha sido recusado no container acima.
⚠️ Ela é IRMÃ do grid, fora do `.sis-data-grid.mud-table` — e isso é o que
permite o sticky sem tocar no `overflow: hidden` do card: `hidden` cria
contexto de rolagem e prenderia a faixa dentro dele (medido: `top` ia para
-735px com a página rolada).
------------------------------------------------------------------------- */
.sis-grid-scroll-topo {
position: sticky;
top: var(--mud-appbar-height, 64px);
z-index: 3;
overflow-x: auto;
overflow-y: hidden;
height: 0;
/* Fina e discreta, como manda o tema. ⚠️ Declarar `scrollbar-width` AQUI faz o Chromium ignorar todo
`::-webkit-scrollbar` deste elemento — é a cicatriz registrada no bloco do `.mud-table-container`
acima. ⇒ ⛔ não adianta acrescentar um bloco de pseudo-elemento para esta faixa: ele nasce morto.
Quem responde pela aparência no Chromium é esta linha mais o trilho pintado abaixo. */
scrollbar-width: thin;
scrollbar-color: var(--mud-palette-lines-inputs) transparent;
}
.sis-grid-scroll-topo--ativa {
height: 10px;
margin-bottom: 2px;
/* 🩸 O TRILHO é desenhado AQUI, ⛔ não deixado por conta da barra do navegador — medido no Chromium
(E2E, 2026-09-11): a barra é OVERLAY tanto com `scrollbar-width: thin` quanto com `auto`
(offsetHeight == clientHeight nos dois), e overlay some quando ninguém está arrastando. Uma faixa
invisível em repouso derrota o pedido que a originou: ela existe para o operador VER que dá para
arrastar ali em cima.
⚠️ Depender do SO não serve: no Windows do cliente a barra costuma ser clássica e visível, e no
headless do CI não é — o mesmo CSS entregaria duas experiências.
⚠️ A cor sai do TEXTO, ⛔ não de `--mud-palette-lines-default`: medido, aquela é rgb(220 225 232) e a
55% sobre o card branco dá um trilho que ⛔ não aparece nem na captura. Pelo texto, o mesmo token
serve aos dois temas.
⚠️ E a mistura é com `surface`, ⛔ não com `transparent`: grudada sob a app bar a faixa FLUTUA sobre
as linhas da grade, e um trilho translúcido deixaria o texto delas atravessar por baixo. */
background-color: color-mix(in srgb, var(--mud-palette-text-primary) 22%, var(--mud-palette-surface));
border-radius: 5px;
}
/* O trilho não desenha nada: a largura dele é o que dá à faixa a MESMA extensão rolável da tabela, e é
isso que faz o polegar ter o tamanho proporcional em vez de percorrer tudo em dois pixels. */
.sis-grid-scroll-topo__trilho {
height: 1px;
}
/* Dentro de um diálogo quem rola é o conteúdo dele, e ⛔ não há app bar por cima — o offset da casca
empurraria a faixa para dentro da grade. */
.mud-dialog .sis-grid-scroll-topo {
top: 0;
}
/* Cabeçalho diferenciado: fundo cinza, texto secundário em caixa alta leve,
sublinha de 2px. Distingue o header do corpo sem depender de cor forte.
A sublinha usa table-lines (a mesma cor das linhas do corpo, agora legível) em vez de lines-default —
assim o cabeçalho é a MESMA linha, só mais grossa, e não uma segunda cor competindo. */
.sis-data-grid .mud-table-head th,
.sis-data-grid .mud-table-head .mud-table-cell {
background-color: var(--mud-palette-gray-light);
color: var(--mud-palette-text-secondary);
font-weight: 600;
font-size: 0.72rem;
letter-spacing: 0.04em;
text-transform: uppercase;
border-bottom: 2px solid var(--mud-palette-table-lines);
}
/* SEM zebra por padrão (decidido em 2026-07-25, junto com o reforço das linhas).
Havia aqui uma regra que listrava as linhas pares de TODO .sis-data-grid, INCONDICIONALMENTE — ela ignorava
o parâmetro `Striped` do SisDataGrid (que é false por default), então a tela não tinha como desligar a
zebra nem pedindo. Duas razões pra ela sair:
1. Enquanto a linha de separação era invisível, a zebra fazia o trabalho dela por tabela. Com o separador
legível, as duas guiam o olho pela mesma linha — Material Design pede UM dos dois, não os dois, e o
fundo uniforme devolve destaque ao hover e à seleção, que é onde a informação de estado mora.
2. Sem a regra, o parâmetro `Striped` volta a FUNCIONAR: quem passar Striped="true" recebe o listrado
nativo do MudBlazor (que usa o mesmo --mud-palette-table-striped). Deixou de ser sempre-ligado e virou
opt-in por tela, que é o que a assinatura do componente sempre prometeu.
O TableStriped continua na paleta justamente por causa do (2) — não é valor órfão. */
/* ────────────────────────────────────────────────────────────────────────────────────────────────────────
CÉLULA NUMÉRICA e CÉLULA COM CAMPO (2026-09-01)
🩸 Nasceu de uma captura da revisão de XML de entrada, onde o dono viu os itens "tortos": com dez colunas
e um campo de busca dentro da última, o dinheiro QUEBRAVA A LINHA — "R$" numa linha e "45,90" na outra —
e os valores à direita paravam em alturas diferentes, um por linha. Alinhar à direita não basta quando o
conteúdo pode quebrar: o que o olho percebe é o fim da PRIMEIRA linha, e ele muda de célula para célula.
⛔ A regra NÃO é global por `text-align:right` inline: seria adivinhar a intenção pelo estilo. A tela
declara a classe, e ela diz o que a célula É — número —, não como ela aparece.
⚠️ O `nowrap` empurra a largura, e é de propósito: quem rola é o CONTAINER da grade (o
.mud-table-container já tem overflow local, com as sombras de rolagem logo acima), ⛔ nunca a página.
É a mesma régua do HorizontalScrollbar da nota fiscal digitada. */
.sis-data-grid .sis-cell-numero {
white-space: nowrap;
text-align: right;
}
/* Grade de CONDIÇÕES de pagamento (editor de forma de pagamento).
🩸 Nasceu de uma captura em 1024×768: com a coluna "Vencimentos (dias)" a grade foi a doze colunas, e o
`overflow-x:auto` do container NÃO basta — sem uma largura mínima o navegador prefere ESPREMER as células
a rolar, e os campos numéricos passaram a exibir "(" no lugar de "0,00", com a coluna "Ativo" cortada na
borda do diálogo.
⚠️ O min-width vai no
, ⛔ não no container: é o container que rola, e dar-lhe largura mínima
empurraria o próprio diálogo. */
.sis-condicoes-tabela table {
min-width: 1320px;
}
/* Célula que hospeda um CAMPO (busca vinculada, numérico inline): o campo é alto e o texto das vizinhas é
de uma linha só — sem isto, a linha inteira cresce e o texto flutua contra o campo. */
.sis-data-grid .sis-cell-campo,
.sis-data-grid td:has(.sis-lookup-field),
.sis-data-grid td:has(.mud-input-control) {
vertical-align: middle;
}
/* Transição do realce: a faixa "acende" em vez de piscar. É o que torna o hover perceptível mesmo quando o
mouse atravessa o grid rápido — o olho registra o movimento da cor, não só o estado final. */
.sis-data-grid .mud-table-body .mud-table-row .mud-table-cell {
transition: background-color 0.12s ease-out;
}
/* Hover: realce esverdeado (o TableHover da paleta, reforçado em SisThemes.cs — ver o comentário lá), sem
cobrir a seleção. O !important vence o sombreamento próprio do MudDataGrid, que também escreve
background-color na linha em hover e, sendo mais específico em alguns temas, apagava este realce. */
.sis-data-grid .mud-table-body .mud-table-row:hover:not(.sis-grid-row-selected) td {
background-color: var(--mud-palette-table-hover) !important;
}
/* Linha selecionada: fundo tingido com a primária + faixa de acento à esquerda.
O !important vence o sombreamento de hover/zebra do próprio MudDataGrid.
NÃO usa --mud-palette-primary-hover (o "-hover" que o MudBlazor deriva de HoverOpacity, ~6% de opacidade —
pensado pra um :hover discreto, não pra marcar "esta é a linha selecionada"). Com opacidade tão baixa, no
tema CLARO a seleção quase some sobre o branco do card — foi o que o dono reportou ("não dá pra enxergar").
Em vez disso, mistura a primária do tema ativo (--mud-palette-primary-rgb, publicada pelo MudThemeProvider)
numa opacidade fixa e mais forte, dedicada só a este estado — segue o tema (muda com Light/Dark/Food/...)
mas não depende do HoverOpacity global nem se confunde com o :hover comum de botão/menu.
Seleção x hover não competem por serem tons diferentes do mesmo verde: a seleção soma DOIS sinais que o
hover não tem — a faixa de acento de 4px e o peso da fonte. */
.sis-data-grid .mud-table-body tr.sis-grid-row-selected td {
background-color: rgba(var(--mud-palette-primary-rgb), 0.22) !important;
font-weight: 600;
}
.sis-data-grid .mud-table-body tr.sis-grid-row-selected td:first-child {
box-shadow: inset 4px 0 0 0 var(--mud-palette-primary);
}
/* Linha de separação entre registros: o MudBlazor usa var(--mud-palette-table-lines) no border-bottom de
cada célula (1px). O valor de TableLines pro tema Light era quase invisível sobre o branco do card —
reforçado em SisThemes.cs (ver o comentário lá) pra ficar claramente perceptível sem virar uma grade
pesada. Aqui só reafirma a intenção — o valor real é publicado pela paleta ativa. */
.sis-data-grid .mud-table-body .mud-table-row .mud-table-cell {
border-bottom: 1px solid var(--mud-palette-table-lines);
}
/* Última linha sem separador: quem fecha o corpo é o contorno do card. Evita a linha dupla (separador +
borda) que aparece logo acima do rodapé/paginador. */
.sis-data-grid .mud-table-body .mud-table-row:last-child .mud-table-cell {
border-bottom: none;
}
/* =========================================================================
NO CELULAR CADA REGISTRO É UM CARTÃO — a grade empilhada CABIA e ⛔ não se LIA
=========================================================================
🩸 Medido em 2026-09-13 (#2739), em Pessoas, Vendas e Contas a receber a 390×844: o vão entre dois
registros consecutivos era **0px**, o `
` ⛔ não tinha borda, margem nem fundo próprio, e a fronteira
entre dois REGISTROS era a MESMA linha de 1px que separa dois CAMPOS do mesmo registro. Com 265 a 389px
por registro cabem 2 a 3 por tela, e o que o operador lê é "Ações › Emissão…".
🔑 **A causa tem DUAS metades, e a segunda é nossa.** O MudBlazor empilha em `.mud-xs-table` desenhando
CÉLULAS (flex + `::before { content: attr(data-label) }`), e a única fronteira que ele prevê é o
`border-bottom` da ÚLTIMA célula da linha — ou seja, ele já tentava separar registro de registro. Quem
apagou a distinção foi a regra do Sis logo acima, que põe `border-bottom` em TODA célula: escrita para o
modo TABELA (onde "toda célula" é "toda linha", e está certo), ela vira "toda linha de campo" no modo
empilhado. ⇒ **regra de grade escrita sem olhar o modo empilhado erra por metade**, e o erro é mudo.
🩸 E o achado ⛔ não veio da medição: veio de uma PERGUNTA do dono. A grade tinha entrado no "já funciona"
do handoff porque passou na largura e nos alvos de toque. ⇒ **"cabe" ⛔ não é "se lê"** — portão de
largura fica verde com os registros indistinguíveis, e é por isso que esta fatia ganhou portão PRÓPRIO
(`GradeEmCartoesNoCelularTests`), que mede o VÃO entre registros.
⚠️ O corte é o MESMO do resto da casca (`599.98px`, o `viewport.js`), e em 768/1024 a grade continua
TABELA — medido. ⛔ Não mexa aqui achando que alcança o terminal de 1024×768.
📖 docs/handoff-interface-no-celular-2026-09-13.md §3 (D3b) */
@media (max-width: 599.98px) {
/* A tabela e o corpo viram bloco: sem isto o `
` com `display: block` fica sob um `table-row-group`,
e o navegador o embrulha numa linha/célula anônima — margem e borda do cartão passam a não valer. */
.sis-data-grid .mud-table-root,
.sis-data-grid .mud-table-body {
display: block;
}
/* ⛔ O `border-top` do corpo (do MudBlazor) some: com cartões ele vira um traço solto acima do primeiro. */
.sis-data-grid .mud-table-body {
border-top: none;
}
/* O CARTÃO. `overflow: hidden` é o que faz o raio recortar o fundo da primeira e da última linha de
campo — sem ele o canto arredondado aparece "furado" pelo realce de seleção. */
.sis-data-grid .mud-table-body > .mud-table-row {
display: block;
margin: 0 0 12px;
border: 1px solid var(--mud-palette-lines-default);
border-radius: var(--mud-default-borderradius, 8px);
background-color: var(--mud-palette-surface);
overflow: hidden;
}
/* 🔑 A ÚLTIMA célula ⛔ não leva separador: quem fecha o registro é a borda do cartão. É a correção da
metade que este arquivo tinha errado — e é ela que devolve significado à linha de 1px, que volta a
dizer só "próximo CAMPO". */
.sis-data-grid .mud-table-body > .mud-table-row > .mud-table-cell:last-child {
border-bottom: none;
}
/* O separador ENTRE CAMPOS fica mais leve que a borda do cartão — a hierarquia é o que se lê. */
.sis-data-grid .mud-table-body > .mud-table-row > .mud-table-cell {
border-bottom: 1px solid color-mix(in srgb, var(--mud-palette-table-lines) 45%, transparent);
}
/* 🔴 O `!important` aqui ⛔ não é preguiça: quem escreve a largura é um `style` INLINE, posto pela TELA
para o modo TABELA — `width: 1%` na coluna de código, `min-width: 280px` na de nome, e assim em 93
consultas. Regra de classe ⛔ não vence atributo inline, e sem isto a célula de código fica com **16px**
dentro de um cartão de 364 (medido em Pessoas): o realce do registro selecionado pinta só um pedaço da
linha, e o cartão — que é uma moldura — faz esse retalho parecer defeito de renderização.
🔑 A largura de COLUNA ⛔ não tem sentido onde ⛔ não há colunas: no cartão cada campo é uma linha. */
.sis-data-grid .mud-table-body > .mud-table-row > .mud-table-cell {
width: auto !important;
min-width: 0 !important;
max-width: none !important;
}
/* ⚠️ A regra de "última LINHA sem separador" (acima, do modo tabela) ⛔ não vale aqui: no cartão cada
registro se fecha sozinho, e sem isto o último registro perderia os separadores INTERNOS dele. */
.sis-data-grid .mud-table-body > .mud-table-row:last-child > .mud-table-cell {
border-bottom: 1px solid color-mix(in srgb, var(--mud-palette-table-lines) 45%, transparent);
}
.sis-data-grid .mud-table-body > .mud-table-row:last-child > .mud-table-cell:last-child {
border-bottom: none;
}
/* O RÓTULO do campo (o `::before` do MudBlazor) recua para um papel de apoio: quem o operador lê é o
VALOR. Sem isto o rótulo repetido a cada registro disputa a leitura com o dado. */
.sis-data-grid .mud-table-body > .mud-table-row > .mud-table-cell::before {
color: var(--mud-palette-text-secondary);
font-weight: 400;
flex: 0 0 auto;
}
/* A célula de AÇÕES vira RODAPÉ do cartão: fundo tênue e os ícones à direita, para o gesto ficar no
mesmo lugar em todos os cartões. */
.sis-data-grid .mud-table-body > .mud-table-row > .mud-table-cell:last-child {
background-color: color-mix(in srgb, var(--mud-palette-table-lines) 18%, transparent);
}
/* 🔑 A célula de EXPANDIR (a do `HierarchyColumn`) ⛔ não tem `data-label` — é a única assim, e sem isto
ela ocupa uma linha inteira do cartão só com o chevron, que foi justamente o que virava "separador por
acidente" no defeito original. Compacta, ela lê como o canto do cartão. */
.sis-data-grid .mud-table-body > .mud-table-row > .mud-table-cell:not([data-label]) {
justify-content: flex-end;
padding-top: 2px;
padding-bottom: 2px;
border-bottom: none;
min-height: 0;
}
/* ⚠️ O realce de seleção pintava a célula; no cartão ele pinta o CARTÃO, senão o registro selecionado
aparece como um retângulo dentro de outro. */
.sis-data-grid .mud-table-body > .mud-table-row.sis-grid-row-selected {
border-color: var(--mud-palette-primary);
}
/* ⛔ A barra de rolagem horizontal do topo ⛔ não tem função com cartões (nada rola para o lado) e
⚠️ ela é `position: sticky`: deixada viva, some com um pedaço do primeiro cartão. */
.sis-data-grid .sis-grid-scroll-topo {
display: none;
}
}
/* -------------------------------------------------------------------------
O "ORDENAR POR" DO CELULAR (#2761) — a barra que devolve a ordenação onde o
cabeçalho não existe.
🩸 Abaixo de 600px o MudBlazor esconde o `` inteiro para empilhar os
registros. O cabeçalho é o ÚNICO lugar de onde se ordena ⇒ a capacidade
sumia sem aviso: sem botão apagado, sem mensagem — só deixava de existir.
Medido: 126 telas usam o SisDataGrid, NENHUMA declara `SortMode.None`, e são
96 colunas com `Sortable="true"` além das que herdam o default.
🔑 A barra é ESCONDIDA por padrão e revelada só aqui, ⛔ nunca o contrário:
escrita como `display: flex` com um `display: none` no `@media` do terminal,
qualquer folha carregada depois — ou um `@media` que não casasse — a deixaria
VISÍVEL no desktop, que é o lado caro do erro (ali o cabeçalho já ordena, e
dois controles para o mesmo fim discordam).
⚠️ O corte é o MESMO do cartão e do resto da casca (`599.98px`, o
`viewport.js`). ⛔ Não o mude sozinho: em 768 e 1024 a grade continua tabela,
e a barra apareceria sobre um cabeçalho que já faz o serviço.
📖 docs/handoff-interface-no-celular-2026-09-13.md §3 (D3c) */
.sis-grid-ordenar {
display: none;
}
@media (max-width: 599.98px) {
/* `relative` é o que ancora o painel da lista — ele é filho, ⛔ não popover. */
.sis-grid-ordenar {
position: relative;
display: flex;
align-items: center;
gap: 2px;
/* Encosta no primeiro cartão sem colar: o cartão já traz 12px de vão entre registros. */
margin-bottom: 4px;
}
/* ⚠️ O texto ⛔ não pode ser cortado no meio de um nome de coluna comprido ("Data de emissão"), e
⛔ não pode empurrar a seta para fora da tela: o botão encolhe e o rótulo trunca com reticências. */
.sis-grid-ordenar-botao {
min-width: 0;
flex: 0 1 auto;
overflow: hidden;
text-transform: none;
}
.sis-grid-ordenar-botao .mud-button-label {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
/* 🔑 O alvo de toque tem PISO de 44px — a régua de dedo da frente do celular. O `Size.Small` do
MudBlazor dá 30px, que é alvo de mouse. ⛔ Não troque por padding: o ícone ficaria descentrado. */
.sis-grid-ordenar-sentido {
min-width: 44px;
min-height: 44px;
flex: 0 0 auto;
}
/* O fundo que fecha a lista ao tocar FORA dela. ⚠️ `fixed` cobrindo o viewport inteiro, ⛔ não
`absolute`: o toque pode cair em qualquer ponto da tela, inclusive fora da grade. */
.sis-grid-ordenar__fundo {
position: fixed;
inset: 0;
z-index: 1200;
}
/* ⚠️ `z-index` ACIMA do fundo — senão o primeiro toque em cada item cairia no fundo e só fecharia
a lista, e o controle pareceria não responder. */
.sis-grid-ordenar__painel {
position: absolute;
top: calc(100% + 2px);
left: 0;
z-index: 1201;
min-width: 200px;
/* ⚠️ ⛔ Não pode passar da tela: com muitas colunas os últimos itens ficariam inalcançáveis. */
max-width: calc(100vw - 32px);
max-height: 60vh;
overflow-y: auto;
padding: 4px 0;
border: 1px solid var(--mud-palette-lines-default);
border-radius: var(--mud-default-borderradius, 8px);
background-color: var(--mud-palette-surface);
box-shadow: var(--mud-elevation-8);
}
.sis-grid-ordenar__item {
display: flex;
align-items: center;
/* 🩸 `justify-content` EXPLÍCITO, e ⛔ não é redundância com o default: medido no navegador, um
`