Componentes
51. Personalização de colunas
seed-componentes.md v1.43 · §51seção 53 de 9851-personalizacao-de-colunas-estavel-f7-2-2026-08.md · MD5 4f357660Título completo no canon: Personalização de colunas — estável (F7.2, 2026-08-15) · PC1–PC7 · gabarito A3
Base (3 rodadas, 2026-08-15): R1 — Carbon (#10166: redimensionar coluna foi triado como "not pursuing" no core; #4750/#4751 especificam reorder/resize e declaram "drag and drop is not accessible", prevendo caminho de teclado) · Fiori (diálogo de personalização com mover para cima/baixo; régua de ~20 colunas separando o diálogo simples do complexo). R2 — React Aria
ResizableTableContainer+ColumnResizer: Enter entra em modo de redimensionamento, setas ajustam, e o leitor de tela opera o resizer como slider, com suporte aforced-colors; custo declarado pela própria doc: dentro do container as larguras deixam de ser do algoritmo nativo e passam a ser calculadas em JS · TanStackcolumnSizing/columnOrder, com aviso sobre bibliotecas de DnD em markup<table>. R3 — SC 2.5.7 (arraste tem de ter alternativa de ponteiro único) · SC 2.5.8 (alvo ≥24px — o resizer de 1px do produto de referência reprova).
| # | Decisão | Porquê | Descartado |
|---|---|---|---|
| PC1 | O resizer é role="slider": aria-valuemin/max/now, nome acessível citando a coluna ("Largura da coluna Cliente"), setas ajustam em passos, Home/End vão aos limites |
É a única semântica que descreve o que a operação faz (mover um valor numa faixa) e é a que a stack já implementa e testou com AT | div arrastável sem papel (invisível para AT) · botão que abre um campo numérico (perde a manipulação direta) |
| PC2 | Alvo de acerto ≥24px sobre linha visível de 1px (SC 2.5.8), com o alvo invisível por ::before |
O mesmo mecanismo do resizer de split do CP29 — um contrato, dois usos. O produto de referência usa 1px sem área ampliada e reprova a norma | Handle visível de 8–12px (ruído em tabela densa, e ainda reprova) |
| PC3 | Redimensionar é DESLIGADO abaixo de 640px | Gesto de precisão não sobrevive ao dedo, e no estreito a decisão certa é qual coluna aparece (LD3), não qual é a largura dela | Manter o resizer no toque com alvo maior (rouba área da própria coluna) |
| PC4 | Reordenar coluna tem os três caminhos do CP30: arraste · "mover para…" no menu do cabeçalho · teclado, com anúncio em live region | SC 2.5.7 exige ponteiro único além do teclado; e a medição do Carbon diz que todos os usuários testados esperavam arrastar — o arraste fica, como caminho rico | Só arraste (norma) · só diálogo (frustra a expectativa medida) |
| PC5 | O PAINEL DE COLUNAS é o caminho completo sem arraste: mostra/oculta, ordem (mover ↑↓), e declara a importância LD3 de cada coluna | Um lugar só resolve reorder acessível, visibilidade e a decisão editorial do LD3 — que hoje vive espalhada. É o diálogo do Fiori com o nosso vocabulário | Três controles separados (o usuário não relaciona) · esconder a importância (a coluna que some no estreito vira acidente) |
| PC6 | Largura mínima por coluna, e a largura é estado do GABARITO (persiste por tela, não por sessão global) | Sem mínimo, uma coluna vira 8px e some sem aviso; e persistência global faria a mesma coluna nascer torta em outra tela | Sem mínimo · persistência entre usuários (é preferência pessoal) |
| PC7 | Fronteiras: o cálculo de largura em JS (custo do React Aria) só entra quando o resize é ligado — tabela sem resize continua no algoritmo nativo do browser; salvar visões nomeadas = produto | Não se paga o custo de layout de quem não usa o recurso; e "visões salvas" é decisão de produto, não de DS | Ligar o container de resize sempre (custo sem contrapartida) |
Nota de integração, medida no produto de referência: resize e reorder combinados já
produziram bug documentado (a largura "lembra" a posição antiga da coluna — Carbon IoT #1016).
A ordem correta é reordenar → recalcular larguras a partir da ordem nova, e a suíte guarda o
par. (Guardas: suite-container.mjs, RSZ-01…RSZ-04.)
Também cita o §51: tela-detalhe.