.table-wrapper {
overflow-x: auto;
-webkit-overflow-scrolling: touch;
border: 1px solid var(--border-color);
}
.table-wrapper table {
width: 100%;
border-collapse: separate;
border-spacing: 0;
}
/* Prima coloana ramane vizibila la scroll */
.table-wrapper th:first-child,
.table-wrapper td:first-child {
position: sticky;
left: 0;
background: var(--bg-surface);
z-index: 2;
box-shadow: 2px 0 5px rgba(0, 0, 0, 0.05);
}Am refăcut recent interfața pentru un produs B2B intern cu 1.200 de utilizatori activi. Clientul a zis din start: „nu ne interesează mobilul, băieții lucrează doar de pe laptopuri”. Evident, la două săptămâni după lansare, 28% din sesiunile de autentificare veneau de pe telefoane, direct din depozite sau din mașină.
Când ai un ecran plin de date agregate, layout-ul responsive nu e doar o chestiune de flex-wrap: wrap. Sunt trei puncte critice unde dashboard-urile crapă urât: meniul lateral, tabelele cu 10+ coloane și metricile din header.
1. Sidebar-ul: nu ascunde navigarea fără sens
Pe desktop vrei un sidebar fix, eventual pliabil la nivel de iconițe dacă utilizatorul vrea mai mult spațiu util. Pe ecrane mici, treaba asta devine un chin dacă încerci să păstrezi sidebar-ul vizibil.
Soluția curată pe care o folosesc acum se bazează pe o simplă variabilă CSS controlată dintr-o clasă pe <body> sau pe containerul rădăcină. Pe ecrane sub 1024px, sidebar-ul trece automat în mod off-canvas (transform: translateX(-100%)) și devine modal doar când apeși pe hamburger menu. Nu încerca să comprimi textele din meniu la 10px doar ca să încapă lângă conținut. Pierzi lizibilitatea complet. Singurul trade-off sincer aici: dacă utilizatorul are un ecran intermediar, cum e o tabletă în portrait, un drawer acoperă conținutul când e deschis, dar e un compromis mult mai decent decât să mănânci 200px din lățimea oricum mică.
2. Tabelele de date: scroll orizontal vs. transformare în carduri
Aici se dau cele mai mari bătăi de cap. Soluția „clasică” recomandată de mulți este să transformi rândurile din tabel în carduri folosind display: block pe td și pseudoelemente td::before cu etichete.
Sincer? Merge excelent pentru tabele simple de 3-4 coloane. Pentru tabele reale din contabilitate sau CRM-uri, cu 12 coloane, filtre, dropdown-uri de acțiuni și statusuri colorate, varianta cu carduri devine un coșmar de 4 metri lungime la scroll vertical. Pierzi capacitatea utilizatorului de a scana datele rapid pe verticală.
Ce a funcționat impecabil în producție a fost un wrapper simplu cu overflow-x: auto, dar cu prima coloană setată pe position: sticky. Astfel, identificatorul principal (numele clientului sau numărul facturii) rămâne pe ecran în timp ce utilizatorul dă scroll spre dreapta pentru detalii. Atenție doar la border-collapse: dacă folosești collapse, sticky pe celule se comportă bizar pe Safari; pune border-collapse: separate și gestionează bordurile manual.
3. Cardurile de metrici: container queries bat media queries
Grid-ul de cards e banal pe un ecran lat, dar devine problematic când ai layout-uri complexe cu panouri redimensionabile. Dacă folosești doar viewport media queries, cardul se raportează la lățimea ecranului, nu la zona în care se află.
De când Container Queries au suport de peste 90%, le pun direct pe secțiunea de cards:
.dashboard-grid {
container-type: inline-size;
display: grid;
grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
gap: 1rem;
}
Dacă sidebar-ul e deschis sau ecranul se îngustează, containerul se adaptează singur, fără să calculezi manual lățimea sidebar-ului în breakpoint-uri de @media.
Voi cum abordați tabelele mari pe mobil? Rămâneți la scroll orizontal cu coloane înghețate sau ați găsit o cale mai bună să prezentați 15 coloane pe un ecran de iPhone?