Warum Tabellen für Layouts manchmal besser als CSS sind

[Sven Rautenberg]

Moin!

Nun gut. Mal als Beispiel folgendes Layout:

Ein ziemlich konstruiertes Layout, möchte ich meinen. Aber gut, manche Designer können sich ja nicht zurückhalten.

Meine persönliche Sicht auf Designvorgaben ist allerdings immer, dass ich auch den Sinn erfassen muß, der sich hinter einer grafischen Darstellung versteckt. Das ist unabdingbar, denn Spalten haben nur sehr selten gar nichts miteinander zu tun. Oft besteht zumindest für einige irgendeine Verbindung zwischeneinander, die es deshalb auch technisch zu berücksichtigen gilt.

1. Ein Header (so breit wie der Viewport)

Das dürfte vermutlich die leichteste der Übungen sein. :)

Fünf Spalten:

1. Die erste von links ist die Navigation. Sie ist immer nur so breit wie der längste Inhalt, welcher dynamisch geändert werden kann. Etwas wie "width:12em;" scheidet also aus.

Du meinst "so breit wie der BREITESTE Inhalt"?

Diese Forderung ist weder mit Tabellen noch mit CSS sinnvoll zu erfüllen, da kein Layout es verträgt, wenn Ausnahmezustände wie "Donaudampfschifffahrtslogbuch" auftreten. In so einem Fall ist immer eine Umformulierung des Linktextes angesagt.

2. Die zweite von links ist der Inhaltsbereich. Er ist immer mindestens so groß (von der Höhe her) wie die Navigation. Er nimmt den kompletten restlichen horizontalen Platz ein.

Wenn der Inhalt den restlichen horizontalen Platz einnimmt, ist für die restlichen drei Spalten kein Platz mehr. Wo bleiben die ab?

3. Die dritte und fünfte Spalte von links, beinhalten zusätzliche Informationen. Beide Spalten sind immer gleich breit (so breit wie die breitere von beiden). Die Breite hängt wieder ausschließlich vom Inhalt ab. Sie sind zusätzlich immer gleich hoch.

Zusätzliche Informationen wozu?

Und auch hier wieder Kritik an der Formulierung: Wenn die beiden Spalten gleich breit sind, dann gibt es keine breitere von beiden.

Für die dynamische Breite gilt ansonsten dasselbe, wie für die Navigation. Abgesehen davon würde mich sehr interessieren, wie du die Forderung nach "gleichbreite dynamische Breite" mit Tabellen realisiert kriegst. :) Ich will nicht behaupten, dass es unmöglich ist - aber ich halte es für den Knackpunkt dieser Idee.

4. Die vierte Spalte von links(zwischen den vorherigen beiden) hat eine feste Höhe, aber eine vom Inhalt abhängige variable Breite. Sie ist immer mindestens so hoch wie der Viewport (minus der Höhe des Footers), wird aber größer, wenn die zweite Spalte von links größer als 100% des Viewports wird.

Interessanterweise hast du nur zu den Spalten 2 und 4 Aussagen zu deren Höhenverhalten getroffen.

5. Der Footer. Er ist immer ganz am Ende des Viewports, wird eine der oberen Spalten aber größer, wandert er weiter nach unten. Er nimmt 100% der Breite ein.

Zu dem Höhenverhalten des Footers hast du wieder gar keine Aussage getroffen. Ebensowenig zu dessen Breitenverhalten, sowie zum Breitenverhalten der Gesamtanordnung der fünf Spalten.

6. Innerhalb der Navigation (erste Spalte von links) befinden sich zwei weitere Container. Sie haben eine feste Höhe, aber keine feste Breite (wieder Inhaltsabhängig) und ihr Inhalt (sowohl gefloatete Block-Elemente als auch Inline-Elemente) ist vertikal zentriert.

Was soll das genau sein? Sinn? Inhalt?

