Tabellen: Wünsche und Realitäten

Über die Probleme mit der Erstellung von Inhalten trotz vermeintlich einfach zu bedienender Editoren a la “so wie Word” und die Gefühle des Webdesigners hatte ich ja schon einiges geschrieben. Ein weiteres Beispiel aus der Realität und mein Versuch, eine für alle zufriedenstellende Lösung zu finden. Als Hinweis vorab: jenes Szenario spielt sich nicht innerhalb eines Redaktionsworkflows ab, bei dem es zusätzlich noch ein Layout Team gibt.

Die Akteure

Wir “Webleute” sind uns alle einig: eigentlich sollte man den Editor im CMS so weit drosseln, dass er nur noch das Nötigste kann und ihn parallel dazu mit einigen sinnvollen Styles zu füttern. Eine Vorlage kann zusätzlich hilfreich sein.

Auf der anderen Seite ist da der Kunde, der Anwender. Der ist mitunter gar nicht so glücklich über den abgespeckten Editor und auch die gemeinsam besprochenen Vorlagen können eines Tages hinfällig sein: die Ausnahme wird also zum Normalfall und damit sind alle Vorlagen eigentlich für die Katz’.

Die Ausgangslage

Eigentlich waren da die von mir so schön vorgegebenen Tabellen Stylings, welche das TYPOlight Inhaltselement “Tabelle” bedienen sollen. Tabellen da, wo sie wirklich benötigt werden. Das Styling nicht viel: nur ein paar gesetzte Abstände und eine Rahmenlinie unten. Gut gemeint, gut gedacht, leicht bedienbar. Für eine spezielle Tabelle hatte ich dann zum Inhaltselement noch eine ID vergeben und darüber die Spaltenbreite einer speziellen Tabelle gesetzt.

Auch der Anwender fand, dass dies eine gute Idee sei. Nur leider… wollte er dann doch gerne die Spaltenbreite bestimmen können und gleichzeitig noch weitere Linien ziehen, wo es nötig ist. Das ist Kundenwunsch und der geht auf jeden Fall vor, Einzelheiten kann man dann immer noch diskutieren.

Gelungene Lösung in Sicht?

Tja, damit war mein sauberes Konzept, das auf die Nutzung der Inhaltselemente abzielte, komplett gekippt. Hier nämlich müsste ich für jedes individuelle Styling neue CSS Stile definieren oder dies gar dem Kunden zumuten. Das geht aus verschiedenen Gründen gar nicht -klar. Auch eine Vorlage wird ihren Zweck nur marginal erfüllen, denn damit können zwar sowohl Linien gezogen als auch Breitenänderungen vorgenommen werden. Nur sauber wird das nicht mehr sein.

Das Problem mit der Tabelle

Die Erfahrung, die Benutzer mit Tabellen aus Programmen wie Word mitbringen, sind nicht unbedingt eine gute Ausgangsposition, um HTML Tabellen richtig zu verstehen. Wer Dreamweaver nutzt, kennt die lustige Welt der Colspans, Rowspans und sonstiger Verschachtelungstechniken und schiebt sich einfach alles so lange zurecht, bis es passt. Das HTML dahinter spielt da nur eine untergeordnete Rolle. Happy Styling mit WYSIWYG. Weil das im Editor eines CMS alles nicht mehr ganz so komfortabel ist, wird sich da schnell mal einer Breakline beholfen. - und dies kann man einfach nicht verhindern.

Warum die Angabe der Breite durchaus sinnvoll ist, zeigt folgendes Beispiel (bewusst rudimentär gehaltener Tabellen), automatisch und ohne Breitenangaben, aber für eine als 100% deklarierte Tabelle. Einfach mal, um das Problem mit der Spaltenbreite nochmal präsent zu machen.

Spalten mit Inhalt gleicher Länge

Spalte 1 Spalte 2 Spalte 3

Mittlere Spalte breiter

kurz Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean lectus. Fusce non turpis. Integer nulla. Nam eleifend faucibus nisi. kurz

Drei Spalten unterschiedlicher Breite

auch etwas längere Spalte Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean lectus. Fusce non turpis. Integer nulla. Nam eleifend faucibus nisi. kurz

