Bitte fixiert Tabellenüberschriften

 (btxx.org)
4 Punkte von GN⁺ 2024-02-25 | 1 Kommentare | Auf WhatsApp teilen
  • Bei Tabellen mit vielen Zeilen vergisst man beim Scrollen leicht die Bedeutung der Spalten, was das Lesen der Daten erschwert
  • Wenn man zu thead nur position: sticky; und top: 0; hinzufügt, lässt sich ein fixierter Header umsetzen
  • sticky wird weltweit von rund 96 % der Browser unterstützt und ist damit kaum noch als experimentelle Funktion zu betrachten
  • Auch wenn man weiter unten liegende Zeilen wie den 300. Eintrag betrachtet, bleiben die Spaltenüberschriften sichtbar, was die Navigation in der Tabelle verbessert
  • Die Umsetzung ist klein, aber der Effekt groß; für Webseiten mit langen Tabellen ist das eine sinnvolle grundlegende Verbesserung der Usability

Das Problem verschwindender Header in langen Tabellen

  • Bei großen Datensätzen oder Tabellen mit Hunderten von Zeilen verschwindet der Tabellenkopf nach dem Scrollen aus dem sichtbaren Bereich
  • Wenn man bis zum 300. Eintrag heruntergeht, kann es schwierig werden, erneut nachzuvollziehen, wofür die Daten in den einzelnen Spalten stehen
  • Je unbekannter die Tabelle ist, desto stärker muss man sich beim Lesen die Bedeutung der Spalten merken, was die Navigation mühsamer macht

sticky auf thead anwenden

  • Die Lösung besteht darin, thead zwei CSS-Eigenschaften hinzuzufügen
position: sticky;
top: 0;
  • Wenn position: sticky und top: 0 zusammen verwendet werden, lässt sich der Header auch während des Scrollens am oberen Bildschirmrand fixieren
  • sticky hat eine weltweite Unterstützung von etwa 96 % und kann daher in vielen Browsern verwendet werden
  • Die tatsächliche Funktionsweise lässt sich im CodePen-Beispiel ansehen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-02-25
