Warum Tabellen für Layouts manchmal besser als CSS sind

[Sven Rautenberg]

Moin!

Deine Forderung für die Spalten:
Spalte 2: "mindestens so groß wie die Navigation"
Spalten 3 und 5: "Sie sind zusätzlich immer gleich hoch"
Spalte 4: "hat eine feste Höhe", aber dann auch "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."
Daraus folgt für Spalte 1 dann eigentlich: Höhe so hoch, wie Inhalt da ist.

Da frage ich mich ja schon, wie du dieses Höhenchaos mit Tabellen hinkriegen willst, selbst wenn man der Einfachheit halber annimmt, die Breite jeder Spalte soll einfach nur 20% sein. Allein schon die Kombination der Höhe der Spalten 3 bis 5 dürfte extrem schwierig hinzukriegen sein.

Abgesehen davon sind Forderungen wie beispielsweise "feste Höhe" (welche) und "wird größer" natürlich widersprüchlich.

Sorry, "fest Höhe" = "Mindesthöhe"

Ebenso ist nicht definiert, wie sich denn diese Spalte verhält, wenn sie mehr Inhalt darstellen muß, als alle anderen Spalten.

Wie meinst du das?

Was passiert, wenn in Spalte 4 der meiste Inhalt darzustellen ist? Wie lang werden dann die anderen Spalten?

Dann zu der horizontalen Ausdehnung:
Spalte 1: "nur so breit wie der längste Inhalt"
Spalte 2: "den kompletten restlichen horizontalen Platz" (wobei der Rest als letztes übrigbleibt, wenn alle anderen Spalten ihren Platz haben)
Spalte 3 und 5: "sind immer gleich breit (so breit wie die breitere von beiden). Die Breite hängt wieder ausschließlich vom Inhalt ab."
Spalte 4: "eine vom Inhalt abhängige variable Breite"

Mit diesen Definitionen ist es möglich und legitim, der Spalte 2 genau einen Pixel Breite geben zu lassen, sofern alle anderen Spalten einfach nur ungünstigen Inhalt haben. Ein Pixel wäre ein gültiger "Rest".

Jep.

Hältst du das für ein sinnvolles Layout?

Die breite von Spalte 1 wird 100% erreichen, sofern ihr Inhalt sehr lang ist. Ein einfacher Textabsatz, der mehr als eine Zeile umfasst, reicht da schon aus. Oder was ist unter "der längste Inhalt" zu verstehen?

Bei Leerzeichen wird der Text umgebrochen. Falls dort aber ein großes Blockelement ist, dann hast du Recht.

Vom Umbrechen an Leerzeichen steht nirgendwo etwas.

Summa summarum stellst du hier ein Sammelsurium von Layoutforderungen auf, die du dir selbst vermutlich noch nie optisch und "mechanisch" vorgestellt hast.

Diese abstruse Konstruktion dann zur Argumentation "pro Tabellenlayout" zu verwenden ist daher mehr als haarsträubend.

Nun, ich vermute man kann es mit Tabellen _eher_ teilweise realisieren als mit CSS alleine.

Oho, "teilweise".

Ich vermute, man kann es ohne Tabellen deutlich weitergehender "teilweise" realisieren - also weitergehender, als mit Tabellen.

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.

Ich gebe einer Spalte eine Breite von "50%" und der anderen die Breite "*". Das erfordert aber beim Ändern wieder Eingriffe in den Quellcode. Dennoch funktioniert es immerhin.

Hey, News aus der Realität: Eine Breite "*" gibts nicht für Tabellenspalten, und sofern du sie in <colgroup> einsetzen wolltest: Das funktioniert nur im Firefox, und sonst nirgendwo.

???

Die Angabe width="*" ist für keinen Browser einen sinnvolle Angabe. Sie wird ignoriert.

Resultat ist, dass du eine Tabelle gewisser Breite hast, deren erste Spalte 50% der Tabellenbreite einnimmt. Was sagt das wohl über die Breite der zweiten, undefinierten Spalte aus?

