CSS-Tabelleneigenschaften nutzen

Jetzt, wo der IE6 von Microsoft offiziell als vollkommen böse und auch der IE7 als uncool angesehen ist, können wir so langsam dazu übergehen, all diejenigen CSS2.1-Eigenschaften auch tatsächlich zu verwenden, von denen man bisher nur theoretisch und hinter vorgehaltener Hand geredet hat, gewissermaßen.

Eine sehr praktische Sache sind die Eigenschaften display: table und display: table-cell. Und zwar beispielsweise immer dann, wenn man eine unbekannte Anzahl von Elementen in der Horizontalen nebeneinander platzieren möchte, und darauf aus ist, dass eine gewisse Gesamtbreite immer exakt eingehalten wird. Bestes Beispiel sind horizontale Navigationen, so wie auf der Website des PIA e. V.:

PIA 2

PIA

Die Breite der einzelnen li-Elemente sind im CSS gar nicht festgelegt. Statt dessen bekommt das ul ein display: table verpasst, und seine lis ein hübsches display: table-cell. Die Breite von ul ist auf eine bestimmte Pixelanzahl festgezurrt, und die lis richten sich dann automatisch so aus, dass sie zusammen genau diese Breite bekommen.

Wenn nun dem Kunden einfällt, dass er einen oder zwei Hauptmenüpunkte mehr oder weniger benötigt, ist dies absolut kein Problem!

(Als Fallback-Lösung für IE6 und IE7 sollte man natürlich mit Floats arbeiten, muss dann aber leider doch wieder eine feste Breite vergeben, damit es einigermaßen aussieht.)

27 Kommentare

Schepp

Nicht zu vergessen die Tatsache, dass man endlich ohne abenteuerliche Verrankung Elemente vertikal zentrieren kann!

Philipp

IE6 Fallback heißt dann, dass es zwar darstellt aber dann nicht immer bündig mit der Kante abschließt?

Finde ich einen guten Kompromiss!

Willi

Nur wäre das dann semantisch das gleiche wie HTML-Tables für die Navigation, oder nicht?

Free the Pixel

@willi Die Navigation hier ist ja keine Tabelle im semantischen Sinne, sondern man macht sich ja nur die Eigenschaften der Tabellendarstellung zu Nutze. Im Gegenteil, ein <table> Element wäre hier semantischer Unsinn.

Gerrit

@Willi: Semantik bezieht sich ausschließlich auf den HTML-Part eines Webdokuments. Man kann also per CSS nicht die Semantik definieren.

Die Navi bleibt im HTML eine Liste, egal, was ich per CSS damit anstelle.

GE

Mein Fallback für alte Browser:

Ich nehmer einfach eine Tabelle, wo ich die Layout-Eigenschaften einer Tabelle brauche ;-)

Das »Layout-Tabellen sind böse« habe ich schon wieder hinter mir.

Zur Erinnerung: »table« kommt vom lateinischen »tabula« – Fläche.

Eine Tabelle ist also dazu da, Elemente sinnvoll und übersichtlich auf einer Fläche darzustellen. Eine typische Layout-Aufgabe. Was »tabellarische Daten« sind, definiere ich mir selbst ;-)

Gerrit

@GE: Und ich bin inzwischen auch über dieses Konzept »Elektrizität« hinweg und betreibe meine mechanischen Abakusse wieder mit Dampfkraft. Was praktisch ist, definiere ich mir selber.

GE

Hallo Gerrit, ich sehe, wir verstehen uns ;-)

Nee, im Ernst, was ich mache, hat überhaupt nix mit den verschachtelten Tabellen-Layouts der 90er zu tun.

Und innerhalb der Tabellenzellen arbeite ich selbstverständlich semantisch, Ãœberschriften, Absätze, Listen …

Nur bin ich nicht bereit, das, was es schon gibt, mit CSS nachzubauen, und dabei auch noch an Fallbacks für alte Browser zu denken …

Wo die absolut genialen, bewährten, zuverlässigen und ohne wenn und aber funktionierenden flexiblen Layouteigenschaften einer Tabelle benötigt werden (und nur da), da setze ich sie einfach ein.

Genau da, wo Du die »modernen« CSS Eigenschaften einsetzt, nicht mehr und nicht weniger.

