Om forfatteren
Chen Hui Jing er en autodidakt designer og udvikler med en overdreven kærlighed til CSS. At reducere antallet af kodelinjer i hendes webprojekter gør hende ekstremt glad. Hun …Mere omHuijing↬
- 11 min læsning
- CSS,JavaScript,Designmønstre,Responsivt webdesign
- Sparet til offline læsning
- Del på Twitter, LinkedIn
Tabeller er et designmønster til visning af store mængder data i rækker og kolonner, hvilket gør dem effektive til at lave sammenlignende analyser på kategoriske objekter. Tabeller er blevet brugt til dette formål allerede i det 2. århundrede, og da verden begyndte at blive digital, fulgte tabellerne med.
Det var uundgåeligt, at internettet ville understøtte visning af data i tabelform. HTML-tabeller præsenterer tabeldata på en semantisk og strukturelt hensigtsmæssig måde. Standard stilarter på HTML-tabeller er dog ikke ligefrem det mest æstetisk tiltalende, du nogensinde har set. Afhængigt af det ønskede visuelle design var det nødvendigt med en vis indsats på CSS-fronten for at pynte disse tabeller. For ti år siden blev en artikel med “Top 10 CSS Table Designs” offentliggjort på Smashing Magazine, og den får stadig en masse trafik den dag i dag.
Nettet har udviklet sig meget i løbet af det seneste årti, og det er mere bekvemt end nogensinde før at få dit websted eller din applikation til at tilpasse sig den viewport, som det bliver vist i. Når det er sagt, skal vi fortsat træffe velovervejede designvalg, der ikke går på kompromis med tilgængeligheden. Da tabeller ikke ser ud til at falde ud af popularitet lige foreløbig, lad os se, hvordan tabeller kan oprettes på nettet i 2019.
CSS-Only Options
Hvis dit datasæt ikke er så stort, og funktioner som paginering og sortering ikke er nødvendige, så overvej en JavaScript-fri løsning. Du kan få nogle ret flotte resultater, der fungerer godt på en hel række skærmstørrelser uden den ekstra vægt fra et stort bibliotek.
Det er desværre sådan, at uden hjælp fra JavaScript til noget DOM-manipulation på tilgængelighedsfronten har vi kun en håndfuld CSS-only-muligheder. Men til små datasæt er de ofte tilstrækkelige.
Mulighed 1: Gør ingenting
Vi starter med et scenarie med lav indsats. Hvis dine data passer i en tabel med kun få kolonner og mange rækker, er en sådan tabel temmelig mobilklar til at begynde med.
Det problem, du ville have, er sandsynligvis at have for meget plads på bredere skærme, så det kan være tilrådeligt at “lægge loft” over tabellens maksimale bredde med et max-width
, mens du lader den krympe efter behov på en smal skærm.
Denne slags mønster fungerer bedst, hvis dine data ikke i sig selv er linjer og linjer af tekst. Hvis de er numeriske eller korte sætninger, kan du sandsynligvis slippe af sted med ikke at gøre meget.
Mulighed 2: Style The Scroll
David Bushell skrev om sin teknik til responsive tabeller tilbage i 2012, som involverede påberåbelse af overløb og mulighed for at lade brugerne scrolle for at se flere data. Man kunne argumentere for, at dette ikke ligefrem er en responsiv løsning, men teknisk set reagerer containeren på bredden af viewport.
Lad os først se på det “grundlæggende” overløb. Forestil dig, at jeg bruger luft-kvotes omkring basic, fordi stylingen for de rullende skygger er alt andet end det. Alligevel refererer “basic” i dette tilfælde til det faktum, at tabellen ikke transformeres på nogen måde.
Denne teknik til at lave rulningsskygger stammer fra Roma Komarov og Lea Verou, der har taget udgangspunkt i hinandens idéer for at skabe magi. Den er baseret på at bruge flere gradienter (lineære og radiale) som baggrundsbilleder på det indeholdende element og bruge background-attachment: local
til at placere baggrunden i forhold til indholdet.
Det gode ved denne teknik er, at for browsere, der ikke understøtter rulningsskygger, kan du stadig rulle tabellen som normalt. Det ødelægger ikke layoutet overhovedet.
En anden rullemulighed ville være at vende tabeloverskrifterne fra en rækkekonfiguration til en kolonnekonfiguration, mens der anvendes en vandret rulning på <tbody>
-elementets indhold. Denne teknik udnytter Flexbox-adfærd til at omdanne tabellens rækker til kolonner.
Ved at anvende display: flex
på tabellen gør det <thead>
og <tbody>
til begge flex-børn, der som standard lægges ud ved siden af hinanden på samme flexlinje.
Vi gør også <tbody>
-elementet til en flexcontainer, hvilket gør alle <tr>
-elementer inden for det til flex-børn, der også lægges ud på en enkelt flexlinje. Endelig skal hver tabelcelle have deres visning indstillet til block
i stedet for standard table-cell
.
Førdelen ved denne teknik er, at overskrifterne altid er synlige, ligesom en fast overskriftseffekt, så brugerne ikke mister kontekst, når de scroller gennem datakolonnerne. En ting, man skal være opmærksom på, er, at denne teknik resulterer i en diskrepans mellem den visuelle og kildeordenen, og det gør tingene lidt uintuitivt.
Sprinkler på noget JavaScript
Som tidligere nævnt har layoutmuligheder, der involverer morphing af tabellen ved at ændre display
-værdier, nogle gange negative konsekvenser for tilgængeligheden, hvilket kræver nogle mindre DOM-manipulationer for at rette op.
Dertil kommer en række tips om brugeroplevelse, når det gælder design af datatabeller fra Andrew Coyle, herunder funktioner som paginering, sortering, filtrering osv. (funktioner, som kræver noget JavaScript for at blive aktiveret).
Hvis du arbejder med et relativt enklere datasæt, kan du måske skrive dine egne funktioner til nogle af disse funktioner.
Rows To Blocks, With Accessibility Fix
Så vidt jeg ved, stammer denne responsive teknik til datatabeller fra CSS-Tricks-artiklen “Responsive Data Tables” af Chris Coyier tilbage i 2011. Den er siden blevet tilpasset og udvidet af mange andre.
Kernen i denne teknik er at gøre brug af en media query for at skifte display-egenskaben for tabelelementet og dets børn til block
på en smal viewport.
På en smal skærm er tabeloverskrifterne visuelt skjult, men de findes stadig i tilgængelighedstræet. Ved at anvende dataattributter på tabelcellerne kan vi derefter vise etiketter for dataene via CSS, mens vi beholder indholdet af etiketten i HTML. Se nedenstående CodePen for at se, hvordan mark-up og stilarter ser ud:
Den oprindelige metode anvender en bredde på det pseudo-element, der viser labelteksten, men det betyder, at du skal vide, hvor meget plads din label har brug for til at begynde med. Ovenstående eksempel anvender en lidt anden fremgangsmåde, hvor etiketten og dataene hver især er på modsatte sider af deres indeholdende blok.
Vi kan opnå en sådan effekt via auto-margins i en flex-formateringskontekst. Hvis vi indstiller display-egenskaben for hvert <td>
-element til flex, fordi pseudo-elementer genererer bokse, som om de var umiddelbare børn af deres oprindelige element, bliver de flex-børn af <td>
.
Dernæst er det et spørgsmål om at indstille margin-right: auto
på pseudo-elementet for at skubbe cellens indhold til den yderste kant af cellen.
En anden fremgangsmåde, der gør det smalle viewport-layout, er at bruge en kombination af Grid og display: contents
. Bemærk, at display: contents
i understøttende browsere har problemer med tilgængelighed i øjeblikket, og denne metode bør ikke bruges i produktion, før disse fejl er rettet.
Men måske læser du dette, efter at disse fejl er blevet løst, i så fald er her en alternativ layoutmulighed.
Hvert <tr>
-element er indstillet til display: grid
, og hvert <td>
-element er indstillet til display: contents
. Kun de umiddelbare børn af en gittercontainer deltager i en gitterformateringskontekst; i dette tilfælde er det <td>
-elementet.
Når display: contents
anvendes på <td>
, bliver det “erstattet” af dets indhold, i dette tilfælde bliver pseudo-elementet og <span>
inden for <td>
i stedet gitterbørn.
Det, jeg godt kan lide ved denne fremgangsmåde, er muligheden for at bruge max-content
til at dimensionere kolonnen af pseudo-elementer, hvilket sikrer, at kolonnen altid vil være lige så bred som den længste etiket, uden at vi manuelt skal tildele en breddeværdi for den.
I fremtiden, når størrelsesværdierne min-content
, max-content
og fit-content
(omfattet af CSS Intrinsic & Extrinsic Sizing Module Level 3) understøttes som generelle width
og height
værdier, vil vi have endnu flere muligheder for at lægge tingene ud.
Ulempen ved denne fremgangsmåde er, at du har brug for den ekstra <span>
eller <p>
omkring indholdet i din tabelcelle, hvis den ikke allerede havde en sådan, ellers ville der ikke være nogen måde at anvende stilarter på det.
Enkle paginering
Dette eksempel viser en grundlæggende paginering implementering, der blev ændret fra denne CodePen af Gjore Milevski til at paginere på tabelrækker i stedet for divs. Det er en udvidelse af eksemplet “style the scroll”, der blev diskuteret i det foregående afsnit.
Fra et layoutperspektiv er Flexbox meget praktisk til at placere pagineringselementerne på tværs af forskellige viewportstørrelser. Forskellige projektdesigns vil have forskellige krav, men Flexbox’ alsidighed bør give dig mulighed for at tage højde for disse forskelle i overensstemmelse hermed.
I dette tilfælde er pagineringen centreret på siden og over tabellen. Betjeningselementerne til at navigere frem og tilbage er placeret på hver side af sideindikatorerne på bredere skærme, men alle fire vises over sideindikatorerne på smalle skærme.
Vi kan gøre dette ved at ændre order
-egenskaben. Visuel omfordeling af indhold bør altid ske med omtanke, da denne egenskab ikke ændrer kildesorteringen – kun hvordan den vises på skærmene.
Enkle sortering
Dette eksempel viser en grundlæggende sorteringsimplementering modificeret ud fra dette kodestykke af Peter Noble for at tage højde for både tekst og tal:
Det ville være nyttigt at have en slags indikator for, hvilken kolonne der er ved at blive sorteret og i hvilken rækkefølge. Det kan vi gøre med tilføjelse af CSS-klasser, som så kan styles som man vil. I dette tilfælde er indikatorsymbolerne pseudo-elementer, der skifter, når der klikkes på måloverskriften.
En simpel søgning
Dette eksempel er en grundlæggende filtreringsfunktionalitet, der itererer gennem alt tekstindholdet i hver tabelcelle og anvender en CSS-klasse til at skjule alle rækker, der ikke matcher søgeindtastningsfeltet.
En sådan implementering er relativt naiv, og hvis dit brugsscenarie kræver det, kan det give mening at søge pr. kolonne i stedet. I det scenarie kan det være en god idé at have hvert inputfelt som en del af tabellen i deres respektive kolonner.
Lad et bibliotek håndtere det
De ovenstående JavaScript-snippets tjener til at demonstrere, hvordan tabeller med større datamængder kan forbedres for at gøre livet lettere for brugerne af disse tabeller. Men med virkelig store datasæt kan det nok være fornuftigt at bruge et eksisterende bibliotek til at håndtere dine store tabeller.
Spalteomskiftningsmønsteret er et mønster, hvor ikke-essentielle kolonner skjules på mindre skærme. Normalt er jeg ikke fan af at skjule indhold, blot fordi visningsvinduet er smalt, men denne tilgang af Maggie Costello Wachs fra Filament Group løser mit problem ved at give en drop-down-menu, der giver brugerne mulighed for at skifte de skjulte kolonner tilbage til visning.
Overstående artikel blev offentliggjort tilbage i 2011, men Filament Group har siden udviklet en komplet pakke af responsive table plugins kendt som Tablesaw, som indeholder funktioner som sortering, rækkevalg, internationalisering og så videre.
Kolonne-omskifterfunktionen i TableSaw er heller ikke længere afhængig af jQuery, i modsætning til eksemplerne fra den oprindelige artikel. Tablesaw er et af de eneste biblioteker, jeg kunne finde, der ikke har en afhængighed af jQuery i øjeblikket.
Wrapping Up
Der findes et utal af designmønstre for tabeller, og hvilken tilgang du vælger, afhænger i høj grad af den type data, du har, og målgruppen for disse data. Når alt kommer til alt, er tabeller en metode til organisering og præsentation af data. Det er vigtigt at finde ud af, hvilke oplysninger der betyder mest for dine brugere, og beslutte sig for en tilgang, der bedst opfylder deres behov.
Videre læsning
- “CSS-Only Responsive Tables”, David Bushell
- “Accessible, Simple, Responsive Tables”, Davide Rizzo, CSS-Tricks
- “Responsive Table Layout”, Matt Smith
- “Responsive Patterns”: Tables,” Brad Frost
- “Hey, It’s Still OK To Use Tables,” Adrian Roselli
- “Tables, CSS Display Properties, And ARIA,” Adrian Roselli
- “Data Tables,” Heydon Pickering