Bedingungen: Der IE6 & IE7 muss es darstellen können. Ob Quirks oder nicht, ist mir egal. Der Effekt soll wirklich erzielt werden. Es soll nicht nur so _aussehen_ als wären zwei Spalten gleich groß o.ä..

Ohne jetzt groß einen Gedanken an die Realisation dieses unvollständig beschriebenen Layouts verschwendet zu haben würde ich sagen, dass es mit keinem Mittel realisierbar ist.

Sollte jemand das Gegenteil beweisen wollen: Mein Respekt ist ihm sicher, aber ich persönlich habe kein Interesse, solch ein merkwürdiges Layout in tagelanger Kleinarbeit hinzufummeln.

Oder widersprich mir jemand hinsichtlich der Realisierungszeit?

So. Ich gebe zu, das ist etwas heftig und wird in der Realität wohl eher selten auftauchen. Dennoch treten die einzelnen Teilprobleme öfters auf und können nicht einfach gelöst werden.

Das Problem ist, dass du hier Teilprobleme miteinander verbindest, die man in der Praxis so nie verbinden würde. Für sich genommen würde man sie vielleicht lösen können - die Kombination macht sie unlösbar. Und insbesondere die Forderung, ein Layout für beliebig unbändigen Content zu erstellen sorgt für die Probleme - sowohl mit Tabellen, als auch mit CSS. Diese Probleme sind im Prinzip nur dadurch zu umgehen, dass man diese kritischen Inhalte passender formuliert.

Ich selbst könnte dieses Layout für die standardkonformen Browser (Firefox, Opera, Safari, Konqueror...) durchaus nur mit Divisionen hinbekommen. Da bräuchte ich dann aber sehr viele Hilfselemente, Browserhacks und so weiter.

Du würdest auch mit Tabellenlayout extrem viele Hilfselemente benötigen. Oder willst du behaupten, dass du einfach nur eine fünfspaltige Tabelle zu verwenden brauchst, und der Rest ist alles nur sinnvolles semantisches HTML? Da möchte ich doch mal gepflegt widersprechen.

Monster-Layouts erfordern Monster-HTML und Monster-CSS.

Mit Tabellen _und_ Divisionen wäre das ganze etwas schneller und Browserfreundlicher gelöst. Nachteile hat das aber natürlich auch.

Es hat z.B. einen Nachteil: Während Villa Tabello noch auf das Rendering wartet, wird in Villa Stylesheeto schon die nächste Seite angesurft. :)

Und um eine Gegenfrage zu stellen, warum werden seit einigen Jahren sehr
große Websites im Falle eines Relaunchs (fast) immer komplett CSS-basiert
realisiert? Dafür muß es doch Gründe geben ... ;-)

Ich weiß es nicht. Vielleicht weil ihr Layout nicht so komplex ist oder es nur für standardkonforme Browser konzipiert wird?

Mit Sicherheit nicht. Keine kommerzielle Website kann es sich leisten, auf den IE6 zu verzichten. Qualitätsagenturen nehmen auch Mac-Browser extrem ernst, also eigentlich alle Browser, die nennenswerten Marktanteil oder Prestigewert haben. Und es ist möglich, eine Site sowohl für IE6, IE7, Firefoxe, Safaris und Operas auf Windows, Mac und Linux gangbar zu machen. Manche Dinge erfordern Hacks (vor allem der IE6 erfordert sowohl separate CSS-Anweisungen, als ggf. auch noch Reparaturen mit Browser-Sniffing-Javascript - wobei die Reparaturen bei abgeschaltetem Javascript lediglich eine nicht identische Darstellung zur Folge haben, aber kein zerstörtes Layout).

Um das alles hinzukriegen, benötigt man aber zweifelsohne viel Zeit, viel Erfahrung, viel Geduld mit den Browsern, Leidensfähigkeit und Experimentierfreude.

Ich kann aber nicht erkennen, dass ein Tabellenlayout das in irgendeiner Form leichter macht. Jedenfalls aus meiner Erfahrung heraus.

- Sven Rautenberg