Responsive Retrofitting Teil 1
Wenn wir mit bestehenden Inhalten planen müssen, kommt es oft vor, dass wir Daten-Tabellen responsive darstellen sollen. Diese Tabellen sind naturgemäß meist sehr schwierig auf kleinen Bildschirmen abzubilden, viele Tabellen sind sehr groß und enthalten viele Daten. Das rührt daher, dass Redakteure (bzw. diejenigen, die für den Inhalt verantwortlich sind) versuchen über Excel-Tabellen komplexe Daten abzubilden und die Daten so ins Web übernommen werden (sollen). In der Vergangenheit war der Platz auf großen Bildschirmen vorhanden, im Multi-Screen-Zeitalter und in einer responsiven Website heutzutage, meist nicht mehr.
Meine erste Regel wenn Tabellen „responsive“ abgebildet werden sollen, prüfen ob man den Inhalt nicht auch anders ausgezeichnet werden kann, bzw. flexiblere HTML-Elemente für die Abbildung verwendet werden können. So haben wir in einem Projekt eine Suchergebniss-Ausgabe von einer Tabellenansicht in eine Listenansicht (UL) umgewandelt.
Ein schlechtes Beispiel, wie ich finde, ist die Verwendung von DIV-Containern wie im Artikel „Responsive and SEO friendly data tables“ beschrieben. Tabellendaten haben (wenn richtig verwendet) auch eine semantische Zuordnung untereinander. Über Tabellenkopf (thead
, th
) und Tabellenzellen (tbody
, td
), optimalerweise auch über scope-Attribute können die Zusammenhänge im Markup ausgezeichnet werden. Das kann man nicht mit unsematischen DIV-Container nachbilden (es sein denn man nutzt zusätzlich WAI-Aria Attribute, aber lassen wir mal die Kirche im Dorf).
Besser geeignet für diesen Zweck sind semantische Elemente wie eine Description List (DL). Ein <dl>
-Element ist dann im übertragenem Sinne ein <tr>
, ein <dt>
ist ein <th>
und ein <dd>
das Äquivalent zu <td>
. Somit haben die Inhalte auch eine semantische Bedeutung zueinander. Das ist zwar auch von hinten durch die Brust ins Auge, aber besser als DIVs.
Ein Beispiel:
<div class="tabled-view">
<dl>
<dt>Beschreibung:</dt>
<dd>Lorem ipsum is evil!</dd>
</dl>
</div>
Altlasten
Für den Fall, dass man das Markup nicht verändern kann, muss man sich anderer Tricks behelfen. Eine Möglichkeit wäre das „Responsive Tables“ jQuery-Plugin von Zurb (die Macher von Foundation). Das Plugin klont die Tabelle, überlagert beide Tabellen und blendet einerseits die Tabellenzellen, andererseits die Tabellenköpfe aus. Zudem macht das Script den Zellenbereich horizontal scrollbar. Der ein oder andere kennt das vielleicht von Excel, dort kann man ebenfalls einen Bereich festsetzen und den Rest der Zeilen scrollen.
CSS und JavaScript in den HEAD einfügen:
<link rel="stylesheet" href="responsive-tables.css" />
<script src="responsive-tables.js"></script>
Die Klasse „responsive” zur Tabelle hinzufügen, fertig.
<table class="responsive">
<tr> … </tr>
</table>
Nachteil: es ist nur ein fester Breakpoint im JavaScript gesetzt. Das könnte im Fall der Tabelle auch ausreichen, aber man weiß ja nie… Ich habe zudem noch -webkit-overflow-scrolling: touch
hinzugefügt für ein flüssigeres Momentum-Scrollen in WebKit-Browsern.
div.table-wrapper div.scrollable {
overflow: scroll;
overflow-y: hidden;
-webkit-overflow-scrolling: touch;
}
Weitere Plugins:
CSS-only Lösung
Eine weitere Möglichkeit, die ich bereits in Projekten verwendet habe, beschreibt Chris Coyier im Artikel „Responsive Data Tables“. Hierbei werden alle Tabellen-Zellen in Blockelemente umgewandelt und mit Pseudo-Elementen versehen, die wiederum die Zeilenbeschreibungen als content
Wert mitbringen. Das funktioniert sehr gut, ist aber nicht so flexibel, da fest in CSS geschrieben.
/* Label the data */
th:nth-of-type(1):before { content: "Name:"; }
th:nth-of-type(2):before { content: "Vorname:"; }
th:nth-of-type(3):before { content: "Straße:"; }
th:nth-of-type(4):before { content: "PLZ:"; }
th:nth-of-type(5):before { content: "Ort:"; }
Chris beschreibt weiter in seinem Blogpost, wie man die Variante mit HTML5 data-Attributen flexibel bekommt (Idee von @chriseppstein).
<th data-label="Name">Name</th>
th:before { content: attr(data-label); }
Beispiel: http://codepen.io/maddesigns/full/pHqnt
Browser-Support für diese Lösung
Der IE9, sowie alle älteren IEs mögen es nicht, wenn man Tabellen auf ‚display: block‘ setzt, es kann – muss nicht – zu Darstellungsfehlern kommen. Das sollte man bedenken.
Wichtig ist, dass man sich den Inhalt vorher genau anschaut und dann entscheidet, welche Responsive Tabellen Lösung die Beste ist, es kommt auf den Inhalt an.
There I said it: Content First!
Sehr interessant!
Sehr gut geschrieben und sehr interessant.
Für manche Dinge braucht man einfach eine Tabelle. Eine einfache Lösung für TYPO3 ist es, einen wrap um die Tabellen zu basteln, der einen overflow:auto bekommt. Geht natürlich auch mit anderen Systemen.
Wenn es geht vermeide ich Tabellen, ich mag die schon nicht in InDesign und im Web auch nicht.
Aber wenn es mal dazu kommt ist hier die Methode eine sehr interessante. Danke für den Artikel.
Schöne Grüße
Stefan
Ich hatte mir dazu mal vor längerem Gedanken gemacht und benutze seit dem erfolgreich folgende Lösung: http://www.freizeitler.de/2014/08/19/usability-und-content-strategien-eine-tabelle-im-responsive-web-design/
Der Blogpost entstand nach einer „Testphase“ von einem Jahr…
@Henry Schönes Beispiel, hatte ich letztens auch gesehen. Kommt bestimmt auch mal zum Einsatz.