Zu Deinem Vergleich: Wenn ich eine Maschine bauen will, die auch da funktioniert, wo es keinen Strom gibt (alte Browser), sollte die nicht elektrisch angetrieben sein ;-)

GE

Hallo Gerrit, ich nochmal,

eigentlich hast Du ja Recht, die Navigation wird ja in der Regel vom CMS als Liste ausgegeben, und da ist es schon toll, wenn man dieser Liste per CSS die Layout-Eigenschaften einer Tabelle geben kann.

Ich habe mich auch nicht explizit auf Dein Beispiel bezogen, eher allgemein auf den (wohlüberlegten und sparsamen) Einsatz von Tabellen für Layout Zwecke hier und da und wo es passt, was man eben so im Template regeln kann.

Davor schrecke ich halt nicht (mehr) zurück.

Willi

„@Willi: Semantik bezieht sich ausschließlich auf den HTML-Part eines Webdokuments. Man kann also per CSS nicht die Semantik definieren.

Die Navi bleibt im HTML eine Liste, egal, was ich per CSS damit anstelle.“

Vielleicht steh ich auf dem Schlauch, aber ich sehe da keinen Unterschied, ob ich ein Element nun im HTML oder im CSS falsch bezeichne. Natürlich kann man darüber streiten, ob eine Liste eine (einspaltige/einzeilige) Tabelle ist oder nicht, aber an welcher Stelle ich nun etwas als Tabelle bezeichne, scheint mir Haarspalterei zu sein. Mir ist allerdings klar, dass man hier die Vorteile einer Tabelle mit der Flexibilität der CSS-Gestaltung kombiniert.

Gerrit

@Willi: Du stehst tatsächlich auf dem Schlauch. Wenn wir über Semantik reden, spielt CSS überhaupt keine Rolle. CSS und Semantik haben nichts miteinander zu tun!

Wenn es um Semantik geht, betrachtet man ausschließlich den HTML-Code. Und in HTML ist die Navigation als Liste ausgezeichnet. Es gibt kein Table-Element!

Per CSS habe ich die Möglichkeit, das Layout-Verhalten der Liste so zu definieren, dass sie aussieht wie eine Tabelle, aber es bleibt semantisch trotzdem eine Liste.

Marc

Dein einleitender und abschließender Satz widersprechen sich und ich finde es etwas gefährlich, nicht deutlicher darauf hinzuweisen: Denn der IE7 kann das nicht!

Das Problem an der Kiste mit der »Fallbacklösung feste Breite« ist, dass es keine Fallbacklösung ist. Denn definierst Du eine feste Breite, hast Du ganz schnell zwei Zeilen, wenn der Redakteur Menüpunkte hinzufügt (unwahrscheinlich aber nicht unmöglich wenn es um die Hauptnavi geht) oder den Text der bestehenden Punkte ändert (wahrscheinlicher, zweimal selbst erlebt bei dieser Lösung). Und dann kommt nach 3 Wochen der Anruf, dass es im IE7 scheiße aussieht und Du weißt, dass eine von Dir eigentlich perfekte Lösung seit 3 Wochen eventuell sogar (teilweise) unbrauchbar war, weil der letzte Punkt weggerutscht ist. Und das Nachjustieren im IE-Stylesheet… müßig, da man doch ab und an kontrollieren sollte, ob da was geändert wurde.

Dann doch wirklich lieber eine JS-Fallbacklösung, die die Breite berechnet und die Punkte richtig verteilt. Vor allem im Hinblick auf media-querys, wenn man sowieso unterschiedliche Versionen anbietet.

Und wenn dann IE7 ohne JS… eben: Keine feste Breite, bisschen Padding: immerhin nutzbar.

Marc

Oh mann. Den Halbsatz mit »IE7 böse« habe ich tatsächlich überlesen. Naja, gilt ja trotzdem. Nichts für ungut.

florian

Eingangs eine Frage und Anmerkung:
Warum jetzt erst? Die Darstellungs-Kompatibilität zum IE6 habe ich den ersten Kunden mit Distributionsstart des IE7, dem letzten kurz vor dem IE8 ausgeredet … und da sahen die Fallbacks nicht schlimmer aus als jetzt! ;)