Hacker-News-Kommentare

  • Einen fixierten Header auf einer Achse akzeptiere ich ja noch, aber ich warte immer noch auf den Tag, an dem CSS beide Achsen unterstützt: https://github.com/w3c/csswg-drafts/issues/8286

    • Ein Auftragsprojekt, bei dem sowohl Spalten als auch Header fixiert werden mussten, war eines der schwierigsten Dinge, die ich je machen musste Mit einer Standardtabelle wäre es einfach gewesen, aber hier war es eine komplexe dynamische VueJS-Drittanbietertabelle mit generiertem CSS-as-JS, und allein herauszufinden, wo CSS und JS überhaupt herkamen, hat ewig gedauert; am Ende musste ich JS-Klassenfunktionen und generiertes CSS überschreiben Es tat mir leid, dass es für den Kunden so lange gedauert hat, und seitdem wähle ich Bibliotheken in Vue-/React-Codebasen viel vorsichtiger aus. Tabellen sind doch ein grundlegendes HTML-Element — warum braucht man für eine einfache Aufgabe drei Schichten JS-Klassen und sogar per JSON importiertes CSS?
    • Ich beobachte vermutlich seit acht Jahren schon das ursprüngliche Issue, aus dem dieses hervorgegangen ist, und es ist einer der frustrierendsten Teile der CSS-Spezifikation Manchmal braucht man eben riesige Datentabellen und möchte oben fixieren und gleichzeitig overflow-x: auto verwenden, aber stattdessen soll man sich für eines von beidem entscheiden

  • Ehrlich gesagt habe ich kaum CSS-Kenntnisse und baue trotzdem Web-Apps, die mehr oder weniger funktionieren. Neulich wollte ich bei einer Monster-Tabelle mit etwa 20.000 Zeilen den Header fixieren: https://www.datasciencemeta.com/rpackages Ich hatte zuerst erwartet, dass es bei den Bootstrap-Tabellenklassen so etwas wie class="table table-header-sticky" gibt, aber das gab es nicht, und nach 20 Minuten mit Stack Overflow, GPT und CodePen-Vorschlägen hatte ich nur seltsame Nebenwirkungen Mit dem CodePen aus diesem Artikel lief es dagegen in zwei Minuten, und ich rolle es gerade in Produktion aus

  • Einen Tabellenkopf zu fixieren wirkt mit position: sticky; einfach, aber sobald man anfängt, der Tabelle weitere Funktionen zu geben, wird es sofort kompliziert Ich hatte einmal in einer Tabelle mit fixiertem Header eine Funktion eingebaut, die den Index der ersten sichtbaren Zeile speichert, wenn ein Nutzer durch den Inhalt scrollt und dann die Seite verlässt, und ihn bei der Rückkehr wiederherstellt. Dabei wurde immer etwa eine Zeile zu weit unten wiederhergestellt. Es stellte sich heraus, dass Zeile 5 tatsächlich ganz oben in der Tabelle war, aber durch das darüberliegende thead sah Zeile 6 wie die erste Zeile aus Also habe ich die Scroll-Position unter Berücksichtigung der thead-Höhe angepasst, aber gelegentlich war es immer noch um ein paar Pixel verschoben, und weil es eine große Tabelle war, mit Lazy Loading im Scroll-Event und dem Standard-Autolayout der Tabelle, wurden Header-Zellen umbrochen, wodurch sich die gesamte Header-Höhe änderte. Am Ende habe ich an thead einen ResizeObserver gehängt und die Scroll-Position dynamisch angepasst, wenn sich die Höhe änderte [1] https://developer.mozilla.org/en-US/docs/Web/API/ResizeObser...

  • Wenn du das umsetzt und möchtest, dass auch die Rahmenlinie des Headers fixiert bleibt, kannst du es über table thead:before und table thead:after lösen, indem du position: absolute, width: 100%, top: 0/bottom: 0 sowie border-top/border-bottom setzt

  • Eigentlich sollten Tabellenköpfe von Haus aus so funktionieren. Wenn ein Entwickler überhaupt die entsprechenden Tags benutzt und zusätzlichen Aufwand betreibt, ist die Wahrscheinlichkeit hoch, dass genau dieses Verhalten gewünscht ist

    • Installiere einfach ein Browser-Plugin, mit dem sich auf allen Seiten ein benutzerdefiniertes Stylesheet laden lässt Allerdings bauen immer mehr Seiten ihre Tabellen heute mit 500 statt und mit 45-fach verschachtelten in jedem auf, daher würde das dort vermutlich nicht funktionieren
    • Solche Änderungen würden vermutlich auf unerwartete Weise irgendetwas kaputtmachen Der Hauptgrund ist wohl, dass vor dem Aufkommen von CSS Grid viele Websites Tabellen für Rasterlayouts verwendet haben. Wenn Header fixiert würden, könnten solche Layouts kaputtgehen Ein großes Versagen der HTML-Semantik ist, dass Tabellen nicht als „Methode zur Darstellung tabellarischer Daten“, sondern als „beliebiges Raster von Elementen“ verstanden wurden

  • In der Kommandozeile schickt man den Header nach stderr und den Inhalt nach stdout Andernfalls ergibt heights | sort -k2 -nr die Reihenfolge George 186, Wally 173, NAME HEIGHT, aber wenn der Header stdout umgeht, wird daraus NAME HEIGHT, George 186, Wally 173

    • heights | (sed -u 1q; sort -k2 -nr) funktioniert korrekt Quelle: https://stackoverflow.com/a/56151840
    • Wenn man in eine Datei schreibt, muss man noch ein paar zusätzliche Verrenkungen machen und braucht auch mehr Shell-Verständnis Das ist eine fortbestehende Einschränkung eines reinen In-Band-Textmodells, aber wenn man STDERR auf diese Weise missbraucht, dürfte das eher verwirren als helfen Wenn heights eine Datei ist, kann man etwa % head -1 heights ; sed 1,1d heights | sort -k2 -nr verwenden, und wenn heights ein ausführbares Programm ist, das teuer ist, zweimal zu starten, dann etwa % heights > /tmp/heights ; head -1 /tmp/heights ; sed 1,1d /tmp/heights | sort -k2 -nr. Man kann auch per awk weiterpipen Andere Optionen sind weniger bequem, aber dafür weniger überraschend und funktionieren auch dann, wenn der Autor des Programms etwas anderes im Sinn hatte
    • Was wäre hier besser? Den Header nach stderr zu schicken oder ihn nur dann auf stdout auszugeben, wenn stdout ein TTY ist?

  • Das hat lange Zeit nicht funktioniert. Chrome hatte früher position: sticky auf thead- und tr-Elementen deaktiviert: https://issues.chromium.org/issues/41303743 Ich erinnere mich, dass die Browser-Support-Tabelle fast überall grün aussah, es in Chromes Tabellen aber ausgerechnet nicht ging

    • Dass es jetzt so einfach ist, überrascht mich. Als ich das früher gebraucht hätte, musste man HTML und CSS mit allem möglichen Ballast vollstopfen, damit es in allen Browsern funktioniert Überraschend war es aber auch wieder nicht, denn Webentwicklung läuft meist genau so

  • Es gibt auch die Fraktion, die lieber sagen würde: „Bitte bloß nicht“: https://news.ycombinator.com/item?id=32998091

    • Bei normalen Webseiten stimme ich vollkommen zu. Ich entferne mit uBlock Origin oft fixierte Elemente, weil das schneller geht als eigene Stylus-Styles zu schreiben, und generische, seitenweit angewandte Styles haben oft ziemlich gut funktioniert Hier geht es im Original aber um Datentabellen mit fixierten Header-Zeilen, und dafür ist dieser Vorschlag tatsächlich ziemlich nützlich
    • Dabei geht es um fixierte Header auf der ganzen Webseite. Bei Tabellen ist das etwas völlig anderes Wenn man eine Tabelle mit ungefähr einem Dutzend Zahlenspalten ansieht und ein kleines Stück nach unten scrollt, sodass man sofort nicht mehr weiß, was was ist, ist das wirklich unerquicklich
    • Was genau ist am Attribut sticky schlecht?

  • Im CodePen sieht es besser aus, wenn man top um die Rahmenbreite versetzt. Zum Beispiel -1px statt 0, damit der Tabellenkörper nicht oberhalb des Headers durchscheint Vergleich: https://codepen.io/bradleytaunt/pen/bGZyJBj Anpassung: https://codepen.io/alokmenghrajani/pen/ExMBQow

  • Statt eines fixierten Headers wird ein begrenzter Viewport in der Höhe vorgeschlagen, sodass der Header immer sichtbar bleibt So wie bei DataGridXL(https://datagridxl.com). Zur Transparenz: Das habe ich gebaut

    • Nur so ein Gedanke, aber ohne Zeigegerät, also zum Beispiel nur mit Tastatur, dürfte sich das sehr schwer navigieren lassen
    • Nicht als Kritik gemeint, aber auf Mobilgeräten mochte ich diesen Ansatz noch nie. Ich finde, Inhalte sollten zusammen mit der Seite scrollen