Responsive Table und WordPress

Responsive hier und da - das Thema hat gewicht bekommen und endlich ist es populärer als in den Diskussionen von Entwicklern, die dem Thema nahe stehen. Responsive ist für mich mehr als das Nutzen einiger Mediaqueries auf bestimmte Werte und das Anpassen der Optik. Aber darum soll es hier nicht gehen, dazu gibt es ausreichend Beiträge auf anderen Sites und ein ausführliches Buch "Responsive Webdesign: Reaktionsfähige Websites gestalten und umsetzen" in deutscher Sprache von Christoph Zillgens.

Für mich war in letzter Zeit ein Thema in diesem Umfeld etwas aktueller, denn ich habe diverse WordPress Instanzen laufen, die zu Dokumentationszwecken von Entwicklungen dienen. Dabei erstellen die Kunden eine ganze Reihe von tabellarischen Daten und wenn diese in Meetings und Vorstellungen via Beamer dargestellt werden, dann ging die Auflösng rapide nach untern und die 1900 Pixel-Bildschirme stehen nicht mehr zur Verfügung. Daher lag es nahe, dass Tabellen mit einer Lösung ausgestattet werden, die trotzdem für eine sinnvolle Darstellung sorgt.

Nun ist das Thema der flexiblen Tabellen auch nicht mehr neu und man kann sich auf die Suche nach Lösungen begeben. Die Lösung kann beliebig komplex ausfallen und auf unterschiedliche Anforderungen zugeschnitten werden. Sei es mit einer reinen CSS Lösung oder dem Eingriff via JavaScript, beliebig komplex. Sinnvoll ist hier der Beitrag von Jens, da er die Hintergründe uns seine Überlegungen darlegt.

table

Für meine Umsetzung war eine schnelle Hilfreiche Lösung notwendig. Das Thema JavaScript ja/nein stand nicht zur Debatte, da es sich um die Nutzung innerhalb eines Unternehmes, im Intranet, handelt und JS aktiv ist. Trotzdem habe ich mich für eine eine Umstrukturierung der Tabelle entschieden und stelle die Tabelle von links nach rechts, beginnend mit den Kopfdaten dar.

table-small

table-smallest

Der Grund war in erster Linie, dass die Leute einfache Tabellen in die Artikel werfen. Für eine weitere Lösung - Scrollende Tabellen mit fester 1. Spalte, die mir gefällt, müssen sie die Tabelle mit einer Klasse ergänzen. Beide Lösungen sind implementiert und aktuell prüfe ich noch, wie die Anwender mit welcher Lösung zurecht kommen. Aber die Umstrukturierung kommt gut an. Man darf nicht vergessen, die Anwender sehen die Tabelle, je nach Auflösung und verändern nicht live die Größe, so dass sie Veränderung der Spalten nicht mitbekommen. Trotzdem ist die Lösung via JS und CSS sinnvoll und ggf. zu verwenden. Da diese aber eine Klasse ander Tabelle benötigt und dies nicht einfach dynamisch zu ergänzen ist, halte ich die reine CSS-Lösung für sinnvoll und schlank.
Den folgenden Code lege ich in der functions.php des Themes ab und nutzte die Funktion für die Inkludierung aller Stylesheets und Scripte.


if ( ! function_exists( 'documentation_scripts_styles' ) ) {

	add_action( 'wp_enqueue_scripts', 'documentation_scripts_styles' );
	/**
	 * Enqueue scripts and styles for front-end.
	 *
	 * @since 2.0
	 */
	function documentation_scripts_styles() {

		// set suffix for debug mode
		$suffix = defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG ? '.dev' : '';

		// Register responsive table script
		// Kudos to Responsive Tables project
		// @see  http://www.zurb.com/playground/responsive-tables
		wp_register_script(
			'documentation-responsive-tables',
			get_template_directory_uri() . '/js/responsive-tables' . $suffix . '.js',
			array( 'jquery' ),
			'01/14/2013',
			TRUE
		);

		// Register responsive table style
		wp_register_style(
			'documentation-responsive-tables',
			get_template_directory_uri() . '/css/responsive-tables' . $suffix . '.css',
			array(),
			'01/14/2013',
			'screen'
		);

		wp_enqueue_script( 'documentation-responsive-tables' );
		wp_enqueue_style( 'documentation-responsive-tables' );
	}

} // end if func exists

Der Code dient vor allem zum Aufzeigen der Implementierung. Keine Veränderung des head oder desr Footer-Bereiches. Das Registrieren und Inkludieren via Funktionen von WordPress. Damit wird es nicht nur einfacher für andere darauf einzuwirken, abschalten oder zu nutzen, sondern auch die Paketierung im Live-Modus in eine Datei ist einfacher.

Das Thema ist nicht einfach, kann beliebig umfangreich werden und Fallbacks für NonJS Aufrufe können ebenso aufwendig werden. Daher sehe ich die Anforderung des Kunden hier als wichtigstes Kriterium und nicht das reine aktivieren einer fertigen Lösung. Trotzdem hier der Verweis auf zwei Lösungen, die mir aufgefallen sind.

Alternativ freue ich mich ebenso, wenn mein Theme Documentation mit dieser vorgestellten Lösung ggf. erweitert wird oder neue Ideen hinzukommen.

Kommentare sind geschlossen.