@Willi:
Sich in SGML, insbesondere HTML – meinetwegen sogar XML und XHTML – an einer Semantik zu orientieren hat den Sinn und Zweck, die vorhandenen Elemente (»Tags«) sinnvoll einzusetzen, damit unabhängig von der Weiterverwendung eine fundierte Basis da ist. Auf deutsch: Ein Blockquote soll als <blockquote> getagged sein, damit sowohl der herkömmliche Browser, die alltägliche Suchmaschine wie Google, Screenreader wie JAWS, …, wissen, »da kommt ein Zitat«.
Eine Tabelle fürs Layout zu verwenden entspricht nicht der Definition, sieht im herkömmlichen Browser vielleicht noch gut aus, verwirrt aber alle anderen Parser, die sich am Standard definieren. (Konkret ein <table> mögen die meisten Parser derzeit noch verzeihen, aber dem Standard entspricht es trotzdem nicht und wird – hoffentlich – demnächst überall rausfliegen.)
Darüberhinaus erzeugt gerade das <table>-Tag einen enormen Overhead (Standard ist ja: <table><tbody><tr><td></td></tr></tbody><table>).

Wie man mit der Darstellung auf einzelnen Geräten umgeht – und ein Stylesheet steuert ja ausschließlich die Darstellung im gemeinen Browser – ist einem selbst überlassen. Solange das Fundament für alle stimmt.

Emanuel

immer wieder amüsant, wie die aufregung los geht, wenn es ums thema css-table-eigenschaften geht. viele scheinen nur den merksatz »tabellen nicht zu layout-zwecken verwenden« verinnerlicht zu haben, ohne genau zu wissen, weshalb das so ist.

die tabelle als solche (aus html-sicht) ist natürlich nur für tabellarische daten gedacht. aber wenn ein html-dokument semantisch korrekt aufgebaut ist, wird man daran auch mit css nicht mehr rütteln können.

man kann höchstens noch alles so verquer anordnen, dass der otto-normal-besucher, der nicht direkt mit dem quelltext in berührung kommt und die seite auf rein visueller ebene wahrnimmt, komplett verwirrt wird.

und bitte berichtigt mich, falls ich mich hier irren sollte :-)

florian

@Emanuel, Fantastisch richtig und weniger kryptisch ausgedrückt als von mir :), wenn im ersten Absatz auch unnötig polemisch.

Willi

@Florian: Danke für die Erklärung! Die Nachteile von HTML-Tabellen wie Overhead, Inflexibilität und Probleme bei Screenreadern waren mir bewusst. Aber ich dachte, dass solche Interpretationsschwierigkeiten bei CSS auch auftreten können, dass das also z.B. von Screenreadern mitgelesen wird. Da gabs doch z.B. mal das Problem mit display: none, wenn ich mich nicht täusche. Aber wenn ich so darüber nachdenke, war das wohl eher ein Gedankenfehler, da die CSS-Auszeichnung als Tabelle den Aufbau der Website ja nicht verändert, im Gegensatz zu HTML-Tabellen. Das kommt eben davon, wenn man solche Gedankengänge nicht zu Ende denkt. ;)

florian

@Willi: Immer gern, so eine Erläuterung hilft gelegentlich ja auch, die eigenene Gedanken zu ordnen.

Ich habe das Thema Smartphones bewusst nicht angesprochen, das ist ja allerdings auch noch so ein Ding, bei dem dessen Parser das <table> völlig beabsichtigt interpretiert, aber dann auf seinem viel zu kleinen Display »merkwürdig« darstellt. In der Realität wird das durch alle möglichen Fallbacks und Workarounds ausgeglichen … in einer fernen Zukunft können wir uns alle diese Fallbacks und Workarounds sparen, weil niemand mehr eine so (unnötig) komplizierte Lösung anbietet.

Dass neuerdings das W3C und die WHATWG Tabellen-Layouts wohl wieder standartisieren (http://lists.w3.org/Archives/Public/public-html/2011Mar/0245.html) lassen wir mal nicht unter den Tisch fallen.
Das dürfte bei sachlicher Argumentation aber bei jedem Webworker auf taube Ohren stoßen.

Emanuel

@florian: vielen dank :-) und bitte entschuldige die polemik, man lässt sich in der online-kommunikation ja hin und wieder doch gehen. auch wenn man es mittlerweile eigentlich besser wissen sollte.