Spalten mit unterschiedlicher inhaltlicher Gewichtung

Spalte eins Spalte 2 Spalte 3
1 Nam eleifend faucibus nisi. Spalte 3
2 Lorem ipsum dolor sit amet. Spalte 3

Hier würde man sich wünschen, Tabellenspalte 1 noch etwas schmaler zu haben, um sie nicht überzubewerten, gleichzeitig aber Tabellenspalte 2 noch mehr Gewicht zu geben.

Ich habe bisher keine befriedigende Lösung für dieses Problem gefunden.

Ein hübscher Rahmen

Rahmen sind fast noch problematischer. Das Attribut border bezieht sich (ohne CSS wohlgemerkt) auf table und ist weder auf tr noch td anwendbar (siehe dazu beispielsweise die Element und Attributreferenz auf selfhtml). Das bedeutet: eine Tabelle ohne CSS hat entweder einen Rahmen oder sie hat keinen. Erst “ohne Rahmen” und mit CSS kann man Tabellenzellen (meist Zeilen) auch individuell mit Rahmenelementen ausstatten.

Und dann fängt schon das nächste Problem an.  Dieser Rahmen, definiert im Style, darf nicht auf eine Zeile angewandt werden (wie man es vielleicht als Standardvariante vermuten würde), sondern “zieht” nur dann, wenn er auf eine einzelne Tabellenzelle angewandt wird. Intuitiv ist das nicht.

Okay. Border-collapse? Mit border-collapse: collapse; lässt sich wenigstens noch der moderne Browser davon überzeugen, den Rahmen auch dann anzuzeigen, wenn er auf das tr Element bezogen wird. Zum modernen Browser zählt da allerdings auch der IE 7 nicht, denn er macht es nur “halb richtig”. Keine sehr überzeugende Lösung also. Übrigens gibt oder gab es hier offenbar einen Mozilla Bug. (zu diversen Quellenangaben: Google hilft weiter…)

Zum Tabellenmodell und Rahmen gäbe es noch einiges zu sagen. Fakt ist: die Browserunterstützung einzelner “Krücken” ist mau und daher für den “Hausgebrauch” weitestgehend unbrauchbar, - weil ohne Regelwerk unzumutbar für den “normalen User”. Für den Webdesigner mit Spaß an der Bastelei bietet das Ganze allerdings schier unbegrenzte Möglichkeiten (so sollte es auch sein, wenn es denn nicht so komplex und nochdazu nicht halbwegs browserübergreifend gültig wäre).

Semantik oder “der Wunsch nach Freiheit”

Natürlich kann man vorab definieren, welche Tabellentypen es gibt und unter der Prämisse des “wir behandeln alle gleich” Vorlagen definieren für Termine, für Preistabellen, für Adresslisten usw. Irgendwann wird der Anwender aber vielleicht kommen und nach einer neuen Vorlage verlangen. Und vielleicht wird er es dann auch selbst machen, ohne mich, ohne Vorlage - eben mit “ganz normalen Mitteln” nach bestem Wissen und Gewissen. Vielleicht auch Bilder einfügen? Dann wird sich die Tabelle sowieso in jeglicher Hinsicht verselbstständigen.

Die Semantik hinter dem Tabelleninhalt (Achtung: nicht der hinter dem Markup!) kann ich nur kennen und berücksichtigen. Sie ist aber von Fall zu Fall verschieden und erfordert zu Recht eine individuelle Darstellung, wenn gewünscht.

Tabellen also als die Wildwuchs-Falle des Webdesigns? Hier scheitert jedenfalls aus meiner Sicht der beste Anspruch des Webdesigners… und gerade an der Tabelle, diesem vermeintlich so einfachen Werkzeug, um alles mal schnell schön untereinander zu bekommen, zeigt sich eine nicht zu unterschätzende Stolperfalle für valides (X)HTML.

Klar, in einem großen Team mit einer Mannschaft, die sich nur ums Schreiben kümmert, während andere nur fürs Layout zuständig sind, mag das alles kein Problem sein…

 

Auch was dazu sagen?