Tabelle: 'rowspan' und Zellenhöhe erzwingen
Stefan
- html
Hallo zusammen!
Ich habe ein Problem: Ich habe eine Tabelle, in der sich links eine Zelle über drei Zeilen erstreckt. Die drei Zellen rechts daneben sollen sich nun wie folgt verhalten: Die obere und die untere Zelle sollen immer eine feste Höhe haben, die mittlere Zelle soll je nach Größe der linken Zelle gestreckt werden:
---------------------------------------
| | feste Höhe |
| |------------------|
| | |
| variable | variable |
| Höhe | Höhe |
| | |
| |------------------|
| | feste Höhe |
---------------------------------------
Stattdessen passiert folgendes (IE6): Sobald der Inhalt der linken Zelle höher ist als der der rechten drei (was in der Regel der Fall ist), wird die "überschüssige" Höhe auf die rechten drei Zellen verteilt.
Ich habe nun schon eine Menge gegoogelt und in Selfhtml gesucht und gelesen. Das Problem scheinen ja viele zu haben. Ich habe von Doctype-Switching gelesen und eine Menge rumprobiert, aber hinbekommen habe ich es nicht. Den aktuellen Stand meiner Bastelei kann man hier ansehen (dort ist die Tabelle noch etwas komplexer):
http://test.schwachsinn-online.de/
(Die Zellen mit den Grafiken 2 und 4 sollen nur so hoch sein, wie die Grafiken darin.)
Ich habe auch gelesen, dass man für das Layout besser CSS nimmt als eine Tabelle - aber ehrlich gesagt wäre mir eine Tabellen-Lösung lieber, wenn es eine gibt. Ach ja und andere Browser als den IE will ich natürlich auch berücksichtigen, ich habe bloß bis jetzt nur im IE getestet.
Ich bin für jede Hilfe dankbar!
Viele Grüße,
Stefan
Ich habe ein Problem: Ich habe eine Tabelle
Rein interessehalber...was sind das für tabellarische Daten, die Du mit diesen paar Zellen darstellen wirst?
Hi,
Rein interessehalber...was sind das für tabellarische Daten, die Du mit diesen paar Zellen darstellen wirst?
es sind erwartungskonform keine. Folge dem Link; er ist ein hervorragendes Beispiel für die alte Weisheit "nomen est omen".
Cheatah
Rein interessehalber...was sind das für tabellarische Daten, die Du mit diesen paar Zellen darstellen wirst?
es sind erwartungskonform keine. Folge dem Link; er ist ein hervorragendes Beispiel für die alte Weisheit "nomen est omen".
Ja, so wie es weiter unten in meinem Beitrag auch steht - die Tabelle dient Layout-Zwecken. Falls es eine Lösung mit der Tabelle gibt, würde ich sie der Einfachheit halber vorziehen. Falls nicht werde ich nötigenfalls auch alles in ein CMS-Layout umbauen.
Viele Grüße,
Stefan
Falls es eine Lösung mit der Tabelle gibt, würde ich sie der Einfachheit halber vorziehen.
Dass das einfacher ist, sagst Du nur, weil Du (vermute ich mal) noch kein CSS-Layout gemacht hast. Das Gewohnte scheint immer einfacher. Ein Urteil kann man sich aber erst erlauben, wenn man alle Möglichkeiten kennt.
Außerdem geht es beim Tabellenmissbrauch nicht nur um die Einfachheit, sondern die Nutzbarkeit bei den Anwendern, was das wichtigste an einer Website sein sollte.
Falls nicht werde ich nötigenfalls auch alles in ein CMS-Layout umbauen.
Ein CMS-Layout oder CSS-Layout? :-)
Falls es eine Lösung mit der Tabelle gibt, würde ich sie der Einfachheit halber vorziehen.
Dass das einfacher ist, sagst Du nur, weil Du (vermute ich mal) noch kein CSS-Layout gemacht hast. Das Gewohnte scheint immer einfacher. Ein Urteil kann man sich aber erst erlauben, wenn man alle Möglichkeiten kennt.
Da ist was dran. Ich werde mich damit auseinandersetzen und einen zweiten Versuch mit CSS machen.
Außerdem geht es beim Tabellenmissbrauch nicht nur um die Einfachheit, sondern die Nutzbarkeit bei den Anwendern, was das wichtigste an einer Website sein sollte.
Aber wie ist es denn beim CSS-Layout z.B. mit der Abwärtskompatibilität? Eine Tabelle wird auch in alten Browsern zumindest soweit richtig angezeigt, dass man noch alles lesen kann. Bei verschachtelten DIV's ist das m.W. u.U. nicht der Fall.
Falls nicht werde ich nötigenfalls auch alles in ein CMS-Layout umbauen.
Ein CMS-Layout oder CSS-Layout? :-)
Naja, wohl eher CSS - ist mir schon kurz nach dem Abschicken aufgefallen... :-/
Viele Grüße,
Stefan
Aber wie ist es denn beim CSS-Layout z.B. mit der Abwärtskompatibilität? Eine Tabelle wird auch in alten Browsern zumindest soweit richtig angezeigt, dass man noch alles lesen kann. Bei verschachtelten DIV's ist das m.W. u.U. nicht der Fall.
Erstens...reden wir hier von CSS-Layout und nicht von "verschachtelten divs". Das Element <div> ist ein allgemeines Block-Element, das nur zum Gruppieren mehrerer Elemente dient. Mit CSS-Layout hat es nichts zu tun. Nicht mehr, als ein <h1>, <p> oder <address>.
Zweitens: Die Abwärtskompatibilität ist bei CSS-Layouts besser als bei Tabellenlayouts. Tabellenlayouts funktionieren nämlich nicht in allen Browsern, weil es Browser gibt, die keine Tabellen darstellen können. In diesen Browsern sind diese Sites unbenutzbar.
CSS-Layouts bauen aber auf einer grundsoliden Struktur (HTML, Semantik), die von jedem Browser da draußen verstanden wird, auch meinetwegen einem Netscape 0.8. Die mit CSS-Layout gestalteten Sites verinnerlichen außerdem die Trennung von Inhalt und Layout. Damit wird die CSS-Site auch in alten Browsern, wie auch in Textbrowsern, Vorlesebrowsern und Suchmaschinen 100% nutzbar (Barrierefreiheit). Tabellenlayouts sind nicht nur in alten Browsern nicht nutzbar, auch in modernsten Vorlesebrowsern. Auch Suchmaschinen sind von semantischem HTML weitaus mehr entzückt, als von Tabellenmissbrauch.
Der Einwand, der von Dir kommen wird ist, dass Sites mit CSS-Layout in CSS-unfähigen Browsern aber anders aussehen. Ja, das ist natürlich klar. Aber sie sind immerhin benutzbar, das ist das Wichtigste an einer Website! CSS-unfähige Browser stellen aber immerhin eine gut durchdachte, semantische Seitenstruktur dar, die jeder lesen und verstehen und nutzen kann. Das ist der Knackpunkt.
es sind erwartungskonform keine.
Das war mir auch klar, aber man will ja höflich bleiben, und den OP die vernichtende Antwort selber geben lassen ;-)
Folge dem Link
Das tat ich. Dort sah ich weder tabellarischen Inhalt noch Inhalt überhaupt.
er ist ein hervorragendes Beispiel für die alte Weisheit "nomen est omen".
Jau. Gut gesprochen! :-)
Hallo Stefan,
height:inherit
, nicht height:inherited
Dein HTML-Element bräuchte dann auch noch eine Höhe per CSS. Die Höhe musst du über alle Nachfahrenselemente durchreichen bis zu deiner Tabellenzelle mit der Nummer 3.
Und weil es eh nur noch höchstens vier Wochen dauert, bis die Schoko-Nikoläuse wieder im Supermarkt in den Regalen stehen, gebe ich dir auch noch diesen Link, der dich vielleicht inspiriert:
http://www.sprachlernspiele.de/engel/matroschka.html
Gruß Gernot
Moin!
Ich habe ein Problem: Ich habe eine Tabelle, in der sich links eine Zelle über drei Zeilen erstreckt. Die drei Zellen rechts daneben sollen sich nun wie folgt verhalten: Die obere und die untere Zelle sollen immer eine feste Höhe haben, die mittlere Zelle soll je nach Größe der linken Zelle gestreckt werden:
Ich habe mich früher mal recht intensiv mit Tabellenlayouts auseinandergesetzt (damals war das noch nicht so schlimm mit den CSS-Befürwortern ;) ), und als Quintessenz festgestellt:
Spaltenbreiten kann man wirksam nur in der obersten Tabellenzeile angeben (mit width-Attribut), und Zeilenhöhen nur in der ganz linken Tabellenspalte (mit height-Attribut).
Das bedeutet: Du kannst ganz links, in der übergreifenden Zelle, lediglich die gemeinsame Höhe für alle drei Zeilen angeben, der Browser ist dann aber frei, die weiteren Höhen nach Belieben festzusetzen - auch wenn man diese Zellen noch so toll mit height-Attributen oder CSS dazu bewegen möchte, eine bestimmte Höhe anzunehmen.
Einzige Lösung, wenn es Tabellen bleiben sollen: Ganz links muß noch eine winzig schmale (width="1") zusätzliche Spalte untergebracht werden, welche kein rowspan enthält, aber die Höhenangaben für die rechten Zellen vorwegnimmt.
Alternativ könnte man eventuell auch mit verschachtelten Tabellen was reißen, um von diesem rowspan wegzukommen. Das macht die ganze Sache aber nicht weniger eklig.
- Sven Rautenberg
(damals war das noch nicht so schlimm mit den CSS-Befürwortern ;) )
Auch wenn Dein Smiley mir suggeriert, dass Du selbst CSS-Befürworter bist, so kann ich mich mit solchen Kommentaren rein gar nicht anfreunden. Weil dadurch Ahnungslose immer glauben werden, die CSS-Befürworter wären nur Spinner, die nach einiger Zeit wieder aussterben, und es wäre rein gar nichts schlimm an Tabellenlayouts.
Leider verstehen diese Ahnungslosen dann noch weniger, dass das Blödsinn ist.
Nur deswegen gibt es auch immer noch Auflösungsweichen...*yuck!*
Moin!
(damals war das noch nicht so schlimm mit den CSS-Befürwortern ;) )
Auch wenn Dein Smiley mir suggeriert, dass Du selbst CSS-Befürworter bist, so kann ich mich mit solchen Kommentaren rein gar nicht anfreunden. Weil dadurch Ahnungslose immer glauben werden, die CSS-Befürworter wären nur Spinner, die nach einiger Zeit wieder aussterben, und es wäre rein gar nichts schlimm an Tabellenlayouts.
Ich bin auf jeden Fall CSS-Befürworter, aber ich stelle auch ganz deutlich eines fest: Tabellen und CSS schließen sich nicht gegenseitig aus. Das kann ja schon deshalb nicht gehen, weil das eine HTML ist, das andere CSS. "display:block" und "display:none" - das schließt sich gegenseitig aus. :)
Fakt ist auch, dass Tabellen (bzw. mit entsprechenden display-Werten hingezüchtete anderweitige Blöcke) z.B. bei vertical-align eine wesentlich weitergehende Formatierungsmöglichkeit bieten, als normale Blockelemente.
Leider verstehen diese Ahnungslosen dann noch weniger, dass das Blödsinn ist.
Wenn ich mir teilweise die zur Verfügung stehenden Alternativen ansehe, die mir CSS bietet, und dazu noch die Implementierungsfehler nehme, die unser gemeinsamer Lieblingsbrowser dabei präsentiert, dann muß ich deutlich sagen, dass ich diesem ganzen Bug-Minenfeld auch sehr gerne durch eine passend eingesetzte Tabelle entgehen, die in dieser Hinsicht wesentlich weniger Probleme aufwirft und genau das tut, was man von ihr erwartet.
- Sven Rautenberg
Ich bin auf jeden Fall CSS-Befürworter, aber ich stelle auch ganz deutlich eines fest: Tabellen und CSS schließen sich nicht gegenseitig aus.
Das würde ich auch nie sagen, und darum ging es (mir) hier ja auch gar nicht.
Leider verstehen diese Ahnungslosen dann noch weniger, dass das Blödsinn ist.
Wenn ich mir teilweise die zur Verfügung stehenden Alternativen ansehe
Das Problem ist, dass aufgrund mangelnder Interpretation seitens (eigentlich nur eines) Browsers das Layout über die Semantik gestellt wird. Das ist der erste Schritt, Barrieren zu erschaffen, die nicht nötig wären. Und das nur, um die Optik aufzupolieren.
Du hast Deine Meinung geäußert, ich meine, dass die Nutzbarkeit (Semantik) immer vor der Optik kommt. Wir wollen es dabei belassen und alle ihre eigene Meinung bilden lassen. Ich möchte nur nicht, dass das in einem ellenlangen Thread ausartet :-)
Gruß,
-Efchen
Moin!
Wenn ich mir teilweise die zur Verfügung stehenden Alternativen ansehe
Das Problem ist, dass aufgrund mangelnder Interpretation seitens (eigentlich nur eines) Browsers das Layout über die Semantik gestellt wird. Das ist der erste Schritt, Barrieren zu erschaffen, die nicht nötig wären. Und das nur, um die Optik aufzupolieren.
Welche "Barrieren" denn genau?
Für den überwiegenden Teil an visuellen Surfern stellt "mit Tabelle oder CSS" absolut keinen Unterschied dar.
Für den wichtigen Teil des Maschinenpublikums (Spider etc.) stellt das optische Erscheinungsbild generell kein Problem dar, weil es irrelevant ist. Hier weitergehende Semantik einzubauen wird durch Tabellen ja nicht ausgeschlossen.
Und für die Gruppe der nicht-visuellen menschlichen Surfer stellt eine "optische" Tabelle auch keine Barriere dar, jedenfalls nicht grundsätzlich, denn man kann Tabellen natürlich schlecht oder gut benutzen - und eine gut genutzte Tabelle ist eben eine, die man auch ohne Tabellenfunktionalität noch versteht, weil ihr Inhalt sinnvoll serialisiert wird.
Du hast Deine Meinung geäußert, ich meine, dass die Nutzbarkeit (Semantik) immer vor der Optik kommt.
Ich glaube nicht, dass es möglich ist, Semantik und Optik zu trennen.
Zum einen aus dem theoretischen Ansatz heraus, dass es ja ureigenster Sinn eines (semantisch markierten) Dokuments ist, optisch angezeigt zu werden.
Zum anderen aus dem praktischen Ansatz heraus, dass es sich einfach schlecht "verkauft" oder vom Zusatzaufwand her nicht rechnet, wenn man für einen Kunden auf Teufel-komm-raus die Semantik pusht, und dann hinterher mit der Optik Probleme kriegt.
Das wäre sicherlich weitaus weniger problematisch, wenn nur irgendein uninteressanter 0,5%-Browser beispielsweise mit float Probleme hätte - aber es ist dummerweise der 50-99%-Browser namens IE. Und wenn der eine unakzeptable optische Darstellung liefert, zahlt der Kunde nicht - da kann noch so tolle Semantik in der Seite sein.
Wir wollen es dabei belassen und alle ihre eigene Meinung bilden lassen. Ich möchte nur nicht, dass das in einem ellenlangen Thread ausartet :-)
Das wird es sowieso. Insbesondere, wenn ich jetzt noch den Threadtitel ändere. ;)
Gruß,
-Efchen
- Sven Rautenberg
Welche "Barrieren" denn genau?
Alles, was die Nutzbarkeit beeinträchtigt. Verschachtelte Layout-Tabellen z.B.
Für den überwiegenden Teil an visuellen Surfern stellt "mit Tabelle oder CSS" absolut keinen Unterschied dar.
Seit wann interessiert nur "der überwiegende Teil"? Und was ist mit den nicht-visuellen Nutzern? Die sind vernachlässigbar, ja? Das nennt sich Diskriminierung.
Und wenn Du glaubst, für normal Sehende mit visuellen Browsern stellt Tabelle oder CSS keinen Unterschied dar, dann hast Du nicht Ladezeit berücksichtigt, Caching, Übersic htlichkeit für den Autor, Austauschbarkeit von Designs, Wartungsfähigkeit der Site und und und. Da ist auch für "den überwiegenden Teil" sehr wohl ein Unterschied.
Für den wichtigen Teil des Maschinenpublikums (Spider etc.) stellt das optische Erscheinungsbild generell kein Problem dar, weil es irrelevant ist. Hier weitergehende Semantik einzubauen wird durch Tabellen ja nicht ausgeschlossen.
Layout-Tabellen (und nur von solchen spreche ich, da Tabellen für tabellarische Daten ja richtig sind) sind falsche Semantik. Das ist einfach Quatsch. Gut, einfache Tabellen stören auch oft genug Vorlesebrowser nicht, und auch Suchmaschinen nicht. Aber Du kochst doch Kirschenmarmelade auch nicht mit Gurken statt Kirschen.
Tabellen zum Layout zu verwenden war ein Hack aus Zeiten ohne CSS. Heute freuen sich die Leute drauf, wenn sie auf CSS-Hacks für den IE verzichten können, wenn IE7 kommt. Warum freut sich keiner, auf den Tabellen-Layout-Hack zu verzichten, jetzt wo er nicht mehr nötig ist?
Und für die Gruppe der nicht-visuellen menschlichen Surfer stellt eine "optische" Tabelle auch keine Barriere dar
Natürlich nicht, denn das optische wird vom Vorlesebrowser ja ignoriert. Ein mit <table> ausgezeichneter Inhalt ist aber keine "optische Tabelle", sondern eine strukturelle Tabelle. Und die kann zu Barrieren führen.
jedenfalls nicht grundsätzlich, denn man kann Tabellen natürlich schlecht oder gut benutzen
Jaja, und man kann auch mit nem Traktor auf der Autobahn fahren.
Inhalt, der keine tabellarischen Daten darstellt, aber als Tabelle ausgezeichnet ist, ist falsch ausgezeichnet. Das ist so. Zugegeben hindert Dich niemand daran, es falsch zu machen, und trotzdem eine Tabelle zu nehmen.
und eine gut genutzte Tabelle ist eben eine, die man auch ohne Tabellenfunktionalität noch versteht, weil ihr Inhalt sinnvoll serialisiert wird.
Wie bitte?
Entweder man hat eine Tabelle, oder man hat keine.
Ich glaube nicht, dass es möglich ist, Semantik und Optik zu trennen.
Doch. Denn das ist ja gerade der Grundsatz von CSS-Layouts: Trennung von Inhalt und Layout.
Du hast recht, wenn Du sagen willst, dass die Struktur durch das Layout beeinflusst wird. Aber die Struktur kann auch ohne die Optik auskommen. Das ist ja ein entscheidender Vorteil von CSS-Layouts, die 100%ige Nutzbarkeit in allen CLients (was bei Tabellenlayouts ja nicht geht).
Zum einen aus dem theoretischen Ansatz heraus, dass es ja ureigenster Sinn eines (semantisch markierten) Dokuments ist, optisch angezeigt zu werden.
Nicht im Web. Suchmaschinen, Textbrowser, Vorlesebrowser sind ein gutes Beispiel dagegen.
Nur, weil die optische Darstellung eine Variante ist (vielleicht sogar die häufigste), ist sie nicht die einzige. Und alle Möglichkeiten sollte man berücksichtigen.
Zum anderen aus dem praktischen Ansatz heraus, dass es sich einfach schlecht "verkauft" oder vom Zusatzaufwand her nicht rechnet, wenn man für einen Kunden auf Teufel-komm-raus die Semantik pusht, und dann hinterher mit der Optik Probleme kriegt.
In Einzelfällen wird man abwägen.
Aber die Semantik zugunsten der Optik zu vernachlässigen kann bei der Nutzbarkeit ins Auge gehen. Umgekehrt nicht so sehr. Nutzer haben mehr von einer nicht so schön aussehenden, aber voll nutzbaren Website, als eine die toll aussieht, aber nicht nutzbar ist.
Das wäre sicherlich weitaus weniger problematisch, wenn nur irgendein uninteressanter 0,5%-Browser beispielsweise mit float Probleme hätte - aber es ist dummerweise der 50-99%-Browser namens IE. Und wenn der eine unakzeptable optische Darstellung liefert, zahlt der Kunde nicht - da kann noch so tolle Semantik in der Seite sein.
Die Einschätzung halte ich vor völlig überzogen.
Wir wollen es dabei belassen und alle ihre eigene Meinung bilden lassen. Ich möchte nur nicht, dass das in einem ellenlangen Thread ausartet :-)
Das wird es sowieso. Insbesondere, wenn ich jetzt noch den Threadtitel ändere. ;)
Als ob den jemand liest ;-)
Hallo Efchen,
Ich glaube nicht, dass es möglich ist, Semantik und Optik zu trennen.
Doch. Denn das ist ja gerade der Grundsatz von CSS-Layouts: Trennung von Inhalt und Layout.
Ist ja in der Theorie alles gut und schön, aber wie stellst du es denn z.B. an, dass Tabellenzellen im meistbenutzen Browser mit einem Abstand von 10 Pixeln dargestellt werden? Da nimmst du das Attribut "cellspacing" und knallst es in den HTML-Code, obwohl das nur der Optik dient, denn die CSS-Eigenschaft border-spacing versteht dieser Browser nicht.
Gruß Gernot
Ist ja in der Theorie alles gut und schön, aber wie stellst du es denn z.B. an, dass Tabellenzellen im meistbenutzen Browser mit einem Abstand von 10 Pixeln dargestellt werden?
padding?
Da nimmst du das Attribut "cellspacing" und knallst es in den HTML-Code
Hab ich seit Jahren nicht mehr benutzt :-)
denn die CSS-Eigenschaft border-spacing versteht dieser Browser nicht.
Wenn das nur ein Browser ist, der das nicht versteht, dann ist das halb so wild. Dann kriegt der Browser halt kleinere Abstände. Das tut einem guten WWW-Design/Layout keinen ab.