Mind

@Emanuel
Ich erinner mich da grade an einen Kollegin die eine Jahres übsersichts Tabelle (elend lang mit zig Kollumnen) mit divs nachgebaut hat :)

Mir tat da der Margen ganz weh an dem Tag, naja kamm wohl vom lauten lachen :p

hans

ich nehme für sowas ebenfalls immer ne echte tabelle :o) stört keinen, ehrlich ;o)

Bernd

Kann mich der hier herrschenden Mehrheitsmeinung nur anschließen. Man hat zwar immer ein wenig das Gefühl, dass Tabellen irgendwie »veraltet« wirken – aber das kommt eben auch von solchen Artikeln wie oben.
Nix dagegen zu sagen, dass man auch über reines CSS die Inhalte dorthin setzt wo man sie haben will – aber letztendlich ist eine Tabelle doch immer wieder das einfachste und schnellste Mittel »kleine« Positionierungsprobleme hinzukriegen.
Ich bin glücklich darüber was CSS inzwischen kann. Dass eine Seite nicht mehr aus 20 ineinander verschachtelten Tabellen besteht ist eine echter Fortschritt und erleicheter die Ãœbersicht sehr – aber so einfach, wie ich mit einer Tabelle innerhalb eines überscheuberen Bereiches ( eben bei noch unverschachtelten Tabellen) weiß wo was positioniert ist, geht es mit CSS eben noch nicht.
Ich würd eie »gute alte Tabelle« nicht mit einer Dampfmaschine vergleichen sondern lieber mit einem Rad.
Man kann ein Abrollen auch anders verwirklichen – aber das Rad ist und bleibt eine optimale Lösung.

Seon

@Bernd: Was du schreibst, ist nicht die Mehrheitsmeinung, sondern ganz mieser Spam. Du bist mir kürzlich schon bei Spreeblick durch einen Spam-Kommentar unangenehm aufgefallen. Gerrit, bitte übernehmen Sie. ;)

Gerrit

@Seon: Ich traue meinen Lesern genug Intelligenz zu, selber entscheiden zu können. Wer im Kommentarbereich beim Thema bleibt und Argumente hat, soll diese ruhig anbringen können, auch wenn sie schwach sind.

Seon

@Gerrit: Es ging mir weniger darum, dass per Kommentarfunktion Unsinn verbreitet wird, sondern darum, dass auf diese Weise offensichtlich kommerzielle Links untergebracht werden sollen.

Marc

Auch wenn ich nicht immer Deine Meinung teile, lese ich Dein Blog regelmäßig. Denn oft lohnt sich die (mitunter kritische) Auseinandersetzung mit Deinen Thesen und es gibt neue Denkanstöße. – Und manchmal (wie in diesem Fall) erinnert es mich an die Dinge, die ich unbedingt mal machen wollte, wenn IE6 und IE7 keine Rolle mehr spielen, die ich aber längst vergessen habe, weil sich IE6 und IE7 so furchtbar lang in unseren Statistiken breit gemacht haben. Danke hierfür!
Ãœbrigens: Eine interessante Alternative für die alten IEs ist display:inline-block…

Francesco

Ohne table-layout: fixed; sieht’s aber eher mau aus. Sollte evtl. noch im Artikel ergänzt werden.

Kriege das nur so hin (Beispiel):

HTML:

<nav> <ul> <li>…</li> … </ul>
</nav>

CSS:

nav { display: table; table-layout: fixed; width: …;
}

ul { display: table-row; }
li { display: table-cell; }

Kommentar verfassen

Mit dem Absenden dieses Formulars erklären Sie sich damit einverstanden, dass ich die von Ihnen eingegeben Daten auf meinem Webserver speichere. Ihr Name, der Kommentartext und die angegeben Website werden für die anderen Besucher von praegnanz.de angezeigt. Ich gebe jedoch insbesondere Ihre E-Mail-Adresse nicht an Dritte weiter und nutze diese auch nicht zu Marketing- oder Statistik-Zwecken. Sie können alle Daten zu einem späteren Zeitpunkt wieder entfernen lassen.