/* Containerul care permite scroll orizontal cu indicator vizual */
.table-container {
position: relative;
overflow-x: auto;
-webkit-overflow-scrolling: touch;
background:
linear-gradient(to right, white 30%, rgba(255,255,255,0)),
linear-gradient(to right, rgba(255,255,255,0), white 70%) 100% 0,
radial-gradient(farthest-side at 0 50%, rgba(0,0,0,.2), rgba(0,0,0,0)),
radial-gradient(farthest-side at 100% 50%, rgba(0,0,0,.2), rgba(0,0,0,0)) 100% 0;
background-repeat: no-repeat;
background-size: 40px 100%, 40px 100%, 14px 100%, 14px 100%;
background-attachment: local, local, scroll, scroll;
}
table {
width: 100%;
border-collapse: collapse;
white-space: nowrap; /* previne wrapping-ul dubios pe mobil */
}Să fim sinceri: să înghesui un dashboard plin de grafice, KPI-uri și tabele pe un ecran de iPhone SE e iadul pe pământ pentru orice frontend-ist. Am avut cazul ăsta recent la un SaaS de logistică cu vreo 12.000 de utilizatori activi lunar, unde am descoperit (spre groaza mea) că peste 30% din manageri verificau stocurile de pe telefon, direct din depozit. N-am avut de ales, a trebuit să refac tot layout-ul de la zero.
În loc să ascund pur și simplu elemente sperând că nu va observa nimeni, am aplicat trei reguli tactice care mi-au salvat build-ul și nervii.
Sidebar-ul collapsible: mai simplu e mai sigur
La început m-am complicat cu layout-uri dinamice care împingeau conținutul principal când deschideai meniul. O prostie care strica toate graficele SVG și cerea recalculări de dimensiuni pe canvas-uri. Am trecut rapid la abordarea clasică: pe desktop sidebar-ul stă fix în stânga la 260px, iar pe mobil devine un overlay complet cu un backdrop-filter: blur(4px) în spate.
Merge excelent pentru că nu modifică layout-ul paginii active, dar are și un trade-off sincer: când meniul e deschis, utilizatorul pierde complet contextul din spatele lui. Pentru noi a fost un compromis acceptabil, utilizatorul vrea doar să schimbe pagina rapid, nu să citească date prin transparența meniului.
Coșmarul tabelelor: Scroll orizontal vs. Carduri
Aici e marea bătălie. Ai un tabel masiv cu 12 coloane: ID, Nume client, Status, Dată, plus încă vreo 8 detalii tehnice. Dacă îl transformi în "carduri" pe mobil (adică fiecare rând devine un bloc vertical), pierzi complet posibilitatea de a compara datele rapid prin scroll vertical.
La proiectul nostru, am mers pe o soluție hibridă. Am păstrat structura de tabel, dar l-am învelit într-un container cu scroll orizontal. Ca să fie clar că mai există date în dreapta, am adăugat un indicator vizual: o umbră subtilă generată din CSS linear-gradient, care dispare doar când ajungi la capătul scroll-ului.
Pentru ecrane foarte mici, am păstrat doar 3 coloane esențiale (ID, Nume, Status), iar restul coloanelor le-am ascuns în mod implicit, fiind accesibile printr-un buton de „expand” pe fiecare rând.
Grid-ul de carduri și container queries
În loc de media queries-urile clasice (@media (max-width: 768px)), am trecut la container-type: inline-size. E o schimbare masivă de paradigmă. De ce? Pentru că dacă ai un layout în care sidebar-ul se poate restrânge, spațiul disponibil pentru widget-uri se schimbă, chiar dacă lățimea ecranului (viewport-ul) rămâne exact aceeași.
Folosind container queries, cardurile de statistici se rearanjează singure în funcție de spațiul pe care îl au la dispoziție în containerul părinte, nu de dimensiunea fizică a ecranului de telefon sau tabletă.
Care e abordarea voastră preferată pentru tabelele mari pe mobil? Mergeți pe scroll orizontal sau preferați să transformați fiecare rând într-un card de tip listă?