<table style=";">
<tr>
<td valign="top" style="background:red;" width="50%">123456789</td>
<td style="background:blue;" width="*">123</td>
</tr>
</table>

  
Entferne das width="\*", es ändert nichts - nicht im Opera, nicht im IE 6.  
  
Die spannendere Frage aber ist: Wo ist in deinem Beispiel die Spalte 4 geblieben? Wie fummelst du die noch dazwischen?  
  

> Funktioniert auch in Opera wunderbar. Natürlich ist das ganze ganz böse per inline formatiert. Aber es funktioniert. Mit CSS geht's gar nicht.  
  
Es ist in der Tat korrekt, dass man mit CSS nicht die größere dynamische Breite eines von zweien Elementen (im Sinne von "shrink-to-fit") ermitteln und beiden Elementen zuweisen kann.  
  
Ich halte diese Einschränkung aber nicht für praxisfern. Sofern in irgendeiner Weise eine Breite des Gesamtkonstruktes zuweisbar ist, können die zwei Elemente sehr wohl gleichbreit definiert werden - nur eben unabhängig von ihrer Inhaltsbreite. Zumal "shrink-to-fit" sich in meinen Augen sowieso nicht sehr gut zum Layouten eignet - es wird zu unschönen Extremfällen führen, die optisch keinesfalls wünschenswert sind.  
  
Außerdem ist ja noch offen ist, wie in deinem Beispiel denn die ebenfalls beliebig breite Spalte 4 zwischen die beiden Spalten gelangen soll.  
  

> > Mal wieder Realitätscheck: Will man wirklich vertikal zentrieren, wenn die Layoutforderungen so extrem sind. Immerhin soll die Navigationsspalte ja wohl so hoch werden, wie Inhalt in Spalte 2 da ist. Aber welchen Sinn hat es, eine Navigation zu haben, die durch vertikale Zentrierung erst auf der zweiten Bildschirmseite zu sehen ist, weil der Inhalt insgesamt drei Bildschirmseiten lang ist?  
>   
> Das ganze ist natürlich sinnfrei. Ich wollte doch nur zeigen, welche Probleme es gibt. =\*(  
  
Du zerrst sinnlose Beispiele an den Haaren herbei. Überlege selbst, welche Wahrhaftigkeit das deiner gesamten Argumentation gibt.  
  

> > Man kann mit CSS auch vertikal zentrieren. Dort, wo es sinnvoll ist.  
>   
> Ja, man braucht 3 Hilfselemente. Ich musste das mal auf einer Seite machen, wo Bilder einer Bildergallerie vertikal ohne Tabelle zu zentrieren waren. Schrecklich.  
  
Komisch: Wenn ich mir eine Tabelle angucke, sind da auch genau drei Hilfselemente enthalten: <table>, <tr> und <td>. Eigentlich sogar vier: <tbody> ist implizit enthalten und muß vor allem in diversen Inkarnationen des Internet Explorers bei Manipulation mit Javascript explizit angegeben werden, sonst \*BUMM\*.  
  

> > Auch - oder vielleicht sogar besonders - die Autoren von Druckwerken wie Büchern, Zeitschriften und Zeitungen schreiben zuerst so, wie sie denken, und überarbeiten ihren Text dann mehrfach so, dass er ins Layout paßt.  
>   
> Die Armen. Das liegt doch aber vermutlich eher daran, dass es eben teuer ist, wenn nicht alles ganz genau passt (dann wird's ne Seite mehr, das kostet). Im Internet haben wir dieses Problem zum Glück nicht.  
  
Es widerlegt dein Argument, du könnest so texten, wie du willst. Niemand kann das, wenn er Wert auf die Optik legt. Entweder der Text wird passend zur Optik gemacht, oder die Optik passend zum Text.  
  
Egal ob mit oder ohne Tabellen oder CSS: In der Situation "Redakteur gibt Text in CMS ein" ist immer nur der Fall "Text wird passend zur Optik gemacht" gegeben.  
  
 - Sven Rautenberg

-- 
"Love your nation - respect the others."