11. November 2008
Der IE8 ist noch nicht einmal veröffentlicht, scheint aber dennoch für einen nicht gerade kleinen Kreis an Webentwicklern bereits zum Heilsbringer zu avancieren. Auslöser der Euphorie ist, dass der IE8 verspricht (ob er es hält werden wir sehen), den CSS 2-Standard nun vollständig und fehlerfrei zu unterstützen, was bedeutet, dass CSS-Tabellen (display:table, display:table-cell, display: table-row) salonfähig werden.
Und hast Du nicht gesehen, schon überschlägt man sich hier, da und dort mit Artikeln, die vom Beginn einer neuen Webdesign-Ära sprechen, in der die ach so komplizierten Layoutkrücken, welche noch auf Floats oder absoluter Positionierung basieren, nur noch ein Schattendasein fristen werden.
Licht und Schatten
Rein gefühlsmäßig entspringt der Hype maßgeblich der Tatsache, dass es mit CSS-Tabellen endlich relativ problemlos möglich sein sollte, CSS Layouts mit gleichlangen Spalten zu erzeugen. Vor zwei, drei Jahren - wo es fast ausschließlich einfache CSS-Spaltenlayouts gab, fand ich diese Idee auch toll. Doch seither hat sich im Webdesign doch einiges getan. Alle Welt baut Grids, Techniken für gleichlange Spalten gibt es zu Hauf, sowohl als Fake-Lösungen (faux columns) als auch ganz real per CSS (siehe hier und da). Sicher, sie haben ihre Nachteile — aber im Grunde erfüllen sie ihren Zweck, wenn man die Funktionalität benötigt. CSS-Tabellen können hier Webdesignern in Zukunft das Leben wirklich noch etwas einfacher machen, den Status eines Erlösers bekommen sie deswegen jedoch sicher nicht. Denn das Gute an all den bisher verwendeten Workarounds ist, dass sie weitestgehend auch mit älteren Browsergenerationen funktionieren. Bei CSS-Tabellen sieht das anders aus. Zwar hinkt auch hier in erster Linie der Internet Explorer hinterher, jedoch sind auch Firefox, Safari & Opera bis heute nicht 100%-ig einer Meinung, was die Detail der Darstellung eines Containers mit der Eigenschaft display:table betrifft.
Ein weiterer, schwerwiegender Nachteil ist, dass es bei Tabellen (und ebenso bei CSS-Tabellen) keine Möglichkeit gibt, die Reihenfolge in der Spalten in der Bildschirmausgabe per CSS zu beeinflussen. Die Codereihenfolge wird streng und unverändert in die Präsentation übernommen. Bei Tabellendaten ist das auch nicht notwendig, bei der Layoutgestaltung führt es jedoch zu massiven Einschränkungen gegenüber den aktuellen Float-Lösungen. Dabei will ich garnicht von den SEO-Fanatikern sprechen, sondern vielmehr den Blick auf Screenreader und Textbrowser lenken. Mit CSS-Tabellen verlieren wir die Möglichkeit, die einzelnen Layoutelemente im Code und in der Präsentation unabhängig zu platzieren. Ich halte diesen Punkt für weitaus wichtiger als die native Unterstützung gleichlanger Spalten, weshalb für mich Floats weiterhin das Maß der Dinge bleiben.
Und nicht zuletzt sind da die beiden Veteranen, Internet Explorer 6 & 7, die vermutlich auch in den nächsten Jahren noch maßgebliche Marktanteile verbuchen werden. Wie bringt man diesen Browsergeneration die CSS-Tabellen nahe? Da fangen wir dann also doch wieder an zu basteln und zu hacken. Denn um auch Nutzer dieser Browser wenigstens in den Genuss der Mehrspaltigkeit kommen zu lassen, müssten die Tabellenspalten speziell für die alten IE’s wieder in floatende Container zurückverwandelt werden.
Gefühlte 5 Jahre zu spät
Ich mag mich natürlich irren, aber ich denke, CSS-Tabellen kommen einfach zu spät. Die Technik hat unbestritten ihren Reiz, doch ist es nunmal so, dass CSS2 schon ein paar Jahre existiert und die Welt während dieser Zeit nicht regungslos auf die Ankunft der CSS-Tabellen gewartet hat. Es gibt eine Vielzahl ausgereifter Layouttechniken, die sich relativ problemlos selbst im veralteten IE5.x fehlerfrei anwenden lassen. Und genau da können CSS-Tabellen nicht punkten, denn nur die kommende IE-Generation wird damit umgehen können.
CSS-Tabellen werden ihren Platz im Webdesign-Alltag finden, da bin ich mir sicher. In einfachen Grid-Frameworks wie 960.gs könnten sie die bisher verwendeten Floats durchaus ablösen. Bei Verwendung dieses Frameworks stimmen Code- und Präsentationsreihenfolge auch jetzt schon zwingend überein, weshalb in diesem Fall technischen Einschränkungen der CSS-Tabellen nicht spürbar werden, die gleichhohen Spalten aber sogar einen echten Mehrwert bieten. Schon bei Blueprint CSS sieht es u.U. anders aus, denn Blueprint stellt Klassen zum Verschieben von Elementen innerhalb des Grids zur Verfügung (mittels positiver/negativer Margins), was in Verbindung mit Floats wunderbar funktioniert, mit CSS-Tabellen aber vermutlich schwierig werden würde.
Eine Revolution oder auch einen signifikanten Entwicklungsschub in Sachen CSS-Layouts sind CSS-Tabellen in meinen Augen daher nicht. Sie bringen zu große Probleme mit (Spaltenreihenfolge in Code und Präsentation), die mit den herkömmlichen Bordmitteln (Floats) seit Jahren getrost als gelöst bezeichnet werden dürfen, zudem ist die Browserunterstützung nur in der aktuellsten Generation gewährleistet. Sie sind aber eine willkommene Alternative in dem einen oder anderen konkreten Anwendungsfall.
Dienstag, 11.11.08 (11:49 Uhr)
Ich freue mich auf CSS-Tabellen wie ein Webentwickler, der seine Seite mal wieder für den IE6 optimieren muss. Für mich spielt diese Technik keine Rolle. Einzig bei sevenload hatte ich das mal eingesetzt, um die Medieninhalte (Videos und Fotos) vertikal zu positionieren. Wenn ich schon davon rede, Tabellen für ein Layout einzusetzen, sträuben sich bei mir die Haare - auch wenn es mit CSS statt HTML gelöst ist.
Dienstag, 11.11.08 (11:52 Uhr)
Es freut mich zu lesen, dass Du da ähnlich denkst wie ich! Ich habe das in meiner Buchrezension zu den “Fortgeschrittenen CSS-Techniken” auch bereits angemerkt: Es fühlt sich seltsam an und ist schon wieder mit jeder Menge neuer DIV-Verschachtelungen verbunden. (Ja, ich weiß, dass _dieser_ Punkt Dir nicht so viel ausmacht ;-)
Dienstag, 11.11.08 (12:42 Uhr)
Ich wollte mich zuerst gleich mal gar nicht damit befassen. Und das Buch “Everything you know about CSS is wrong” hat mich vom Titel her ziemlich abgeschreckt. Aber: was ich bis dato dort nachgelesen habe, kann im Einzelfall und -einsatz durchaus von Vorteil sein. Klar bringt das auch wieder Nachteile mit sich. Aber ich werde das mal alles durchtesten. :)
Ich würde vermuten, dass das CSS-Tabellen-Konzept am besten für den Rahmen greift, aber im kleinteiligen schlicht durch
FLOATwieder verdrängt werden wird, da ist es dann zu wenig flexibel.
Dienstag, 11.11.08 (13:21 Uhr)
Du hast die Vor- und Nachteile, die mir noch etwas ungeordnet im Kopf rumschwirrten, sehr schön zusammengefasst.
Ich denke, dass sich die “CSS Tabellen” durchaus einen Bereich erobern könnten, denn für Einsteiger sind sie wahrscheinlich intuitiver als Floats und nicht jeder braucht für seine kleine Homepage die Kompatibilität zu älteren IEs.
Die Erwartung gleichlanger Spalten sitzt einfach drin, und Techniken wie “Faux Columns” oder “Companion Columns” sind vergleichsweise schwierig zu lernen.
@macx
Ein Layout basiert fast immer auf einem Raster (“Grid”), und da ein Raster aus Spalten und Zeilen besteht ähnelt es optisch verdammich dem Aufbau einer Tabelle. Ich denke nicht, dass Tabellen an sich verpönenswert sind und das zwischen HTML und CSS Tabellen durchaus ein Unterschied besteht. Wäre doch mal ein Thema für die Technikwürze ;-)
@sprungmarker
Ich finde den Titel “Everything you know about CSS is wrong” ziemlich genial, jedenfalls um Klassen besser als “CSS Tabellen im Detail” oder sowas ;-)
Dienstag, 11.11.08 (13:23 Uhr)
@Gerrit
zusätzliche Container brauchen die CSS-Tabellen eigentlich nicht. Und das Problem beim Mischen von Einheiten liegt im Boxmodell begründet, daran ändern auch die CSS-Tabellen nichts.
@Sprungmarker
Sehe ich genauso - im Einzelfall durchaus berechtigt. Die Probleme fangen an, wenn man dem IE6 & 7 eine äquivalente Optik verpassen muss. Dann sind die Workarounds umfangreicher als das eigentliche Layout.
Dienstag, 11.11.08 (14:28 Uhr)
Wir sollten uns nicht vor den neuen Techniken verschießen und sie zumindest ausprobieren, wenn sich ein Anwendungsfall ergibt (und gleichlange Spalten sind definitiv einer), dann können wir sie benutzen, sobald es genügend Browser beherrschen oder die Darstellung auch Linearisiert sinn macht (Beispiel: Drei teaser, die sowohl vertikal als auch horizontal sinnvoll sind).
Was ich nicht verstehe ist dieses Gemeckere (sorry) von wegen HTML-Tabellen. CSS soll uns auf lange Sicht alle Darstellungsformen zugänglich machen. Schon jetzt können wir Tabellen (in guten Browsern) auch anders darstellen lassen indem wir ihnen die Tabelleneigenschaften berauben. Da ist es doch nur nachvollziehbar, dass wir die Eigenschaften von Tabellen (aber nicht deren Semantik) auch als Werkzeuge in die Hand bekommen um sie zu benutzen. Ich halte das nicht für problematisch.
Dienstag, 11.11.08 (14:42 Uhr)
@Eric
Wenn Du das aus meinem Beitrag liest, hast Du mich etwas missverstanden. Ich sehe die gleichen Anwendungsmöglichkeiten wie Du. Allerdings sind das für mich Einzelfälle, über die Projekt für Projekt entschieden wird. Ich spiele für YAML schon eine Weile mit den table-Eigenschaften herum.
Ich halte es jedoch für Augenwischerei, mit marktschreierischen Titeln wie “Everything you know about CSS is wrong” eine Technik zu anzupreisen und die bisherigen Lösungen (Floats, Positionierung) als Krücken darzustellen, und einmal mehr zu verschwiegen, dass die Lösung in der Realität dann eben doch anders aussieht und nicht so einfach gestrickt ist und zudem einige Einschränkungen bereit hält.
Sicher, die gleichlangen Spalten sind ein Pluspunkt. Dafür werde ich die CSS-Tabellen auch einsetzen, wenn ich sie benötige. Allerdings braucht man das eben nicht täglich und auch nicht bei jedem Layoutentwurf. Allerdings werden Webentwickler fast täglich Layouts erstellen müssen, die nicht nur im IE8 gut aussehen. Und in diesem Fall ist Linearisierung meist keine akzeptable Alternative. Und deshalb stört mich dieser Hype, denn die CSS-Tabellen reihen sich für mich max. gleichwertig neben Floats und Positionierungen in die Reihe der verwendbaren CSS-Techniken ein, wobei ich für die crossbrowsertaugliche Layouterstellung weiterhin Floats favorisiere.
Dienstag, 11.11.08 (15:37 Uhr)
Für dynamische Inhalte ist es von Vorteil, wenn Boxen die gleiche Höhe beibehalten und kann für ein Design von großer Bedeutung sein. Aber so schön es ist, gleich lange columns zu haben, wird man trotz CSS-Tables für Page Layout und inline Elemente ohne Floats und Positionierung nicht rumkommen um alle Browser zufrieden zu stellen. Und da ich in der Regel ohnehin ein extra Stylesheet für IE’s erstelle, wird sich vom Aufwand her nichts ändern. Ein für mich wichtiger Vorteil von CSS-Tables ist deren Flexibilität bei der Reihenfolge des Quelltexts, im Gegensatz zu normalen Tabellen.
Dienstag, 11.11.08 (16:54 Uhr)
@Dirk:
Nain, ich habs nur mal so in die Runde geblökt :) Dein Beitrag schlägt ja genau den gleichen Ton an, CSS Tables werden das Webdesign nicht revolutionieren.
Mein Kommentar richtete sich eher an Macx und Gerrit, man sollte das nicht beim ersten anzeichen verteufeln sondern schauen was geht.
Dienstag, 11.11.08 (21:16 Uhr)
Ich verteufele das nicht beim ersten Anblick - sondern habe natürlich selbst schon mit
display: table-cellgearbeitet. Damit alle Browser in den Genuss der Tabellen kommen, ist es jedoch wohl notwendig, dass es div-Äquivalente gibt sowohl für td, als auch für tr und auch für table. Also bin ich mal wieder bei einer wunderbaren dreifachen Verschachtelung, die im Quelltext scheiße aussieht und es wieder schwerer macht, den Code von Hand zu schreiben.
Mir ist das ein bisschen zuviel Veränderung im HTML-Code für ein bisschen wenig Leistung, die ich mit den Tabellen bekomme. Floats decken (fast) alles ab, was ich will. Und ein float-gerechter HTML-Code fühlt sich viel näher am Inhalt an.
Dienstag, 11.11.08 (23:38 Uhr)
Ich gewöhne mir besser keine weiteren schlechten Angewohnheiten an. CSS-Tabellen sind für Sprachen wie XML gedacht, welche kein vordefiniertes table-Element haben? Momentan verwende ich lieber JavaScript, um kleinere CSS-Layoutprobleme zu lösen.
Eher wird CSS3 mit Multi-Column-Layout, Template-Layout und Grid-Positioning-Module interessant, als das CSS-Tabellen jemals von allen relevanten Browsern, und damit meine ich auch die auf mobilen Geräten (WM 6.1 ???), fehlerfrei unterstützt wird.
Mittwoch, 12.11.08 (08:12 Uhr)
@Johann: Do websites need to look exactly the same in every browser?
Mittwoch, 12.11.08 (22:16 Uhr)
Bei der Suche nach einem IE6/IE7-Workaround für die CSS-Tabellen sind Inline-Blocks eine Alternative zu Floats. Inline-Blocks stehen von Prinzip her den Table-Cells nahe. Ein CSS-Tabellenlayout lässt sich hiermit in einigen Fällen nachbauen, wie wir zeigen.
Hacks. Klar. Würde man jeden IE-Workaround ablehnen, könnte man sich bei Lichte betrachtet in diesem Metier nicht mehr bewegen. Und Safari und Firefox verlangen gegenwärtig noch nach strukturellen Anpassungen mit zusätzlichen Divs.
Also ja. Eine weitere Technik unter vielen, aber kein Königsweg. Den gibt es nicht in CSS, sofern man mit CSS das meint, was die Browser da draußen können.
Mittwoch, 12.11.08 (23:56 Uhr)
Danke, Dirk, endlich gibt es hierzulande eine Diskussion zu diesem Thema.
Der Artikel von Kevin Yank mit der aufreißerisch-provokanten Überschrift „Table-Based-Layout Is The Next Big Thing“ , der im Sitepoint-Blog am 28.02.2008 erschien, hatte mich zunächst etwas aufgeschreckt.
Heute sehe ich das Ganze weitaus gelassener.
Man muss nicht gleich auf jeden fahrenden Zug aufspringen, aber wer Webseiten erstellt, sollte sich schon gründlich mit der neuen Layouttechnik beschäftigen und anfangen, damit zu experimentieren.
Andy Clark hat bereits experimentiert und zwei Demos zum Vergleichen erstellt
http://forabeautifulweb.com/blog/about/are_css_tables_ready_for_prime_time/
Dirk, auch Du hast Dich schon damit beschäftigt und die Vorteile und Nachteile ausgelotet. In Antwort #7 heißt es:
Ich spiele für YAML schon eine Weile mit dentable-Eigenschaften herum.
Vielleicht gibt es demnächst ein Beispiel für die YAML_Layout-Rubrik „spezial interest“?
Und wie Peter Müller schrieb, wäre es auch mal ein Thema für die „Technikwürze“.
Ist die Zeit für „css-table-based-Layouts gekommen?
Hierzu gibt es, wie kann es anders sein, Für und Wider.
Ich bin für den goldenen Mittelweg: Keine Euphorie und keine Verteufelung.
Um die float-basierten Layouts sowie speziell um das YAML-Framework mache ich mir keine Sorgen, auch in den kommenden Jahren werden absolut-positionierte Layouts, float-basierte Layouts und css-table-based layouts friedlich nebeneinander existieren.
Freitag, 14.11.08 (11:56 Uhr)
Das ist schon bemerkenswert: Da soll etwas aussehen wie eine Tabelle, es soll sich verhalten wie eine Tabelle, aber aus irgendwelchen Konventionen heraus ist man nicht bereit, an dieser Stelle eine Tabelle zu verwenden. Da nimmt man unter Umständen sogar mehr Markup und mehr CSS in Kauf, und für die nächsten Jahre krampfhafte Sonderlösungen für die aktuell gängigen Browser.
Das ganze erinnert mich an einen Vegetarier, der sich eine Pflanze züchtet, deren Früchte aussehen, riechen und schmecken wie ein Schnitzel ...
Freitag, 14.11.08 (12:26 Uhr)
@GE
Vorsicht: Es ist ein großer Unterschied, das optische Verhalten einer Tabelle nachzubilden oder Inhalte semantisch als Tabelle auszuzeichnen, nur weil man es nicht besser kann oder weiß. Es gibt durchaus berechtigte Anwendungszenarien für CSS-Tabellen, wo eine HTML-Tabelle auch weiterhin nichts verloren hat.
Ich werde dazu sicher in den nächsten Tagen was bloggen.
Freitag, 14.11.08 (12:58 Uhr)
Hallo Dirk, ja ja, ich weiss, aber ich provoziere gern und liebe Metaphern ;-).
Dass eine Tabelle nicht für Layout gedacht ist, ist ja nicht gottgegeben, sondern per Definition so. Frühere html-Spezifikationen haben das durchaus anders vermittelt. Ich könnte mir durchaus vorstellen, vorhandenes und bewährtes zu nutzen und Tabellen-Definitionen in html einzuführen:
<table type=“data”>
<table type=“layout”>
Bei Layout-Tabellen wird dann auf thead, tfoot & Co. verzichtet. Beim Boxmodell führt CSS ja auch das alte, aber sinnvolle IE-Boxmodell wieder ein, und zwar zweigleisig, mit content-box und border-box.
Aber nun genug der Provokation, ich selbst layoute mit floatenden div, aber wo es sich anbietet, “missbrauche” ich eben kurzerhand mal eine Tabelle. Das heisst aber nicht, das ich alte Layout-Konzepte, die von Grund auf und durchweg auf verschachtelten Tabellen mit rowspan und colspan usw. beruhen, gutheisse.
Donnerstag, 20.11.08 (22:46 Uhr)
Da bin ich mal gespannt wie es sich verhält eine CSS-Tabelle zu erstellen. Die Frage ist halt wie es sich an anderen Browsern verhält.
Gruß
Andy
Freitag, 21.11.08 (21:52 Uhr)
Ich kann mich mit dem Gedanken der CSS-Tabellen noch immer nicht anfreunden. Wenn ich eine Liste darstellen will nehme ich eine Liste warum soll ich dann nicht bei einer tabellarische Darstellung von Daten keine Tabelle nehmen sondern eine Div-Konstrukt. War nicht das Hauptargument von CSS-Layout das der Code besser les- und wartbar sein soll.
Ein anders Problem was ist sehen, bis die Browser aussterben die CSS-Tabellen nicht oder nur teilweise darstellen können reden die meisten Leute schon über die Problem und Features von CSS3.
Gerade bei CSS habe ich mir abgewöhnt eine Hype hinterher zu rennen. Der IE kann es eh nicht und wenn dann indem man ihn solang mit Hacks bearbeitet das die Patch-Datei größer ist als das eigentliche Style.
Freitag, 21.11.08 (21:59 Uhr)
@Alwa
Hier hast Du etwas missverstanden. Wenn es um die Darstellung tabellarischer Daten geht, dann ist selbstverständlich die HTML-Tabelle das richtige Element.
Über CSS-Tabellen kann man dann nachdenken, wenn es sich bei den Inhalten eben nicht um tabellarische Daten handelt, man aber in der Bildschirmdarstellung von den Eigenschaften des Tabellenrenderings (gleichhohe Zellen, automatische Erweiterung der Zellen ect.) profitieren will. Und in diesem Fall muss man sich in der Tat dem Problem stellen, wie man mit den älteren Browsern (hauptsächlich dem IE) umgeht.
Ich werde bei Gelegenheit hier aber über eine sinnvolle Anwendung für CSS-Tabellen bloggen, sobald YAML 3.1 fertig ist.
Montag, 24.11.08 (13:53 Uhr)
In meinen Augen sind die CSS-Tabellen auch fünf Jahre zu spät dran. Und wie beschrieben, denke ich, daß deren Markterfolg gering sein wird, da die Marktanteile der bisherigen Browser zu hoch ist.
Donnerstag, 04.12.08 (20:55 Uhr)
Manueller Trackback:
November 2008 im Kontext
[...] Die CSS Tabellen kommen [High Resolution] – dieser lesenswerte Artikel spiegelt zum Teil auch eine langsam in mir reifende Meinung: Wozu eigentlich? [...]