nicht angemeldet
Struppi
Struppi
molily
Struppi
Hallo Selfer, heute mal ein bisschen anders. ;)
Es wird ja nun hier auf SELFHTML, SELFHTML Forum und auch in vielen anderen Foren und vielen anderen Seiten "gepredigt", statt Tabellen lieber Divisionen einzusetzen (oder andere Elemente, je nach Einsatzzweck) und diese mit CSS wie gewünscht zu formatieren.
Dabei entstehen Probleme. Entwickler wünschen sich, dass zwei Elemente gleich lang sind, also in der Höhe immer gleich groß sind, was meist bei dreispaltigen Layouts zum Einsatz kommen soll.
Weiterhin wird sich gewünscht, dass der Footer auch dann ganz am Ende gezeigt wird, wenn der Inhalt und die restlichen Elemente nicht bis zum Ende des Dokuments reichen.
Die Antwort lautet (leider) immernoch: es ist nicht möglich!
"Doch!" werden nun sicherliche einige von euch rufen und es stimmt. Es _ist_ möglich. Aber zu welchem Preis?
Wenn man - um einen Footer am Boden eines Dokuments zu platzieren - zusätzliche (sinnfreie, nur zur Formatierung vorhandene) Elemente (z.B. Divisionen) braucht, u.a. einen großen Container und ein "gecleartes" Element, wo bleiben dann die Vorteile? Die Semantik geht kaputt. Es existieren plötzlich Elemente, die gar nicht gewünscht sind. Elemente, die nur dank einer unvollständigen Technik vorhanden sind und die gar nicht in die Gedankenwelt eines Entwicklers passen. Warum dann nicht eine Tabelle einsetzen?
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Eine andere Möglichkeit, sind optische Effekte (faux columns). Aber wir müssen bedenken: warum wollten wir nochmal von den Tabellen weg? Achja, die Semankik. Aber wo bleibt die, wenn sich die Elemente gar nicht so verhalten, wie wir wollen sondern nur so aussehen? Das tun die Tabellen doch auch. Und sie tun es besser!
Nun kann man darüber streiten, ob es "schlimmer" ist, eine Tabelle zur Formatierung einzusetzen oder etliche sinnfreie überflüssige Divisionen in Quelltext zu haben, die letztendlich auch nur der Formatierung dienen, obwohl wir genau _das_ verhindern wollten.
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen. Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Ich freue mich auf eure Meinungen und besonders auf stark abweichende Meinungen!
Eure (Die_)Antwort
[latex]Mae govannen![/latex]
CSS ist definitiv kein Allheilmittel. Es ist teilweise nicht zuende gedacht und unnötig verkompliziert worden, teilweise wurde Einiges wieder aus dem Standard genommen, weil Browser das (noch) nicht unterstützt hatten und vieles mehr. Diese Entscheidungen sind zum Teil unübersichtlich und chaotisch. Das ist einfach so.
Außerdem ist CSS leider durch die Unfähigkeit des IE (insbesondere <=6) nur zu einem Bruchteil ausnutzbar und da man auf IE6 wohl noch einige Jahre Rücksicht zu nehmen hat, würde selbst ein neuer, durchdachter Standard, so er schon zementiert feststehen würde, die Probleme nicht lösen.
Dennoch ist CSS in fast allen Fällen dennoch die bessere Wahl. Was nutzt mir eine zig-fach verschachtelte Tabellenkonstruktion, die den Quellcode unverhältnismäßig aufbläht (Ladezeit), nur extrem schwer wartbar ist ,für die die Browser länger fürs rendern brauchen und bei der der ganze Seiten-Aufbau unflexibel in der Tabelle festgegossen ist.
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Du hast ein Layout mit Header, Navigation links, Inhalt rechts daneben (Also Standardlayout). Nun möchtest du aber irgendwann den Header und die Navi oben nebeneinander und den Inhalt in voller Breite darunter. Mit CSS in wenigen Minuten geändert, mit Tabellen eine Quälerei.
Cü,
Kai
[latex]Mae govannen![/latex]
Außerdem ist CSS leider durch die Unfähigkeit des IE (insbesondere <=6) nur zu einem Bruchteil ausnutzbar und da man auf IE6 wohl noch einige Jahre Rücksicht zu nehmen hat, würde selbst ein neuer, durchdachter Standard, so er schon zementiert feststehen würde, die Probleme nicht lösen.
Er würde aber die Probleme der momentan nicht möglichen Semantik lösen. Klar, für ältere Browser muss man sich immernoch einiger Hacks bemühen (wenn man das denn möchte), aber am besten ist eine Sprache, bei der ich schreibe, wie ich denke.
Dennoch ist CSS in fast allen Fällen dennoch die bessere Wahl. Was nutzt mir eine zig-fach verschachtelte Tabellenkonstruktion,
Davon war gar nicht die Rede. Lediglich um spezifische Probleme (wie die von mir genannten) zu lösen oder vor allem ältere Browser zu berücksichtigen, sollten einzelne Tabellen verwendet werden. Wenn sie sich vermeiden lassen, sollte man sie auch vermeiden.
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Du hast ein Layout mit Header, Navigation links, Inhalt rechts daneben (Also Standardlayout).
Sieht so aus:~~~html
<table>
<tr>
<td colspan="2">header</td>
</tr>
<tr>
<td>navi</td>
<td>inhalt</td>
</tr>
</table>
> Nun möchtest du aber irgendwann den Header und die Navi oben nebeneinander und den Inhalt in voller Breite darunter. Mit CSS in wenigen Minuten geändert, mit Tabellen eine Quälerei.
Sieht dann so aus:~~~html
<table>
<tr>
<td>header</td>
</tr>
<tr>
<td>navi</td>
</tr>
<tr>
<td>inhalt</td>
</tr>
</table>
Ist das eine Quälerei? Ich finde nicht. Das schwerste ist es in diesem Fall wohl, die Inhalte zu kopieren, mehr nicht. Danach formatiert man die Liste in der Menü-Zelle neu und dann ist gut, mehr braucht man nicht zu machen.
Ok du hast recht, mit CSS geht's einfacher. Aber nur in diesem Fall. In den bei mir oben genannten Fällen, bekommst du da ziemliche Probleme.
Sieht so aus:~~~html
<table>
<tr>
<td colspan="2">header</td>
</tr>
<tr>
<td>navi</td>
<td>inhalt</td>
</tr>
</table>
~~~html
<h1>header</h1>
<ul style="float:left;"><li>navi</li></ul>
<p>inhalt</p>
Sieht dann so aus:~~~html
<table>
<tr>
<td>header</td>
</tr>
<tr>
<td>navi</td>
</tr>
<tr>
<td>inhalt</td>
</tr>
</table>
~~~html
h1 { float: left; width: 33%; }
Viele Grüße,
Stefan
[latex]Mae govannen![/latex]
Ist das eine Quälerei? Ich finde nicht. Das schwerste ist es in diesem Fall wohl, die Inhalte zu kopieren, mehr nicht. Danach formatiert man die Liste in der Menü-Zelle neu und dann ist gut, mehr braucht man nicht zu machen.
Du hast aber nur ein leeres Grundgerüst beschrieben, ich rede von praxisbezogenen Tabellenlayouts. Und was ist dann mit den ganzen Attributen wie Tabellen/Zeilen/Zellen-Breiten/Höhen, colspan, rowspan, Rahmen etc, die nicht mehr zum geändeten Layout pasen und alle angepasst werden müssen? Nein, mit Inhalt umkopieren ist es wohl fast nie getan.
Cü,
Kai
[latex]Mae govannen![/latex]
Ist das eine Quälerei? Ich finde nicht. Das schwerste ist es in diesem Fall wohl, die Inhalte zu kopieren, mehr nicht. Danach formatiert man die Liste in der Menü-Zelle neu und dann ist gut, mehr braucht man nicht zu machen.
Du hast aber nur ein leeres Grundgerüst beschrieben, ich rede von praxisbezogenen Tabellenlayouts. Und was ist dann mit den ganzen Attributen wie Tabellen/Zeilen/Zellen-Breiten/Höhen, colspan, rowspan, Rahmen etc, die nicht mehr zum geändeten Layout pasen und alle angepasst werden müssen?
Nun, die müssen mittels eines zentral definierten CSS natürlich auch geändert werden. Aber wenn du Divisionen einsetzt, ist das nicht anders.
Hi,
Du hast aber nur ein leeres Grundgerüst beschrieben, ich rede von praxisbezogenen Tabellenlayouts. Und was ist dann mit den ganzen Attributen wie Tabellen/Zeilen/Zellen-Breiten/Höhen, colspan, rowspan, Rahmen etc, die nicht mehr zum geändeten Layout pasen und alle angepasst werden müssen?
Nun, die müssen mittels eines zentral definierten CSS natürlich auch geändert werden. Aber wenn du Divisionen einsetzt, ist das nicht anders.
Wenn dein HTML-Code sinnvoll aufgebaut ist, beschraenkt sich die Aenderung aber auf genau *einen* Ort - das CSS, fuer alle betroffenen Dokumente.
Musst du am HTML herumfuhrwerken, hast du auch *alle* Dokumente anzupassen.
MfG ChrisB
Hallo,
nenne uns doch mal Beispiele von Layouts, die sich mit CSS nicht bzw. nur
mit unvertretbar hohem Aufwand realisieren lassen.
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 ... ;-)
Viele Grüße,
Stefan
PS: Nimm es nicht persönlich, aber Deine Argumentation zeugt nur von sehr
bedingtem Fachwissen zum Thema CSS. Natürlich sehe ich ein, dass da
jeder mal angefangen hat, aber was Du hier (anonym) vom Stapel lässt,
ist ein ganz alter Hut. Diese Diskussion kannst Du nicht gewinnen.
Vielleicht ergänzend noch folgender Link: http://www.csszengarden.com/
Ja, die Website ist an sich eine Spielerei oder sagen wir mal, sie dient nur
dazu, die Leistungsfähigkeit von CSS zu präsentieren. Natürlich werden viele
der Layouts in veralteten Browsern nicht so schön ausschauen, aber dies ist
auch nicht die Intention der Website. Einfach mal im aktuellen Firefox oder
einen CSS-technisch vergleichbaren Browser hinsurfen und staunen. Wir reden
dort von _einer_ HTML-Variante, es wird lediglich das CSS-File gewechselt.
Viele Grüße,
Stefan
hi Stefan,
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 ... ;-)
Vielleicht sind die verantwortlichen ja auch SELF´er. :)
Grüße aus H im R an Stefan,
Primus Enginus
Hallo,
nenne uns doch mal Beispiele von Layouts, die sich mit CSS nicht bzw. nur
mit unvertretbar hohem Aufwand realisieren lassen.
Nun gut. Mal als Beispiel folgendes Layout:
1. Ein Header (so breit wie der Viewport)
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.
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.
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.
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.
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.
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.
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.ä..
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. 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.
Mit Tabellen _und_ Divisionen wäre das ganze etwas schneller und Browserfreundlicher gelöst. Nachteile hat das aber natürlich auch.
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?
PS: Nimm es nicht persönlich, aber Deine Argumentation zeugt nur von sehr
bedingtem Fachwissen zum Thema CSS. Natürlich sehe ich ein, dass da
jeder mal angefangen hat, aber was Du hier (anonym) vom Stapel lässt,
ist ein ganz alter Hut. Diese Diskussion kannst Du nicht gewinnen.
Mach dir keine Sorgen, ich nehme das nicht persönlich. Ich selbst schätze mich in Bezug auf CSS und Positionierung eigentlich eher auf sehr fortgeschritten ein. Ich möchte auch keine Diskussion gewinnen (_das_ kann man hier sowieso nicht ;D) sondern mit anderen Meinungen und Erfahrungen austauschen. Das Diskutieren ist nur ein Teil davon.
Hallo,
Der Effekt soll wirklich erzielt werden. Es soll nicht nur so _aussehen_ als wären zwei Spalten gleich groß o.ä..
Und warum? Was ist der praktische Unterschied zwischen »sieht nur so aus« und »ist wirklich so«? Durch das Einschließen von floats sind umgebende Container »wirklich« so groß, lediglich bei »Faux Columns« und ähnlichem muss das nicht so sein.
Ich gebe zu, das ist etwas heftig und wird in der Realität wohl eher selten auftauchen.
Ja. Ich wüsste auch nicht, wie man all diese Anforderungen mit Tabellen lösen könnte.
Ich weiß auch nicht, welche Erkenntnis damit gewonnen ist, utopische Layouts im Kopf zu konstruieren, um damit zu zeigen, dass sie nicht umsetzbar sind. Toll. Entweder es ist eine realistische Anforderung, dann muss ich sie so umsetzen, wie es möglich ist. Andernfalls lohnt es sich nicht, darüber zu diskutieren.
Dennoch treten die einzelnen Teilprobleme öfters auf und können nicht einfach gelöst werden.
Das müsste man wieder im Einzelnen anschauen.
Mathias
Hallo,
Der Effekt soll wirklich erzielt werden. Es soll nicht nur so _aussehen_ als wären zwei Spalten gleich groß o.ä..
Und warum? Was ist der praktische Unterschied zwischen »sieht nur so aus« und »ist wirklich so«? Durch das Einschließen von floats sind umgebende Container »wirklich« so groß, lediglich bei »Faux Columns« und ähnlichem muss das nicht so sein.
Weil ich z.B. eine Grafik verwenden möchte, die bei Faux Coulumns eben _nicht_ funktioniert. Wenn die Container mittels float wirklich so groß sind, ist das ja erwünscht. Ich wollte nur faux columns vorbeugen, das ist eben wieder nur eine Hilfslösung.
Vereinfacht: es dürfen nur Hintergrundfarben definiert werden und jede Spalte darf und muss ausschließlich eine eigene Hintergrundfarbe besitzen. So kann man am besten sehen, ob das Ziel erreicht ist oder nicht.
Ich gebe zu, das ist etwas heftig und wird in der Realität wohl eher selten auftauchen.
Ja. Ich wüsste auch nicht, wie man all diese Anforderungen mit Tabellen lösen könnte.
Ich weiß auch nicht, welche Erkenntnis damit gewonnen ist, utopische Layouts im Kopf zu konstruieren, um damit zu zeigen, dass sie nicht umsetzbar sind. Toll. Entweder es ist eine realistische Anforderung, dann muss ich sie so umsetzen, wie es möglich ist. Andernfalls lohnt es sich nicht, darüber zu diskutieren.
Es lohnt sich, weil ich damit viele kleinere Probleme von CSS aufzeigen möchte, die hier eben nur Teilprobleme darstellen. Und je komplexer das Layout, desto mehr Hacks sind nötig und desto unsemantischer wird es.
So ein Layout wie hier, könnte durchaus Realität sein. Wenn auch eher selten, aber Seltenheit sollte kein Argument sein. Und utopisch ist das ganze sicher nicht.
Hallo,
jede Spalte darf und muss ausschließlich eine eigene Hintergrundfarbe besitzen
Das ist mir CSS möglich, meinen Artikel habe ich ja bereits verlinkt.
weil ich damit viele kleinere Probleme von CSS aufzeigen möchte, die hier eben nur Teilprobleme darstellen.
Dann zeige sie doch mal auf.
Mathias
Hallo,
jede Spalte darf und muss ausschließlich eine eigene Hintergrundfarbe besitzen
Das ist mir CSS möglich, meinen Artikel habe ich ja bereits verlinkt.
Das habe ich auch nicht bezweifelt ;)
weil ich damit viele kleinere Probleme von CSS aufzeigen möchte, die hier eben nur Teilprobleme darstellen.
Dann zeige sie doch mal auf.
Habe ich durch meine ausformulierte Aufgabenstellung und in meinem Ursprungsposting bereits getan und ich habe keine Lust mich zu wiederholen.
Hallo,
Habe ich durch meine ausformulierte Aufgabenstellung und in meinem Ursprungsposting bereits getan
Du hast ein Layout mit bestimmten Anforderungen beschrieben. Ich sehe da mit einigen offensichtlichen Ausnahmen nicht auf Anhieb, was daran genau nicht mit CSS möglich sein soll bzw. was große Umwege erfordert. Ich würde mir wünschen, dass solche Fragen so diskutiert werden, wie alle CSS-Supportfragen hier: »Ich habe versucht, dass in CSS umzusetzen, und komme an den und den Stellen nicht weiter, weil das und das nicht mit CSS möglich ist bzw. nur der und der Workaround existiert.« Andernfalls komme ich da nicht mit und ich glaube sonst auch niemand außer den Diskutanten.
Mathias
Hallo,
Ich weiß auch nicht, welche Erkenntnis damit gewonnen ist, utopische Layouts im Kopf zu konstruieren, um damit zu zeigen, dass sie nicht umsetzbar sind. Toll. Entweder es ist eine realistische Anforderung, dann muss ich sie so umsetzen, wie es möglich ist. Andernfalls lohnt es sich nicht, darüber zu diskutieren.
Es lohnt sich, weil ich damit viele kleinere Probleme von CSS aufzeigen möchte, die hier eben nur Teilprobleme darstellen.
Niemand behauptet, dass heutzutage wirklich alle real existierenden Anforderungen mittels CSS realisiert werden können. Und das in der Praxis noch weitere Probleme hinzukommen, die aber nicht von der CSS-Seite herrühren, bestreitet auch niemand.
Das ist aber weder ein Grund, noch irgendein Argument dafür, stattdessen Tabellen für Layoutzwecke zu missbrauchen.
Und je komplexer das Layout, desto mehr Hacks sind nötig und desto unsemantischer wird es.
Also erstens scheinst du eine falsche Vorstellung von dem Begriff "Semantik" zu haben (sieh mein erstes Posting), und zweitens gehst du die Sache doch schon von der falschen Seite aus an.
Grundsätzlich ist eine Webseite erstmal eine rein lineare Seite - das ergibt sich aus dem Quelltext. Nun bieten diverse Medien die Möglichkeit, die Inhalte durch ein entsprechendes Layout auch anders anzuordnen. Dies sollte immer in erster Linie der leichteren & besseren Aufnahme/ Auffassung der Inhalte durch den Betrachter dienen.
Ich kann mir in der Praxis nur sehr schwer konkrete Inhalte vorstellen, die bei der Präsentation in einem von dir geschilderten Layout, diese Kriterien erfüllen würden. Siehe u.a.: Form follows function
So ein Layout wie hier, könnte durchaus Realität sein.
Genauso gut könnte dann auch ein anderes Layout sinnvoller sein.
Gruß Gunther
Hallo,
nenne uns doch mal Beispiele von Layouts, die sich mit CSS nicht bzw. nur
mit unvertretbar hohem Aufwand realisieren lassen.Nun gut. Mal als Beispiel folgendes Layout:
verlinke bitte das Layout mal, wo Du es mit Tabellen umgesetzt hast. Im
Moment kann ich mir nur schwer vorstellen, wie es letztendlich aussehen
soll. Und wenn ich es recht verstehe, dann willst Du fünf Spalten neben-
einander setzen?! Ist bei kleineren Browserfenstern ziemlich sportlich,
aber meinetwegen.
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?
Also wenn ich mir ard.de, bahn.de, dresden.de, mtv.de, playboy.de, post.de,
spiegel.de, web.de usw. (...) jetzt mal anschaue, dann gibt es da einige
Website mit Layouts, die ich jetzt mal als durchaus komplex bezeichnen
will. Da sind viele verschiedene Elemente, zum Teil auch dynamische In-
halte, auf jeden Fall dürfte Deine erste Vermutung damit entkräftet sein.
Und beim zweiten Punkt liegst Du da jetzt komplett falsch. Ohne es probiert
zu haben, aber ich bin mir sicher, dass die obengenannten Websites bei
annähernd 99% der Besucher nahezu identisch gut im Browser aussehen.
Und dann bin ich mir auch sicher, dass auch das restliche fehlende 1%
die Websites benutzen kann, mit welchem Client auch immer sie darauf
zugreifen. Hier kommt das Stichwort BITV, informiere Dich mal dazu.
Dies ist ein wichtiger Grund, warum gerade öffentliche Behörden und
Einrichtungen ein barrierefreies Layout für Ihre Website benötigen. Und
barrierefrei ist ein Stapel Tabellen ganz bestimmt nicht.
Viele Grüße,
Stefan
Hallo,
nenne uns doch mal Beispiele von Layouts, die sich mit CSS nicht bzw. nur
mit unvertretbar hohem Aufwand realisieren lassen.Nun gut. Mal als Beispiel folgendes Layout:
verlinke bitte das Layout mal, wo Du es mit Tabellen umgesetzt hast. Im
Moment kann ich mir nur schwer vorstellen, wie es letztendlich aussehen
soll. Und wenn ich es recht verstehe, dann willst Du fünf Spalten neben-
einander setzen?! Ist bei kleineren Browserfenstern ziemlich sportlich,
aber meinetwegen.
Dieses Layout habe ich mir spontan ausgedacht und selbst noch nicht erstellt. Ich werde das aber tun, damit ihr es euch besser vorstellen könnt, aber ja, du hast es völlig richtig verstanden, es sollen fünf Spalten nebeneinander sein.
Hallo,
Dieses Layout habe ich mir spontan ausgedacht und selbst noch nicht erstellt. Ich werde das aber tun, damit ihr es euch besser vorstellen könnt, aber ja, du hast es völlig richtig verstanden, es sollen fünf Spalten nebeneinander sein.
na ja, zwar keine fünf, aber schon mal vier Spalten gibt's hier*.
Und wenn du schon mal auf der Seite bist, guckst du dir auch gleich mal die anderen Beispiel-Layouts an, und überlegst dir, wie du das mit Layout-Tabellen umsetzen würdest.
Gruß Gunther
* Es geht nicht darum, ob und wie sinnvoll solche Layouts in der Praxis sind, sondern rein um die Möglichkeit(en).
Hi there,
na ja, zwar keine fünf, aber schon mal vier Spalten gibt's hier*.
ja, fein, und hast Du Dir den Source angesehen? Das ist ja genau das, was der Originalposter geschrieben hat, einfach 4 divs nebeneinander, und? Solange es keine Tags für Spalten gibt, ist es völlig egal, ob man dazu eine Tabelle oder einfach mehrere divs nimmt...
Hallo,
ja, fein, und hast Du Dir den Source angesehen? Das ist ja genau das, was der Originalposter geschrieben hat, einfach 4 divs nebeneinander, und? Solange es keine Tags für Spalten gibt, ist es völlig egal, ob man dazu eine Tabelle oder einfach mehrere divs nimmt...
Du hast anscheinend immernoch nicht den grundliegenden Unterschied verstanden um den es hier geht. Tabellen zerstören die innewohnende Struktur der Information. div-Elemente tun dies nicht.
Glücklicherweise wirds auch nie Elemente für die Spaltenerzeugung geben, denn das ist ein rein Gestalterisches Problem.
Gruß
Hi there,
Du hast anscheinend immernoch nicht den grundliegenden Unterschied verstanden um den es hier geht. Tabellen zerstören die innewohnende Struktur der Information. div-Elemente tun dies nicht.
Ich verstehe den Ansatz sehr wohl, auch wenn ich der Interpretation wenig Glauben schenke. Denn um Glaubensfragen scheint es hier eher zu gehen als um das Lösen von gestalterischen Problemen. Deine Aussage, daß Tabellen eine der Information innewohnende Struktur zerstören ist komplett sinnfrei und klingt für mich eher nach Dogma denn nach einer Analyse einer von mehreren möglichen Designoptionen.
Ich rede hier absolut nicht dem Tabellenlayout das Wort, aber wer in <td>Information</td> grundsätzlich anderes sieht als in <div>Information</div>, der lügt sich selbst in den Designersack. Beides dient der Separation von einem Teil der sich auf der Seite befindlichen Information, die natürlich kein innewohnende Struktur aufweist, diese erhält sie ja erst durch den Kontext, in dem sie dargestellt wird. Was ich natürlich einräume ist, daß diese Struktur durch Darstellung in Tabellenzellen wesentlich rigider und eingeschränkter ist als durch alternative Darstellungsvarianten. Aber der Originalposter hat ja auch von Spezialfällen geschrieben, in denen er Tabellen zu Designzwecken missbrauchen möchte.
Glücklicherweise wirds auch nie Elemente für die Spaltenerzeugung geben, denn das ist ein rein Gestalterisches Problem.
Absolut d'accord...
[latex]Mae govannen![/latex]
Ich rede hier absolut nicht dem Tabellenlayout das Wort, aber wer in <td>Information</td> grundsätzlich anderes sieht als in <div>Information</div>, der lügt sich selbst in den Designersack. Beides dient der Separation von einem Teil der sich auf der Seite befindlichen Information, die natürlich kein innewohnende Struktur aufweist, diese erhält sie ja erst durch den Kontext, in dem sie dargestellt wird.
<td> bedeutet _immer_ „hier folgen tabellarische Daten, die in einer bestimmten Beziehung zu anderen Tabellenzeilen stehen“. Dies ist die Definition einer Tabelle. Und bei Tabellenlayout folgen dann in der Realiät eben nicht immer tabellarische Daten und/oder eine Beziehung zu den anderen Zellen. Genau darin liegt der sematische Mißbrauch. Ein <div> hingegen bedeutet _gar nichts_, der Inhalt kann beliebiger Art sein.
Cü,
Kai
Hi there,
<td> bedeutet _immer_ „hier folgen tabellarische Daten, die in einer bestimmten Beziehung zu anderen Tabellenzeilen stehen“. Dies ist die Definition einer Tabelle. Und bei Tabellenlayout folgen dann in der Realiät eben nicht immer tabellarische Daten und/oder eine Beziehung zu den anderen Zellen. Genau darin liegt der sematische Mißbrauch. Ein <div> hingegen bedeutet _gar nichts_, der Inhalt kann beliebiger Art sein.
was Du nicht sagst. Was Du sagst, ist natürlich zu hundert Prozent korrekt und hat mit dem von mir Gesagten doch so gut wie gar nichts zu tun. Ich habe auf den Aspekt des Separierens von Inhalten verwiesen und erzählst mir wie eine Tabelle definiert ist. Ich gebs auf...
Hallo,
was Du nicht sagst. Was Du sagst, ist natürlich zu hundert Prozent korrekt und hat mit dem von mir Gesagten doch so gut wie gar nichts zu tun. Ich habe auf den Aspekt des Separierens von Inhalten verwiesen und erzählst mir wie eine Tabelle definiert ist. Ich gebs auf...
Wieso auch nicht? Wie willst du etwas trennen, indem du eine Verbindung herstellst?
Gruß
Hallo,
Ich rede hier absolut nicht dem Tabellenlayout das Wort, aber wer in <td>Information</td> grundsätzlich anderes sieht als in <div>Information</div>, der lügt sich selbst in den Designersack.
Wochentag 1. Stunde 2. Stunde 3. Stunde
Montag Mathe Deutsch Geschichte
Dienstag Sport Sport Chemie
Obiges Beispiel _muß_ mittels TABLE-Element (inkl. TR, TH, TD; sinnvoller-
weise noch THEAD, TBODY und ggf. TFOOT) gruppiert werden. Wer sowas mittels
DIVs macht, hat den Sinn nicht verstanden. Die Aussage, dass es sich bei TD
und DIV nicht grundsätzlich um etwas anderes handelt, ist eindeutig falsch.
Dann können wir auch gleich H1-H6, UL, LI .... u.v.m. einsparen, nehmen wir
einfach immer DIV und formatieren es uns mittels CSS entsprechend ?!
***
Aus meiner Sicht ist gutes HTML, wenn der Quelltext möglichst nah an dem Um-
fang bleibt, der notwendig ist, um die inhaltliche Struktur festzustellen,
zusätzliche Elemente und Attribute sollten nur soweit wie nötig existent sein.
Viele Grüße,
Stefan
Hi,
Ich rede hier absolut nicht dem Tabellenlayout das Wort, aber wer in <td>Information</td> grundsätzlich anderes sieht als in <div>Information</div>, der lügt sich selbst in den Designersack.
Wochentag 1. Stunde 2. Stunde 3. Stunde
Montag Mathe Deutsch Geschichte
Dienstag Sport Sport ChemieObiges Beispiel _muß_ mittels TABLE-Element (inkl. TR, TH, TD; sinnvoller-
weise noch THEAD, TBODY und ggf. TFOOT) gruppiert werden.
Logisch, andernfalls gingen die logischen Zusammenhaenge, in denen die einzelnen Daten stehen, hopps.
Wer sowas mittels DIVs macht, hat den Sinn nicht verstanden.
D'accord.
Die Aussage, dass es sich bei TD und DIV nicht grundsätzlich um etwas anderes handelt, ist eindeutig falsch.
Ja, aber darum ging's bei der Argumentation ja auch weniger.
In Frage steht weniger die Richtung tabellarische Daten (Table) -> Div, sondern die umgekehrte: Nicht-tabellarische Daten in Tabelle "verpackt" - und wie "schaedlich" oder eben auch nicht das im Sinne der Nutzbarkeit unter unterschiedlichen Bedingungen ist/waere.
Aus meiner Sicht ist gutes HTML, wenn der Quelltext möglichst nah an dem Umfang bleibt, der notwendig ist, um die inhaltliche Struktur festzustellen,
zusätzliche Elemente und Attribute sollten nur soweit wie nötig existent sein.
Und eben da kommt die Argumentation ins Spiel, haue ich mir jetzt lieber einige sinn- und aussagefreie Elemente in den Code, um bspw. einfach nur zwei optisch "gleich lange" Spalten zu realisieren - oder nehm' ich die Tabelle mit nur einer "Zeile" und zwei Spalten, und kann dafuer auf obskure Workarounds und Hacks verzichten ...?
Mal ehrlich, "faux columns" *sind* doch was perverses - und auch gar nicht immer realisierbar, weil andere Gruende gegen den Einsatz von Hintergrundfarben-/bildern sprechen koennen, oder damit nicht die erwuenschte Flexibilitaet erreicht wird, Stichwort Nicht-Skalierbarkeit von Hintergrundbildern.
Betrachten wir das ganze mal aus Screenreader-Sicht: Mit der "CSS-Variante" hab ich zwei Containerelemente im Quelltext stehen, deren Inhalte nacheinander vorgelesen wuerden - und mit der Tabelle? Genau das gleiche in gruen, zwei simple TDs, deren Inhalte nacheinander vorgetragen werden.
*Darum* geht's doch hier in erster Linie, moechte ich meinen - und *nicht* darum, was davon zu halten ist, wenn jemand zum Layouten Tabellen ueber ein Dutzend Ebenen verschachtelt ...
MfG ChrisB
Hallo,
Betrachten wir das ganze mal aus Screenreader-Sicht: Mit der "CSS-Variante" hab ich zwei Containerelemente im Quelltext stehen, deren Inhalte nacheinander vorgelesen wuerden - und mit der Tabelle? Genau das gleiche in gruen, zwei simple TDs, deren Inhalte nacheinander vorgetragen werden.
Das ist überhaupt nicht das gleiche. Der Screenreader verkauft mir die Tabelle als Tabelle, was verwirrt, wenn es sich bloß um eine Layouttabelle handelt. Div-Elemente werden hingegen nicht kommuniziert.
Screenreader lesen doch nicht einfach die Texte stumpf und unterschiedslos vor, sondern sind ein Interface zum Dokument, zur HTML-Auszeichnung. Tabellen werden da natürlich, je nach Modus, wiedergegeben und ich kann in ihnen auf spezielle Weise navigieren.
Dann gibts eine automatische Erkennung von Layouttabellen, damit Irritationen möglichst vermieden werden. Aber ich würde mich darauf nicht verlassen, das ist natürlich bloße Heuristik und als Black Box implementiert.
Mathias
Hi,
Betrachten wir das ganze mal aus Screenreader-Sicht: Mit der "CSS-Variante" hab ich zwei Containerelemente im Quelltext stehen, deren Inhalte nacheinander vorgelesen wuerden - und mit der Tabelle? Genau das gleiche in gruen, zwei simple TDs, deren Inhalte nacheinander vorgetragen werden.
Das ist überhaupt nicht das gleiche. Der Screenreader verkauft mir die Tabelle als Tabelle, was verwirrt, wenn es sich bloß um eine Layouttabelle handelt. Div-Elemente werden hingegen nicht kommuniziert.
"Verkaufen" bedeutet konkret?
Ich rede hier nicht von einer komplexeren, ggf. sogar verschachtelten, Tabelle(n), sondern von einer Zeile [1] mit zwei Spalten, um "faux columns" vermeiden zu koennen.
Das soll im Screenreader wirklich problematisch sein ...?
[1] Ggf. wuerde ich auch noch eine zweite Zeile (THEAD) spendieren, um Navigation und Inhaltsbereich mit entsprechenden Spaltenueberschriften zu versehen.
MfG ChrisB
Hi,
Ich rede hier nicht von einer komplexeren, ggf. sogar verschachtelten, Tabelle(n), sondern von einer Zeile [1] mit zwei Spalten, um "faux columns" vermeiden zu koennen.
Das soll im Screenreader wirklich problematisch sein ...?
Screenreader werden in erster Linie von welcher Usergruppe verwendet? Genau - von Blinden. Und diese können nicht erkennen, ob eine Tabelle eine reine Layouttabelle ist und wieviel Zeilen und Spalten sie hat.
Imho ist es keine Frage bis zu wievielen Zeilen und Spalten man eine Tabelle als Layouttabelle verwenden kann oder nicht. Die einzige Antwort muss lauten: Gar nicht!
Gruß Gunther
Hi,
Screenreader werden in erster Linie von welcher Usergruppe verwendet? Genau - von Blinden. Und diese können nicht erkennen, ob eine Tabelle eine reine Layouttabelle ist und wieviel Zeilen und Spalten sie hat.
Meine Frage bzw. die Unklarheit war lediglich, wie es sich im Screenreader ueberhaupt aeussert, *dass* es sich um eine Tabelle handelt - aber das hat Mathias ja gerade geklaert.
MfG ChrisB
Hallo,
"Verkaufen" bedeutet konkret?
JAWS liest meiner Erinnerung nach »Tabelle mit drei Zeilen und drei Spalten« (o.ä.) vor, dann kann man durch die linearisierten Inhalte stapfen oder in den Tabellenmodus wechseln.
Das soll im Screenreader wirklich problematisch sein ...?
Zumindest irritierend.
[1] Ggf. wuerde ich auch noch eine zweite Zeile (THEAD) spendieren, um Navigation und Inhaltsbereich mit entsprechenden Spaltenueberschriften zu versehen.
Layouttabelle bleibt Layouttabelle, bitte nicht Semantik reinbringen, wo keine ist und auf summary, caption, thead, tfoot, th und allen andere Infos zur Verknüpfung (headers, scope) verzichten. Sonst wird sie im Screenreader mit noch größerer Sicherheit als Datentabelle verkauft. Dabei sollte es bleiben:
<table><tr><td>
<h2 id="nav">Navigation</h2>
</td><td>
<h2 id="cont">Hauptinhalt</h2>
</td><td>
<h2 id="side">Unwichtiger Seitenkram</h2>
</td></tr></table>
Mathias
Hi there,
Obiges Beispiel _muß_ mittels TABLE-Element (inkl. TR, TH, TD; sinnvoller-
weise noch THEAD, TBODY und ggf. TFOOT) gruppiert werden. Wer sowas mittels
DIVs macht, hat den Sinn nicht verstanden.
Kein Einwand meinerseits. Nur gehst Du vom Umkehrschluss aus, vielleicht von mir schlecht formuliert, aber das war nicht beabsichtigt. Ich habe nicht vorgeschlagen, zum Formatieren oder Darstellen tabellarischer Daten Elemente wie <div> zu verwenden. Ich denke einmal, das hast Du beim Lesen meines Postings auch durchschaut...
Kein Einwand meinerseits. Nur gehst Du vom Umkehrschluss aus, vielleicht von mir schlecht formuliert, aber das war nicht beabsichtigt. Ich habe nicht vorgeschlagen, zum Formatieren oder Darstellen tabellarischer Daten Elemente wie <div> zu verwenden. Ich denke einmal, das hast Du beim Lesen meines Postings auch durchschaut...
Ob man tabellarische Daten mit <div> oder nicht-tabellarische Daten mit <table> (und entsprechend <tr>, <td>, etc.) strukturiert, kommt aufs Gleiche raus - die Verwendung von Elementen, wie sie nicht gedacht ist. Das ist das, was du offenbar noch nicht durchschaut hast.
Hi there,
Ob man tabellarische Daten mit <div> oder nicht-tabellarische Daten mit <table> (und entsprechend <tr>, <td>, etc.) strukturiert, kommt aufs Gleiche raus - die Verwendung von Elementen, wie sie nicht gedacht ist.
Wirklich? Es geht in dem ganzen thread darum, festzustellen, ob es in bestimmten Situationen nicht einfacher sein kann, eine Tabelle zu verwenden anstelle einer anderen, zum Beispiel mit <div>s realisierten Konstruktion. Niemand, aber auch wirklich niemand, hat hier heute (und vermutlich auch früher nie) jemals vorgeschlagen, für tabellarische Daten irgendwelche Div-Konstruktionen zu verwenden. Aber ich räume ein, daß es bequemer ist, sich einfach empört blöd zu stellen als einer Argumentation zu folgen, auch wenn sie aus einer etwas anderen Meinung resultiert.
Das ist das, was du offenbar noch nicht durchschaut hast.
Reg Dich nicht auf, morgen darf ich eh nicht mehr solange aufbleiben, weil ich Dienstag wieder in die Schule muss, kann nicht jeder so gescheit sein wie der grosse Timo "God's Boss" Reitz...
Ob man tabellarische Daten mit <div> oder nicht-tabellarische Daten mit <table> (und entsprechend <tr>, <td>, etc.) strukturiert, kommt aufs Gleiche raus - die Verwendung von Elementen, wie sie nicht gedacht ist.
Wirklich? Es geht in dem ganzen thread darum, festzustellen, ob es in bestimmten Situationen nicht einfacher sein kann, eine Tabelle zu verwenden anstelle einer anderen, zum Beispiel mit <div>s realisierten Konstruktion.
Abstraktion ist hier wohl das Zauberwort, ich habe diese zwar explizit dazugeschrieben, aber es kann nicht jeder so gescheit sein wie ich. Nochmal ausführlicher, extra für dich: Das Stecken von nichttabellarischen Daten in eine Tabelle ist der Missbrauch (oder auch fehlerhafte Verwendung) von Elementen. Das ist die Abstraktion. Jetzt verstanden?
Um den gleichen Fall handelt es sich bei dem Verwenden von <div>s für tabellarische Daten, von <blockquote> bei Nichtzitaten (um z.B. eine Einrückung zu erzielen), etc.
Niemand, aber auch wirklich niemand, hat hier heute (und vermutlich auch früher nie) jemals vorgeschlagen, für tabellarische Daten irgendwelche Div-Konstruktionen zu verwenden. Aber ich räume ein, daß es bequemer ist, sich einfach empört blöd zu stellen als einer Argumentation zu folgen, auch wenn sie aus einer etwas anderen Meinung resultiert.
Es ist aber völlig egal, weil es aus den gleichen Gründen falsch ist.
Hi there,
na ja, zwar keine fünf, aber schon mal vier Spalten gibt's hier*.
ja, fein, und hast Du Dir den Source angesehen? Das ist ja genau das, was der Originalposter geschrieben hat, einfach 4 divs nebeneinander, und? Solange es keine Tags für Spalten gibt, ist es völlig egal, ob man dazu eine Tabelle oder einfach mehrere divs nimmt...
Es gibt Elemente für Spalten, aber für Spalten, die zur inhaltlichen Struktur gehören (und demzufolge innerhalb von Tabellen verwenden werden). Hat man Spalten auf einer Seite, ist die Entscheidung zwischen Tabelle und anderen Elementen (müssen nicht immer divs sein) in der Regel leicht: Bei tabellarischen Daten nimmt man eine Tabelle, bei nichttabellarischen Daten andere Elemente, hierbei gibt es wiederum den Sonderfall, dass kein anderes Element direkt passt, dann wird auf div ausgewichen, weil es *laut Standard* eine Möglichkeit zur generischen Strukturierung ist. Tabellen sind das übrigens ausdrücklich nicht.
Hi,
* Es geht nicht darum, ob und wie sinnvoll solche Layouts in der Praxis sind
Doch, auch, moechte ich meinen.
Es mag zwar sein, dass man mit Tabellen ganz einfach ein halbes Dutzend oder mehr Spalten nebeneinander geklatscht bekommt - und mit CSS vielleicht auch - aber ob das auch *sinnvoll* und nutzbar ist, waere eine ganz andere Frage.
Ich verweise mal auf Rolands Weblog-Beitrag Tabellen, Spalten und Weblogs vs. Hypertext - seiner Argumentation, dass es gar nicht so sinnvoll sein muss, den Betrachter mit haufenweise Informationen in zig Spalten zuzuballern, schliesse ich mich weitgehend an.
Da stecken also erst mal Ueberlegungen bzgl. des Layouts (und noch fundamentaler, der Informationsgliederung/-unterteilung in *Dokument*strukturen) hinter, die noch weit vor der technischen Umsetzung stehen.
Und wenn man da erst mal die noetige Simplifizierung vorgenommen hat, dann wird das ganze auch mit CSS leichter und sinnvoller umsetzbar, als wenn man sich vielleicht daran klammert, zig Spalten nebeneinander klatschen zu wollen.
Der Weg "von Tabellen zu CSS" erfordert m.E. schon ein Umdenken *vor* dem Prozess der Realisierung/Umsetzung - und beinhaltet u.a. erst mal ein Wegkommen vom "Denken in Tabellen".
Letzteres schraenkt mich persoenlich fuer meinen Geschmack in meinen Layoutmoeglichkeiten mehr ein, als dass es mir hilft.
MfG ChrisB
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.
- Ein Header (so breit wie der Viewport)
Das dürfte vermutlich die leichteste der Übungen sein. :)
Fünf Spalten:
- 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.
- 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?
- 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.
- 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.
- 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.
- 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
Moin!
Hallo. Es tut gut mal eine nicht-so-agressiv-emotionale Antwort zu hören ;)
Hast du bewusst su ruhig geschrieben?
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.
- Ein Header (so breit wie der Viewport)
Das dürfte vermutlich die leichteste der Übungen sein. :)
Vermutlich ;)
Fünf Spalten:
- 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"?
So ist es.
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.
- 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?
restlich bedeutet, dass zuerst alle Spalten ihre Platz bekommen und der Rest für diese Spalte übrig bleibt. (im Quelltext wäre dann die Reihenfolge wichtig, hier habe ich sie vernachlässigt)
- 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?
Weiß ich nicht. Vielleicht verkauft der Webmaster Villen und möchte ähnliche Angebote aufzeigen.
Und auch hier wieder Kritik an der Formulierung: Wenn die beiden Spalten gleich breit sind, dann gibt es keine breitere von beiden.
Ja, blöde Formulierung, aber du hast es zum Glück verstanden.
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.
- 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.
Wenn ich keine expliziten Aussagen treffe, kann man davon ausgehen, dass eine feste oder vom Inhalt abhängige Höhe freigestellt ist.
- 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.
Siehe oben. kann rechts gefloatet und 200px hoch sein oder zentriert sein und sich in der Höhe nach dem Inhalt richten.
- 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?
Ich habe nur versucht auf die schnelle ein Beispiel zu konstruieren, was die Problematik der verikalen Zentrierung von Blockelementen in CSS aufzeigen sollte.
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.
Doch, ich denke schon. Nur nicht in vertretbarem Aufwand. :)
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.
Doch doch. Man liest diese Fragen hier doch öfters. Manchmal bekommt man auch Quelltextausschnitte, die mehrere Teilprobleme in einer Datei deutlich machen und meist mit verzweifelten Usern, die hier um Hilfe bitten. ;)
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.
Das ist für mich aber keine Lösung. Man sollte schreiben wie man denkt. Wenn man dabei ständig an das Layout usw. denken muss... naja.
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?
Natürlich nicht.
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. :)
Ich wusste gar nicht, dass es Villen mit *so* großen Pools gibt, dass man darin surfen kann?!
Grüße,
Die_Antwort
Moin!
Arbeiten wir mal Details heraus. Und Widersprüche deiner Layout-Forderungen.
Zunächst mal die vertikale Ausdehnung.
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. Ebenso ist nicht definiert, wie sich denn diese Spalte verhält, wenn sie mehr Inhalt darstellen muß, als alle 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".
Ebenso muß Spalte 5 sinnlos breit gemacht werden, nur weil Spalte 3 inhaltsbedingt sehr breit ist. Für ein vernünftiges Layout sicher nicht sinnvoll.
Spalte 4 kann komplett auf 0 zusammenschrumpfen, wenn sie keinen Inhalt hat.
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?
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.
Und zur Untermalung meiner Argumentation von "Es kommt auf den Sinnzusammenhang an":
- 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?
Weiß ich nicht. Vielleicht verkauft der Webmaster Villen und möchte ähnliche Angebote aufzeigen.
Die Frage ist, ob diese "Zusatzinformationen" sich konkret auf den Inhalt der Spalte 2 beziehen und deshalb auf Höhe des zugeordneten Textabsatzes erscheinen müssen, oder ob es sich um vollkommen unabhängigen Content handelt, der einfach "irgendwo" in der Spalte erscheinen soll.
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.
Bleibt dir also nur, beide Spalten (3 und 5 - was ist mit 4) wahlweise prozentual oder pixelmäßig in der Breite zu definieren. Dann kriegst du aber keine Veränderung von beiden Spalten, wenn in einer Spalte der Inhalt mal breiter wird. Abgesehen davon war deine Forderung, dass die Spalten nur so breit werden sollen, wie ihr Inhalt.
Ich denke, du hast hier den Zonk gezogen. :)
- 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?
Ich habe nur versucht auf die schnelle ein Beispiel zu konstruieren, was die Problematik der verikalen Zentrierung von Blockelementen in CSS aufzeigen sollte.
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?
Man kann mit CSS auch vertikal zentrieren. Dort, wo es sinnvoll ist. Und man weiß, wie. margin:auto tut es allerdings nicht, da das für width und height unterschiedlich gehandhabt wird (auto für margin-top und -bottom wird immer zu 0, jedoch für margin-left und -right wirkt es zentrierend, sofern die restlichen Breitenangaben dies zulassen).
Die Frage ist aber (siehe meinen Realitätscheck), ob vertikales Zentrieren notwendig ist.
Wenn ja, würde ich tatsächlich eine Tabelle mit einer einzelnen Tabellenzelle verwenden. Meine Praxiserfahrung sagt aber: Sowas wird nie passieren. Allein schon deshalb, weil nie garantiert werden kann, dass eine Webseite eine bestimmte Länge hat und NIE länger werden kann. Oder findest du spontan irgendwo auf einer beliebigen Webseite ein vertikal zentriertes Element - und außerdem noch weiteren sinnvoll angeordneten Content beliebiger Länge?
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.
Doch, ich denke schon. Nur nicht in vertretbarem Aufwand. :)
Da es extrem unterspezifiziert ist (vgl. meine Anmerkung zu Höhen ganz oben), dürfte es ein Leichtes sein, alle deine Forderungen zu erfüllen (egal ob mit Tabellen oder ohne) - aber es wird kein sinnvolles oder sinnvoll nutzbares Layout dabei herauskommen.
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.
Das ist für mich aber keine Lösung. Man sollte schreiben wie man denkt. Wenn man dabei ständig an das Layout usw. denken muss... naja.
Niemand, der sich um das optische Erscheinungsbild seines Schriftwerkes Gedanken macht, schreibt so, wie er denkt.
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. Sowohl in der Länge (wenn der Artikel in drei Spalten passen muß, ist es weder akzeptabel, dass der Artikel zu kurz, noch dass er zu lang ist - er wird solange umgeschrieben, bis er paßt), als auch in der Formulierung (automatische oder manuelle Silbentrennung im Satzprogramm bei extrem langen Worten - wenn insgesamt kein gutes Schriftbild herauskommt, weil der Zeilenumbruch unschön ist, werden auch Satzteile, Sätze oder ganze Absätze umgestellt oder neu formuliert, bis es paßt).
Druckwerke haben zum Glück den Vorteil, dass sie unabhängig vom Anzeigeprogramm überall identisch aussehen. Insofern ist die Darstellung im Browser einerseits ein Fluch (es gibt keinerlei Verläßlichkeit in der Darstellung und keine wirkliche Eingriffsmöglichkeit für Optimierungen), andererseits aber auch ein Segen (es gibt keine künstlichen Längenbeschränkungen oder Formulierungszwänge, solange man ein gewisses Maß an Normalität nicht überschreitet).
- Sven Rautenberg
Hallo,
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.
Nebenbei auch nur in Firefox bis einschließlich Version 2. Für Version 3 wurde diese Implementierung entfernt, weil sie wohl gar nicht den HTML-Regeln entsprach.
Gruß
Moin!
Arbeiten wir mal Details heraus. Und Widersprüche deiner Layout-Forderungen.
Zunächst mal die vertikale Ausdehnung.
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?
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.
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.
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.
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.
???
<table style=";">
<tr>
<td valign="top" style="background:red;" width="50%">123456789</td>
<td style="background:blue;" width="*">123</td>
</tr>
</table>
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.
- 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?
Ich habe nur versucht auf die schnelle ein Beispiel zu konstruieren, was die Problematik der verikalen Zentrierung von Blockelementen in CSS aufzeigen sollte.
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. =*(
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.
Niemand, der sich um das optische Erscheinungsbild seines Schriftwerkes Gedanken macht, schreibt so, wie er denkt.
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.
Hi,
Man kann mit CSS auch vertikal zentrieren. Dort, wo es sinnvoll ist.
Ja, man braucht 3 Hilfselemente.
Und was brauchst du?
Ergibt nach meiner Zaehlung irgendwie die gleiche Anzahl an "Hilfselementen".
MfG ChrisB
Hi,
Man kann mit CSS auch vertikal zentrieren. Dort, wo es sinnvoll ist.
Ja, man braucht 3 Hilfselemente.
Und was brauchst du?
- TABLE
- TR
- TD
Ergibt nach meiner Zaehlung irgendwie die gleiche Anzahl an "Hilfselementen".
Es sind bessere Hilfselemente. Zumindest meiner Ansicht nach. Die div-Elemente (oder Divisionen, wie ich sie nenne) verwirren nur. Ein vorlesendes Programm würde sagen:
"Und jetzt kommt: nix"
"Und jetzt kommt: nix"
"Und jetzt kommt: nix"
Punkt.
Bei Tabellen aber, weiß das Programm, dass es nur das vorlesen muss, was im td-Element stehen muss. Daher erscheint es mir besser. Und das wirst du auch nicht ändern können.
Hi,
Und was brauchst du?
- TABLE
- TR
- TD
Ergibt nach meiner Zaehlung irgendwie die gleiche Anzahl an "Hilfselementen".
Es sind bessere Hilfselemente. Zumindest meiner Ansicht nach.
Die reichlich unfundiert zu sein scheint -
Die div-Elemente (oder Divisionen, wie ich sie nenne) verwirren nur. Ein vorlesendes Programm würde sagen:
"Und jetzt kommt: nix"
"Und jetzt kommt: nix"
"Und jetzt kommt: nix"
*Nein*, ein Screenreader wuerde leere, verschachtelte Element *nicht* als
"Und jetzt kommt: nix"
vorlesen.
Punkt.
Zur Bekraeftigung einer absolut falschen Aussage? Komisch.
Bei Tabellen aber, weiß das Programm, dass es nur das vorlesen muss, was im td-Element stehen muss. Daher erscheint es mir besser. Und das wirst du auch nicht ändern können.
Wenn ich dir nicht begreiflich machen kann, dass deine Auffassung absoluter Quark ist, ist das schade.
MfG ChrisB
Hallo,
Ein vorlesendes Programm würde sagen:
"Und jetzt kommt: nix"
"Und jetzt kommt: nix"
"Und jetzt kommt: nix"
Interessant. An welches Vorleseprogramm denkst du da so?
Mathias
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."
Hi,
Das Thema gabs hier schon oft genug. Die zugehörigen Diskussionen
eine Sackgasse. Also soll doch jeder machen wie es ihm beliebt.
Ich persönlich mag vieles an CSS und hasse aber auch vieles daran.
So nutze ich beides je nach Bedarf. Aber um vernünftige variabele
Darstellungen zu bekommen die3 in jedem Browser gleich aussehen ist für mich die Tabelle das das Mittel Nr.1
Alleine schon die oft unlogische Vererbung dann die Blockpositionierung mit
text-align(hä? text-align bei einem Bild oder Absatz?) die extrem unterschiedlichen Ansichten in den jeweiligen Browsern bei Fliesstext, usw
sind Sachen die mich mich bei CSS nerven. Klar da gibts Workarounds, hacks, etc. um am Ende die doch angeblich vereinfachte Darstellunge gegenüber Tabellen hinzu(tricksen)bekommen.
Heinz
Hallo,
Alleine schon die oft unlogische Vererbung dann die Blockpositionierung mit
text-align(hä? text-align bei einem Bild oder Absatz?) die extrem unterschiedlichen Ansichten in den jeweiligen Browsern bei Fliesstext, usw
sind Sachen die mich mich bei CSS nerven.
Welche Vererbungen empfindest du als unlogisch?
Blockpositionierumg mit text-align? Du scheinst etwas sehr falsch zu machen.
Unterschiedliche Ansichten bei Fließtext? Bitte erläutern.
Gruß
Hi,
Alleine schon die oft unlogische Vererbung
Beispiel(e)?
Allein schon der Unfug, dass nicht mal die font-Angaben von gewissen Browsern richtig in Tabellen hinein vererbt werden ...
dann die Blockpositionierung mit text-align(hä? text-align bei einem Bild oder Absatz?)
Auch hae - Block-Elemente werden nicht per text-align ausgerichtet. Text und auch Bilder schon, ja - allgemein halt inline-Elemente - in so fern passt der Eigenschaftenname vielleicht nicht ganz, darf man aber als "historisch gewachsen" betrachten, und allzu grosse Tragik birgt dieser Umstand auch nicht.
die extrem unterschiedlichen Ansichten in den jeweiligen Browsern bei Fliesstext, usw
Wieder: Beispiel(e)?
sind Sachen die mich mich bei CSS nerven. Klar da gibts Workarounds, hacks, etc. um am Ende die doch angeblich vereinfachte Darstellunge gegenüber Tabellen hinzu(tricksen)bekommen.
Lass doch bitte bspw. mal ein links oder rechts ausgerichtetes Bild von Text *umfliessen* - mit deinen Tabellen; ich bin gespannt! (Ohne den Text zu "zerhacken" bitte.)
MfG ChrisB
Hallo,
Beispiel(e)?
Allein schon der Unfug, dass nicht mal die font-Angaben von gewissen Browsern richtig in Tabellen hinein vererbt werden ...
Das ist ein Fehler den die Browser nur im Quirksmode machen. Wenn du die Browser in den standradkonformen Modus versetzt passiert dir das nicht mehr und du kannst mit wesentlich besseren Ergebnissen rechnen. Siehe [Doctype-Switch]
Auch hae - Block-Elemente werden nicht per text-align ausgerichtet. Text und auch Bilder schon, ja - allgemein halt inline-Elemente - in so fern passt der Eigenschaftenname vielleicht nicht ganz, darf man aber als "historisch gewachsen" betrachten, und allzu grosse Tragik birgt dieser Umstand auch nicht.
IE 5.x und IE6+ im Quirksmode zentrieren zwar Blockelemente fälschlicherweise per text-align, arbeitet man jedoch im standardkonformen Modus verwenden IE6 und höher die richtigen Algorithmen zur Zentrierung.
Gruß
Hallo,
Es wird ja nun hier auf SELFHTML, SELFHTML Forum und auch in vielen anderen Foren und vielen anderen Seiten "gepredigt", statt Tabellen lieber Divisionen einzusetzen (oder andere Elemente, je nach Einsatzzweck) und diese mit CSS wie gewünscht zu formatieren.
Es wird nichts gepredigt, der gesunde Menschenverstand gewinnt einfach an Bedeutung. Tabellen fürs Layout zu benutzen ist wie... ein Haus zu bauen um Plakate anbringen zu können.
[...] Entwickler wünschen sich, [...] Weiterhin wird sich gewünscht [...]
Nun ja, Menschen sind Gewohnheitstiere. Und wenn man 3/4 der Zeit, seit es das Web gibt, mit Tabellen gearbeitet hat, fällt es natürlich schwer sich von dieser Spalten-und-Zeilen-Denkweise zu verabscheiden.
Wenn man - um einen Footer am Boden eines Dokuments zu platzieren - zusätzliche (sinnfreie, nur zur Formatierung vorhandene) Elemente (z.B. Divisionen) braucht, u.a. einen großen Container und ein "gecleartes" Element, wo bleiben dann die Vorteile? Die Semantik geht kaputt.
Stimmt, CSS erfordert manchmal Elemente fürs Layout. Diese Elemente sind aber fast immer leer und für den Inhalt bzw. ein simples Ausgabeprogramm ohne Bedeutung.
Warum dann nicht eine Tabelle einsetzen?
Tabellen verändern die Bedeutung des Inhalts. Tabellen sind ein Hindernis, wenn es darum geht nicht-tabellarische Informationen an den Menschen zu übermitteln.
Zudem kann ein simples Ausgabeprogramm den Tabelleninhalt nicht benutzerfreundlich Wiedergeben.
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Geschwindigkeit zeigt sich in der Regel durch die Erfahrung des Autors.
Trennt man nicht Information und Layout? Das kann die Tabelle bei nicht-tabellarischen Informationen nicht.
Eine andere Möglichkeit, sind optische Effekte (faux columns). Aber wir müssen bedenken: warum wollten wir nochmal von den Tabellen weg? Achja, die Semankik. Aber wo bleibt die, wenn sich die Elemente gar nicht so verhalten, wie wir wollen sondern nur so aussehen? Das tun die Tabellen doch auch.
Diesen Punkt verstehe ich nicht ganz. Bitte bedenke: Was aussieht wie eine Tabelle hat nicht die Bedeutung einer Tabelle. Es ist idiotisch, wenn jemand auf eine Tabelle verzichtet, obwohl tabellarische Daten vorhanden sind. Aber vorhandene Informationen als Tabelle zu gestalten ohne die Bedeutung einer Tabelle zu integrieren ist der entscheidende Unterschied in der Art der Gestaltung.
Einfacher: Während <table> nicht für Zwecke des Layouts geeignet ist, eignet sich display:table; umsomehr.
Nun kann man darüber streiten, ob es "schlimmer" ist, eine Tabelle zur Formatierung einzusetzen oder etliche sinnfreie überflüssige Divisionen in Quelltext zu haben, die letztendlich auch nur der Formatierung dienen, obwohl wir genau _das_ verhindern wollten.
Nun, MarkUp-Bestandteile fürs Layout sind anscheinend notwendig. Ich denke allerdings, dass du mit "etliche" übertreibst. Ein paar sind schon notwendig, aber diese haben Vorteile gegenüber Tabellen, z.B. sparen sie mehr Code und beeinflussen nicht die Art und Qualität des Inhalts.
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen. Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Was der Bauer nicht kennt, frisst er nicht? Fällt mir spontan ein.
CSS ist durchaus ein vernünftiges Modell. Nur befinden wir uns leider nicht mehr im letzte Jahrzeht, als die Browser noch innerhalb weniger Monate große Schritte gemacht haben.
Gruß
Hallo,
Es wird ja nun hier auf SELFHTML, SELFHTML Forum und auch in vielen anderen Foren und vielen anderen Seiten "gepredigt", statt Tabellen lieber Divisionen einzusetzen (oder andere Elemente, je nach Einsatzzweck) und diese mit CSS wie gewünscht zu formatieren.
Es wird nichts gepredigt, der gesunde Menschenverstand gewinnt einfach an Bedeutung. Tabellen fürs Layout zu benutzen ist wie... ein Haus zu bauen um Plakate anbringen zu können.
Ja, nimmst du Divisionen, dann brauchst du nicht 3 Plakate sondern 6 und drei davon sind inhaltslos und stehen schräg in der Gegend herum. Ist das wirklich besser?
[...] Entwickler wünschen sich, [...] Weiterhin wird sich gewünscht [...]
Nun ja, Menschen sind Gewohnheitstiere. Und wenn man 3/4 der Zeit, seit es das Web gibt, mit Tabellen gearbeitet hat, fällt es natürlich schwer sich von dieser Spalten-und-Zeilen-Denkweise zu verabscheiden.
Das habe ich bereits getan. Solange ein Layout mittels CSS zu realisieren ist, sollte man das natürlich tun. Ist es aber nicht möglich, sollte man es nicht krampfhaft durch Hacks und zusätzliche Divisionen usw. versuchen. Das war mein Anliegen.
Warum dann nicht eine Tabelle einsetzen?
Tabellen verändern die Bedeutung des Inhalts. Tabellen sind ein Hindernis, wenn es darum geht nicht-tabellarische Informationen an den Menschen zu übermitteln.
Und leere nichts sagende Divisionen nicht?
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Geschwindigkeit zeigt sich in der Regel durch die Erfahrung des Autors.
Ich habe in beidem genug Erfahrungen und kann sagen: in den von mir genannten Fällen geht das Tabellenlayout schneller.
Trennt man nicht Information und Layout? Das kann die Tabelle bei nicht-tabellarischen Informationen nicht.
Ja tut man. Und man fügt nicht zusätzliche sinnfreie und ggf. verwirrende Informationen ein, oder?
Eine andere Möglichkeit, sind optische Effekte (faux columns). Aber wir müssen bedenken: warum wollten wir nochmal von den Tabellen weg? Achja, die Semankik. Aber wo bleibt die, wenn sich die Elemente gar nicht so verhalten, wie wir wollen sondern nur so aussehen? Das tun die Tabellen doch auch.
Einfacher: Während <table> nicht für Zwecke des Layouts geeignet ist, eignet sich display:table; umsomehr.
Ja, würden es >90% der Browser unterstützen... und selbst damit gibt es immernoch Probleme.
Nun kann man darüber streiten, ob es "schlimmer" ist, eine Tabelle zur Formatierung einzusetzen oder etliche sinnfreie überflüssige Divisionen in Quelltext zu haben, die letztendlich auch nur der Formatierung dienen, obwohl wir genau _das_ verhindern wollten.
Nun, MarkUp-Bestandteile fürs Layout sind anscheinend notwendig. Ich denke allerdings, dass du mit "etliche" übertreibst. Ein paar sind schon notwendig, aber diese haben Vorteile gegenüber Tabellen, z.B. sparen sie mehr Code und beeinflussen nicht die Art und Qualität des Inhalts.
Ich persönliche habe es lieber, ein Element zweckzuentfremden, als zusätzlich Elemente hinzuzufügen, bei denen ich mich vielleicht nach einiger Zeit frage: "wozu waren die jetzt nochmal hier?".
Hallo,
Ja, nimmst du Divisionen, dann brauchst du nicht 3 Plakate sondern 6 und drei davon sind inhaltslos und stehen schräg in der Gegend herum. Ist das wirklich besser?
Ich denke du siehst das falsch. CSS erforderd zunächst kein Haus mehr, das spart sehr viel Aufwand. Danach sieh dich in der Welt um: Es hängen teilweise alte und unleserliche Plakate an den Wänden, aber diese Werden vom Betrachter (Browser) ignoriert, wenn er nicht speziell darauf achtet (CSS).
Ist es aber nicht möglich, sollte man es nicht krampfhaft durch Hacks und zusätzliche Divisionen usw. versuchen. Das war mein Anliegen.
Für den großteil der Auftretenden Probleme gibt es Lösungen. Sicher ist CSS hier anders als eine Tabelle, aber bestimmt nicht um so viel schwiriger, dass man es krampfhaft versuchen muss.
Und leere nichts sagende Divisionen nicht?
Eben nicht. Was ist ein leeres Element für einen Browser? Ein Element ohne Bedeutung. Wenn du ein leeres Element mit Hintergrundfarbe versiehst wird es trotzdem nicht angezeigt. Nach diesem Prinzip funktioniert auch der HTML parser. Die tatsache, dass CSS das Element dennoch sichtbar machen kann ist dabei irrelevant.
Ich habe in beidem genug Erfahrungen und kann sagen: in den von mir genannten Fällen geht das Tabellenlayout schneller.
Meine eigene Erfahrung und die einiger Kollegen lässt mich zu einem anderen Schluss kommen. Davon abgesehen ist die Wahl ob CSS oder Tabelle nichts, was man an der Einfachheit der Erstellung entscheiden sollte.
Ja tut man. Und man fügt nicht zusätzliche sinnfreie und ggf. verwirrende Informationen ein, oder?
Verstehe bitte, Tabellen sind die sinnfreiend und verwirrenden Informateionen. Denn: Du erstellst zwischen den Zellen einen Bezug, den es nicht gibt.
Anders verhält es sich, wenn du leere Elemente als Stützen für CSS einbaust. Es gilt zwar, davon so wenige wie möglich zu verwenden (und das wird immer einfacher), aber wenn Sie nötig sind, werden sie als Information ignoriert, weil sie eben gar keine Information enthalten.
Ja, würden es >90% der Browser unterstützen... und selbst damit gibt es immernoch Probleme.
Nein, immer. Davon abgesehen sind wir mit der BRowserunterstützung auf dem besten weg.
Ich kann mir nicht vorstellen, dass display: table mehr Probleme als die notrmale Tabelle verursacht, immerhin erfolgt die Darstellung in modernen Browsern durch dieses CSS modell und nicht mehr durch das HTML Modell.
Ich persönliche habe es lieber, ein Element zweckzuentfremden, als zusätzlich Elemente hinzuzufügen, bei denen ich mich vielleicht nach einiger Zeit frage: "wozu waren die jetzt nochmal hier?".
Dann scheinst du deinen Quelltext falsch zu verwalten. Eine Konstruktion wie <div></div> sieht niemand gerne, <div class="ElementZweck"></div> macht aber durchaus sinn, vor allem sollten HTML und CSS wie in Programmiersprachen kommentiert oder zumindest dokumentiert werden.
Ich benutze lieber ein leeres Element, dass die Information nicht verfälscht (als ewtas ausgibt das es nicht ist), als die Inhalte in Elemente zu pressen, die die tatsächliche Dokumentstruktur einfach nicht wiedergeben.
Gruß
Hallo,
Ja, nimmst du Divisionen, dann brauchst du nicht 3 Plakate sondern 6 und drei davon sind inhaltslos und stehen schräg in der Gegend herum. Ist das wirklich besser?
Ich denke du siehst das falsch. CSS erforderd zunächst kein Haus mehr, das spart sehr viel Aufwand. Danach sieh dich in der Welt um: Es hängen teilweise alte und unleserliche Plakate an den Wänden, aber diese Werden vom Betrachter (Browser) ignoriert, wenn er nicht speziell darauf achtet (CSS).
Ist es aber nicht möglich, sollte man es nicht krampfhaft durch Hacks und zusätzliche Divisionen usw. versuchen. Das war mein Anliegen.
Für den großteil der Auftretenden Probleme gibt es Lösungen. Sicher ist CSS hier anders als eine Tabelle, aber bestimmt nicht um so viel schwiriger, dass man es krampfhaft versuchen muss.
Nun, ich habe ja hier irgendwo ein Beispiel gestellt, dessen Anforderungen ausschließlich mit CSS erfolgen sollen. Du kannst es dir ja mal angucken (ich erwarte gar nicht, dass das wirklich gelöst wird).
Und leere nichts sagende Divisionen nicht?
Eben nicht. Was ist ein leeres Element für einen Browser?
Mir ist egal, was das für den Browser ist. Für _mich_ ist da ein sinnloses Element. Und wenn ich etwas umbauen möchte, dann muss ich wieder in den Quelltext rein, weil ich das Element nicht mehr brauche oder es plötzlich stört?
Ich kann mir nicht vorstellen, dass display: table mehr Probleme als die notrmale Tabelle verursacht, immerhin erfolgt die Darstellung in modernen Browsern durch dieses CSS modell und nicht mehr durch das HTML Modell.
Leider doch.
Ich persönliche habe es lieber, ein Element zweckzuentfremden, als zusätzlich Elemente hinzuzufügen, bei denen ich mich vielleicht nach einiger Zeit frage: "wozu waren die jetzt nochmal hier?".
Dann scheinst du deinen Quelltext falsch zu verwalten. Eine Konstruktion wie
<div></div>sieht niemand gerne,<div class="ElementZweck"></div>macht aber durchaus sinn, vor allem sollten HTML und CSS wie in Programmiersprachen kommentiert oder zumindest dokumentiert werden.
Das tue ich natürlich. Trotzdem muss ich dann zuerstmal die Kommentare lesen, um den Sinn eines Elements zu verstehen. Ich hab es mir angewöhnt _überall_ auch in anderem Code und auch im richtigen Leben, alles so zu bezeichnen, dass ich auf Anhieb sehen kann, wozu es da ist. Zugegeben, das <tr> kann ich nicht bezeichnen, das stimmt. Das CSS aber auch nicht, wenn ich solche Hacks einbaue.
Ansonsten brauche ich normalerweise nicht zu kommentieren. Ich vergebe passende IDs und Klassen, teile meinen CSS Code in bestimmte logische Abschnitte ein (OK, durch Kommentare), aber ich kommentiere selten einzelne Zeilen. Solange ich nicht mit anderen zusammenarbeite ist das auch nicht nötig.
Hallo,
Nun, ich habe ja hier irgendwo ein Beispiel gestellt, dessen Anforderungen ausschließlich mit CSS erfolgen sollen. Du kannst es dir ja mal angucken (ich erwarte gar nicht, dass das wirklich gelöst wird).
Ich habe nur einen kurzen Blick darüber geworfen und ein paar Probleme mit deinen Begrifflichkeiten. Was soll z.B. „immer nur so breit wie der längste Inhalt, welcher dynamisch geändert werden kann.“ bedeuten?
Mach uns doch bitte eine Tabelle (mit Dynamik), die deinen Anforderungen entspricht, dann können auch Leute mit weniger Vorstellungskraft (so wie ich) sich an dieses Vergnügen wagen. ;)
Mir ist egal, was das für den Browser ist. Für _mich_ ist da ein sinnloses Element. Und wenn ich etwas umbauen möchte, dann muss ich wieder in den Quelltext rein, weil ich das Element nicht mehr brauche oder es plötzlich stört?
Ob das Element _dir_ sinnlos erscheint ist komplett irrelevant. Deine subjektive Aufnahmefähigkeit verändert nicht die Art der übertragenen Informationen.
Ist schon wahr, dass Elementstützen für das Layout nichts tolles sind, CSS Designer mögen diese auch nicht. Aber sie haben einfach den Vorteil, dass sie die Informationsstruktur nicht negativ beeinflussen. Das kannst du mit keiner Argumentation widerlegen.
Bei Tabellen musst du auch im Quelltext herumstochern. Das kann je nach Struktur ganz schön kompliziert werden.
Leider doch.
Mir fällt ein, dass HTML Tabellen einige Attribute kennen. Doch sind jene Attribute die für Tabellenlayouts sinnvoll Nutzbar wären nur schlecht oder gar nicht implementiert.
Zudem haben Tabellen Probleme mit Minimal- und Maximal-Breitenangaben. Das macht es schwirig, einen guten Lesefluss zu erzeugen.
Trotzdem muss ich dann zuerstmal die Kommentare lesen, um den Sinn eines Elements zu verstehen. Zugegeben, das <tr> kann ich nicht bezeichnen, das stimmt. Das CSS aber auch nicht, wenn ich solche Hacks einbaue.
Da widerspreche ich dir auch nicht. Ich sage nur dass Unterstützungen für CSS-Layouts weniger Nachteile haben.
Gruß
Hallo,
Nun, ich habe ja hier irgendwo ein Beispiel gestellt, dessen Anforderungen ausschließlich mit CSS erfolgen sollen. Du kannst es dir ja mal angucken (ich erwarte gar nicht, dass das wirklich gelöst wird).
Ich habe nur einen kurzen Blick darüber geworfen und ein paar Probleme mit deinen Begrifflichkeiten. Was soll z.B. „immer nur so breit wie der längste Inhalt, welcher dynamisch geändert werden kann.“ bedeuten?
Ganz einfach: nimm dir eine Division, floate sie rechts und gebe ihr keine Breite. Sie ist ohne Inhalt nicht sichtbar. Wenn aber Inhalt drin ist, ist die Division genauso breit wie das längste Wort (weil selbiges nicht umgebrochen wird).
Mach uns doch bitte eine Tabelle (mit Dynamik), die deinen Anforderungen entspricht, dann können auch Leute mit weniger Vorstellungskraft (so wie ich) sich an dieses Vergnügen wagen. ;)
Gerne, allerdings habe ich im Moment ein wenig zu tun (Ostern und so). Aber ich werde mich darum kümmern (und hoffentlich nicht umsonst).
Mir ist egal, was das für den Browser ist. Für _mich_ ist da ein sinnloses Element. Und wenn ich etwas umbauen möchte, dann muss ich wieder in den Quelltext rein, weil ich das Element nicht mehr brauche oder es plötzlich stört?
Ob das Element _dir_ sinnlos erscheint ist komplett irrelevant. Deine subjektive Aufnahmefähigkeit verändert nicht die Art der übertragenen Informationen.
Aber bei der Entwicklung ist es störend. Zumindest für mich.
Ist schon wahr, dass Elementstützen für das Layout nichts tolles sind, CSS Designer mögen diese auch nicht. Aber sie haben einfach den Vorteil, dass sie die Informationsstruktur nicht negativ beeinflussen. Das kannst du mit keiner Argumentation widerlegen.
Bei Tabellen musst du auch im Quelltext herumstochern. Das kann je nach Struktur ganz schön kompliziert werden.
Eher nicht so kompliziert, weil ich Tabellen nur dann nutze, wenn ich bei CSS weniger Vorteile sehe. Ich selbst habe bis jetzt erst eine einzige (dynamische (PHP & MySQL)) Seite mit Tabellenlayout erzeugt und auch dort nur eine einzige Tabelle verwendet.
CSS und Tabellen schließen sich ja nicht gegenseitig aus, man kann sie wunderbar kombinieren. Tabellen, wenn zwei Spalten immer die gleiche Größe haben sollen und ansonsten CSS. Nur mal als Beispiel.
Leider doch.
Zudem haben Tabellen Probleme mit Minimal- und Maximal-Breitenangaben. Das macht es schwirig, einen guten Lesefluss zu erzeugen.
? Verstehe ich nicht. Da ich so gut wie nie Layouts gestalte, in denen irgendein Bereich in Prozent oder em oder sonstwas angegeben ist (außer selten 100%), verwende ich solche Breitenangaben gar nicht. Solche Angaben sind böse und unflexibel.
Kopier dir mal den Quelltext vom Zen Garden und schreib in einen der Navigationspunkte mal "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" hinein. Der Text geht über die Navigation hinaus. Das ist imho schlecht und sollte wenn möglich vermieden werden. Dafür muss die Navigation ihre Größe ausschließlich dem Inhalt anpassen.
[url:http://forum.de.selfhtml.org/?t=168677&m=1100720@title=Dieser Thread hier] ist ein Beispiel dafür, wie es _nicht_ sein sollte. Hier hat Navigation (nach der ersten Antwort) eine feste Größe. Nagut, nicht fest sondern abhängig von der Schriftgröße, aber ansonsten doch fest. Wird nun ein längerer Listenpunkt hinzugefügt als die Navi lang ist, passt sie sich nicht an sondern der Text "overflowed".
Trotzdem muss ich dann zuerstmal die Kommentare lesen, um den Sinn eines Elements zu verstehen. Zugegeben, das <tr> kann ich nicht bezeichnen, das stimmt. Das CSS aber auch nicht, wenn ich solche Hacks einbaue.
Da widerspreche ich dir auch nicht. Ich sage nur dass Unterstützungen für CSS-Layouts weniger Nachteile haben.
Das stimmt natürlich, aber in manchen Fällen lohnt sich der Aufwand nicht für diese Vorteile.
Hallo,
Ganz einfach: nimm dir eine Division, floate sie rechts und gebe ihr keine Breite. Sie ist ohne Inhalt nicht sichtbar. Wenn aber Inhalt drin ist, ist die Division genauso breit wie das längste Wort (weil selbiges nicht umgebrochen wird).
Das macht die Sache klarer, aber warum rechts fließen lassen, wenn die Spalte links sein soll? Witzig, dass du ein CSS beispiel verwendest ;)
Aber bei der Entwicklung ist es störend. Zumindest für mich.
Das sind Tabellen auch ;)
Eher nicht so kompliziert, weil ich Tabellen nur dann nutze, wenn ich bei CSS weniger Vorteile sehe. Ich selbst habe bis jetzt erst eine einzige (dynamische (PHP & MySQL)) Seite mit Tabellenlayout erzeugt und auch dort nur eine einzige Tabelle verwendet.
Nun, man sollte nicht immer nur nach der Anzahl der Vor- und Nachteile gehen sondern diese auch bewerten. Und den Nachteil der Tabelle, die Inhaltsstruktur zu zerstören, kann kein Vorteil wett machen.
CSS und Tabellen schließen sich ja nicht gegenseitig aus, man kann sie wunderbar kombinieren. Tabellen, wenn zwei Spalten immer die gleiche Größe haben sollen und ansonsten CSS. Nur mal als Beispiel.
Nun, eine Tabelle ist immernoch problematischer als keine Tabelle bzw. Markup-Stützen.
Solche Angaben sind böse und unflexibel.
Wie kommst du darauf? Die Angabe von Maximalbreiten ist durchaus Sinnvoll, um z.B. die Zeilenbreite zu begrenzen. Das ist deshalb sinnvoll, weil Menschen Schwirigkeiten haben einen Text mit langen Zeilen zu lesen. Zudem verschlechtert es allgemein die Wahrnehmung des Inhalts.
Kopier dir mal den Quelltext vom Zen Garden und schreib in einen der Navigationspunkte mal "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" hinein. Der Text geht über die Navigation hinaus. Das ist imho schlecht und sollte wenn möglich vermieden werden. Dafür muss die Navigation ihre Größe ausschließlich dem Inhalt anpassen.
So lange Navigationspunkte müsste aber schon im grundliegenden konzept beachtet werden.
Es stimmt, dass der Zen Garden nicht das beste ist, was es gibt. Das Problem, dass Seiten nicht skalierbar sind ist auch ein bekanntes Problem, hat aber eher damit zu tun, dass diesem Aspekt früher kaum Beachtung geschenkt wurde.
[url:http://forum.de.selfhtml.org/?t=168677&m=1100720@title=Dieser Thread hier] ist ein Beispiel dafür, wie es _nicht_ sein sollte. Hier hat Navigation (nach der ersten Antwort) eine feste Größe. Nagut, nicht fest sondern abhängig von der Schriftgröße, aber ansonsten doch fest. Wird nun ein längerer Listenpunkt hinzugefügt als die Navi lang ist, passt sie sich nicht an sondern der Text "overflowed".
Die angesprochene Lösung ist sicher nicht ideal, da stimme ich zu. Ich muss auch zugeben, Probleme mit Begriffen wie „Größe“ und „Länge“ zu haben. Breite (width) und Höhe (height) sollten die angemessene Terminologie fürs Webdesign sein.
Aber nun gut.
Auf den ersten Blick schein ein tabellarischer Aufbau hier nicht unmöglich zu sein, ich habe gerade aber leider nicht die Mittel dies unwiderlegbar zu beweisen. :(
Das stimmt natürlich, aber in manchen Fällen lohnt sich der Aufwand nicht für diese Vorteile.
Da stimme ich dir nicht zu, scheine dich aber auch nicht überzeugen zu können.
Gruß
Hallo,
Ganz einfach: nimm dir eine Division, floate sie rechts und gebe ihr keine Breite. Sie ist ohne Inhalt nicht sichtbar. Wenn aber Inhalt drin ist, ist die Division genauso breit wie das längste Wort (weil selbiges nicht umgebrochen wird).
Das macht die Sache klarer, aber warum rechts fließen lassen, wenn die Spalte links sein soll? Witzig, dass du ein CSS beispiel verwendest ;)
War ja nur ein Beispiel =((
Eher nicht so kompliziert, weil ich Tabellen nur dann nutze, wenn ich bei CSS weniger Vorteile sehe. Ich selbst habe bis jetzt erst eine einzige (dynamische (PHP & MySQL)) Seite mit Tabellenlayout erzeugt und auch dort nur eine einzige Tabelle verwendet.
Nun, man sollte nicht immer nur nach der Anzahl der Vor- und Nachteile gehen sondern diese auch bewerten. Und den Nachteil der Tabelle, die Inhaltsstruktur zu zerstören, kann kein Vorteil wett machen.
Auch nach der Bewertung überwiegen die Vorteile...
Solche Angaben sind böse und unflexibel.
Wie kommst du darauf? Die Angabe von Maximalbreiten ist durchaus Sinnvoll, um z.B. die Zeilenbreite zu begrenzen. Das ist deshalb sinnvoll, weil Menschen Schwirigkeiten haben einen Text mit langen Zeilen zu lesen. Zudem verschlechtert es allgemein die Wahrnehmung des Inhalts.
Aber nicht für eine Navigation?!
Kopier dir mal den Quelltext vom Zen Garden und schreib in einen der Navigationspunkte mal "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" hinein. Der Text geht über die Navigation hinaus. Das ist imho schlecht und sollte wenn möglich vermieden werden. Dafür muss die Navigation ihre Größe ausschließlich dem Inhalt anpassen.
So lange Navigationspunkte müsste aber schon im grundliegenden konzept beachtet werden.
Nein! Nein, nein, nein, nein, nein!
Genau _das_ ist Aufgabe des Layouts. Ich will mir keine Gedanken darüber machen, ob ein Listenpunkt nun lang genug ist oder nicht. Dann kann ich gleich ein Pixelgenaues Layout entwerfen.
Ich möchte meinen Inhalt schreiben und schreiben und schreiben und den Rest soll gefälligst das Layout übernehmen. Dazu ist es da.
Anderes Beispiel: wie mache ich eine fixe Navigation (float:left; position:fixed) mit wie oben genannter flexibler Breite und einen Content, der rechts daneben liegt? Es geht schlicht und einfach nicht.
Es stimmt, dass der Zen Garden nicht das beste ist, was es gibt. Das Problem, dass Seiten nicht skalierbar sind ist auch ein bekanntes Problem, hat aber eher damit zu tun, dass diesem Aspekt früher kaum Beachtung geschenkt wurde.
Imho haben auf einer Seite em Angaben nichts zu suchen. Die einzige Ausnahmen machen Elemente, die eine fixe Größe haben müssen (z.B. Bilder) weil sie (noch) nicht skalierbar sind.
[url:http://forum.de.selfhtml.org/?t=168677&m=1100720@title=Dieser Thread hier] ist ein Beispiel dafür, wie es _nicht_ sein sollte. Hier hat Navigation (nach der ersten Antwort) eine feste Größe. Nagut, nicht fest sondern abhängig von der Schriftgröße, aber ansonsten doch fest. Wird nun ein längerer Listenpunkt hinzugefügt als die Navi lang ist, passt sie sich nicht an sondern der Text "overflowed".
Die angesprochene Lösung ist sicher nicht ideal, da stimme ich zu. Ich muss auch zugeben, Probleme mit Begriffen wie „Größe“ und „Länge“ zu haben. Breite (width) und Höhe (height) sollten die angemessene Terminologie fürs Webdesign sein.
Finde ich auch, einigen wir uns auf width und height
Das stimmt natürlich, aber in manchen Fällen lohnt sich der Aufwand nicht für diese Vorteile.
Nenn doch mal ein konkretes Beispiel, bei dem die Nachteile der Tabellen für dich überwiegen. (Ein Beispiel wie aus meinen anderen Beiträgen, bitte kein 0815 Layout, welches man mit CSS machen kann)
Hallo Die_Antwort
Kopier dir mal den Quelltext vom Zen Garden und schreib in einen der Navigationspunkte mal "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" hinein. Der Text geht über die Navigation hinaus. Das ist imho schlecht und sollte wenn möglich vermieden werden. Dafür muss die Navigation ihre Größe ausschließlich dem Inhalt anpassen.
So lange Navigationspunkte müsste aber schon im grundliegenden konzept beachtet werden.
Nein! Nein, nein, nein, nein, nein!
Ich stelle mir gerade ein Tabellenlayout vor, welches in einer Spalte viele kurze und einen einzelnen so langen Linktext enthält. Da bleibt in meinem Browserfenster kein Platz für den Inhalt daneben und im Navigationsmenü habe ich gähnende Leere.
Anderes Beispiel: wie mache ich eine fixe Navigation (float:left; position:fixed) mit wie oben genannter flexibler Breite und einen Content, der rechts daneben liegt? Es geht schlicht und einfach nicht.
Und das soll mit Tabellen besser funktionieren?
Sobald ich dem Inhalt positon:fixed gebe, hat seine Größe keinen Einfluss mehr auf die Spaltenbreite.
Was soll mir dabei die Tabelle helfen?
Imho haben auf einer Seite em Angaben nichts zu suchen. Die einzige Ausnahmen machen Elemente, die eine fixe Größe haben müssen (z.B. Bilder) weil sie (noch) nicht skalierbar sind.
Was dann?
Ausschließlich px-Angaben oder ausschließlich %-Angaben oder überhaupt keine Angaben?
Auf Wiederlesen
Detlef
Hallo,
Aber nicht für eine Navigation?!
Nun, der Vorteil liegt darin, dass CSS Layouts fließend (ich spreche jtzt nicht von floats per se) gestaltet werden können, d.h. während die Tabelle den Inhalt zusammenstaucht bis ins Unlesbare kann man mit CSS Inhalte so festlegen, dass sie sich flexibel anordnen.
Nein! Nein, nein, nein, nein, nein!
Die Summe ergibt mathemathisch ein „Ja“ ;)
Ich möchte meinen Inhalt schreiben und schreiben und schreiben und den Rest soll gefälligst das Layout übernehmen. Dazu ist es da.
Stimmt schon, ich habe mich falsch ausgedrückt. Sieh es zusammen mit der Erklärung oben :)
Anderes Beispiel: wie mache ich eine fixe Navigation (float:left; position:fixed) mit wie oben genannter flexibler Breite und einen Content, der rechts daneben liegt? Es geht schlicht und einfach nicht.
Das geht aber auch mit einer Tabelle nicht.
Imho haben auf einer Seite em Angaben nichts zu suchen. Die einzige Ausnahmen machen Elemente, die eine fixe Größe haben müssen (z.B. Bilder) weil sie (noch) nicht skalierbar sind.
Gerade um die Skalierfähigkeit einer Seite zu verbessern sind em-Angaben notwendig. Zeilenbreiten sind beispielsweise ein wichtiger Faktr der Usability einer Seite.
Aber vielleicht habe ich dich auch nur ganz verkehrt verstanden.
Das stimmt natürlich, aber in manchen Fällen lohnt sich der Aufwand nicht für diese Vorteile.
Nenn doch mal ein konkretes Beispiel, bei dem die Nachteile der Tabellen für dich überwiegen. (Ein Beispiel wie aus meinen anderen Beiträgen, bitte kein 0815 Layout, welches man mit CSS machen kann)
Du hast, glaube ich, übersehen, dass du dich gerade selbst zitiert hast ;)
Gruß
Hi,
So lange Navigationspunkte müsste aber schon im grundliegenden konzept beachtet werden.
Abgesehen davon, dass so lange zusammenhaengende Woerter auch wieder einen extremen Sonderfall darstellen -
Nein! Nein, nein, nein, nein, nein!
Genau _das_ ist Aufgabe des Layouts.
Bloedsinn, Unfug, ...
Es kann und darf nicht "Aufgabe des Layouts" sein, fuer *sinnvolle* Inhalte zu sorgen.
Wenn das Layout zuerst kommt, und danach erst die Inhalte - dann machst du ganz sicher etwas falsch (oder du hast eigentlich keine Inhalte, willst aber mal eine "toll aussehende" Webseite basteln).
Anderes Beispiel: wie mache ich eine fixe Navigation (float:left; position:fixed) mit wie oben genannter flexibler Breite und einen Content, der rechts daneben liegt? Es geht schlicht und einfach nicht.
Abgesehen davon, dass float mit einer solchen Position-Angabe auch wieder Bloedsinn ist - wie machst du denn die Fixierung mit deiner Tabelle? Bin gespannt ... kommen jetzt auch noch (I)Frames mit ins Boot?
Imho haben auf einer Seite em Angaben nichts zu suchen. Die einzige Ausnahmen machen Elemente, die eine fixe Größe haben müssen (z.B. Bilder) weil sie (noch) nicht skalierbar sind.
Nochmal Aua.
Dir scheint in Bezug darauf wirklich nicht klar zu sein, wovon du redest.
Nenn doch mal ein konkretes Beispiel, bei dem die Nachteile der Tabellen für dich überwiegen. (Ein Beispiel wie aus meinen anderen Beiträgen, bitte kein 0815 Layout, welches man mit CSS machen kann)
Tabellenlayouts sind 08/15.
CSS erlaubt mir erst die Flexibilitaet und Kreativitaet, die ich mir wuensche.
MfG ChrisB
Hi,
So lange Navigationspunkte müsste aber schon im grundliegenden konzept beachtet werden.
Abgesehen davon, dass so lange zusammenhaengende Woerter auch wieder einen extremen Sonderfall darstellen -
Ich möchte kein Layout haben, was nur in manchen Fällen funktioniert.
Nein! Nein, nein, nein, nein, nein!
Genau _das_ ist Aufgabe des Layouts.Bloedsinn, Unfug, ...
Es kann und darf nicht "Aufgabe des Layouts" sein, fuer *sinnvolle* Inhalte zu sorgen.
Soll sich das Design an meine Inhalte anpassen oder meine Inhalte an das Design? Eher ersteres oder nicht? Und: wer sagt, dass eine lange Aneinanderreihung von Buchstaben nicht sinnvoll sein muss?
Wenn das Layout zuerst kommt, und danach erst die Inhalte - dann machst du ganz sicher etwas falsch (oder du hast eigentlich keine Inhalte, willst aber mal eine "toll aussehende" Webseite basteln).
Sag das allen CMS Benutzern.
Anderes Beispiel: wie mache ich eine fixe Navigation (float:left; position:fixed) mit wie oben genannter flexibler Breite und einen Content, der rechts daneben liegt? Es geht schlicht und einfach nicht.
Abgesehen davon, dass float mit einer solchen Position-Angabe auch wieder Bloedsinn ist - wie machst du denn die Fixierung mit deiner Tabelle? Bin gespannt ... kommen jetzt auch noch (I)Frames mit ins Boot?
Dazu habe ich bereits in einem anderen Post geantwortet. Das ist auch mit Tabellen nicht möglich. Dazu müsste dann Javascript her. Und was hat das jetzt mit iframes zu tun?
Imho haben auf einer Seite em Angaben nichts zu suchen. Die einzige Ausnahmen machen Elemente, die eine fixe Größe haben müssen (z.B. Bilder) weil sie (noch) nicht skalierbar sind.
Nochmal Aua.
Dir scheint in Bezug darauf wirklich nicht klar zu sein, wovon du redest.
Vielleicht gilt das nur für dich? Nenn mir einen Fall, in dem eine fixe Größe notwendig ist.
Hi,
Abgesehen davon, dass so lange zusammenhaengende Woerter auch wieder einen extremen Sonderfall darstellen -
Ich möchte kein Layout haben, was nur in manchen Fällen funktioniert.
Du argumentierst mit ganz bestimmten Sonderfaellen *fuer* den EInsatz von Tabellen - also duerfen solche Sonderfaelle auch in der Gegenargumentation verwendet werden, so du an einer fairen Diskussion interessiert bist.
Es kann und darf nicht "Aufgabe des Layouts" sein, fuer *sinnvolle* Inhalte zu sorgen.
Soll sich das Design an meine Inhalte anpassen oder meine Inhalte an das Design? Eher ersteres oder nicht?
*Eher* ersteres ja.
Aber im Rahmen des technisch und optisch sinnvollen.
Und: wer sagt, dass eine lange Aneinanderreihung von Buchstaben nicht sinnvoll sein muss?
Niemand.
Aber dann gibt es durchaus Faelle, wo man ebenfalls sagen kann, dass deren Unterbringung in einer "Spalte" weniger sinnvoll sein duerfte.
Auf den Einwand, dass bei deinem Tabellenkonstrukt damit eine ewig breite Navigationsspalte herauskaeme, und der eigentliche Inhalt rechts daneben erst durch Scrolling zu erreichen waere, gehst du natuerlich wieder nicht ein - weil du dir fuer deine Argumentation immer nur die Aspekte herauspickst, die in dein Meinungsbild passen, und alle gegenteiligen geflissentlich ignorierst.
Dazu habe ich bereits in einem anderen Post geantwortet. Das ist auch mit Tabellen nicht möglich.
Warum bringst du es dann ueberhaupt erst als vermeitnliches Argument>
Und was hat das jetzt mit iframes zu tun?
Ganz einfach: Ich will dich *immer noch* die fixe Positionierung innerhalb deines Tabellenlayouts umsetzen sehen.
Imho haben auf einer Seite em Angaben nichts zu suchen.
Dir scheint in Bezug darauf wirklich nicht klar zu sein, wovon du redest.Vielleicht gilt das nur für dich? Nenn mir einen Fall, in dem eine fixe Größe notwendig ist.
Nenne du mir bitte den Fall, in dem "em" *fix* ist.
em *ausgerechnet* fuer die Angabe von Bildmaszen ins Feld zu fuehren, ist dann noch mal wieder gesteigerter Bloedsinn deinerseits.
MfG ChrisB
Hi,
Abgesehen davon, dass so lange zusammenhaengende Woerter auch wieder einen extremen Sonderfall darstellen -
Ich möchte kein Layout haben, was nur in manchen Fällen funktioniert.
Du argumentierst mit ganz bestimmten Sonderfaellen *fuer* den EInsatz von Tabellen - also duerfen solche Sonderfaelle auch in der Gegenargumentation verwendet werden, so du an einer fairen Diskussion interessiert bist.
Nein dürfen sie nicht. Das ist eine ganz andere Ebene. Ich gehe außerdem nicht von Sonderfällen aus (es ist das falsche Wort) sondern von selten geäußerten Wünschen. Nun nehme ich mir einen solchen Wunsch und versuche ihn zu verwirklichen. (1. Ebene)
Dann kann es bei der Verwirklichung wiederum inhaltliche Sonderfälle geben (2. Ebene), die gibt's aber auch bei CSS.
Es kann und darf nicht "Aufgabe des Layouts" sein, fuer *sinnvolle* Inhalte zu sorgen.
Soll sich das Design an meine Inhalte anpassen oder meine Inhalte an das Design? Eher ersteres oder nicht?
*Eher* ersteres ja.
Aber im Rahmen des technisch und optisch sinnvollen.
Ja und mir ist der Rahmen zu eng. Mit Tabellen kann ich ihn für einen gewissen Preis erweitern.
Und: wer sagt, dass eine lange Aneinanderreihung von Buchstaben nicht sinnvoll sein muss?
Niemand.
Aber dann gibt es durchaus Faelle, wo man ebenfalls sagen kann, dass deren Unterbringung in einer "Spalte" weniger sinnvoll sein duerfte.Auf den Einwand, dass bei deinem Tabellenkonstrukt damit eine ewig breite Navigationsspalte herauskaeme, und der eigentliche Inhalt rechts daneben erst durch Scrolling zu erreichen waere, gehst du natuerlich wieder nicht ein - weil du dir fuer deine Argumentation immer nur die Aspekte herauspickst, die in dein Meinungsbild passen, und alle gegenteiligen geflissentlich ignorierst.
Doch in einem anderen Post. Aber ich wiederhole es nochmal gerne für dich: Das ist natürlich schlecht. Mann kann es durch eine maximale Breite (CSS, der IE kennt's natürlich nicht) eindämmen und in der Navigation scrollen lassen. Auch CSS umgeht dieses Problem nicht. Es ist bei CSS nur nicht _ganz_ so schlimm. Aber wenn der Text lang genug ist, muss man auch bei CSS scrollen.
Dazu habe ich bereits in einem anderen Post geantwortet. Das ist auch mit Tabellen nicht möglich.
Warum bringst du es dann ueberhaupt erst als vermeitnliches Argument>
Weil es anscheinend Leute gibt (wie du?), welche meinen, dass man ja mit CSS alles lösen könnte. Und das es reichen würde. Stimmt aber nicht. Nicht mal mit Tabellen zusammen.
Und was hat das jetzt mit iframes zu tun?
Ganz einfach: Ich will dich *immer noch* die fixe Positionierung innerhalb deines Tabellenlayouts umsetzen sehen.
Mit inhaltlichen Hilfen oder ohne?
Mit inhaltlichen Hilfen: Tabelle mit zwei Spalten. Rechte Spalte beinhaltet den Inhalt. Link Spalte beinhaltet ein weiteres Element, in dem die Navigation zu finde ist. Dieses Element ist fixiert. Ein weiteres Element darunter enthält auch die Navigation, ist aber nicht fixiert und füllt somit den erforderliche Breite aus. Nachteil: zweimal diegleiche Navigation. Ist aber theoretisch mit irgendwelchen Tricks möglich. So zufrieden? (warum ignorierst du meine Aussagen dazu in den anderen Posts immer? Absicht?)
Imho haben auf einer Seite em Angaben nichts zu suchen.
Dir scheint in Bezug darauf wirklich nicht klar zu sein, wovon du redest.Vielleicht gilt das nur für dich? Nenn mir einen Fall, in dem eine fixe Größe notwendig ist.
Nenne du mir bitte den Fall, in dem "em" *fix* ist.
Fix? Es hat _immer die gleiche_ Größe wie ein Buchstabe (oder irgendwie sowas, ich weiß nicht genau, wie groß ein em ist. Die Größe eines "M"?). Es ist also _nicht_ vom Inhalt abhängig. Das meinte ich mit "fix". Du musstest es natürlich wieder falsch verstehen.
em *ausgerechnet* fuer die Angabe von Bildmaszen ins Feld zu fuehren, ist dann noch mal wieder gesteigerter Bloedsinn deinerseits.
Für die Angabe von Bildmaßen? Das habe ich gar nicht, aber das scheint dir egal zu sein.
Hi,
Du argumentierst mit ganz bestimmten Sonderfaellen *fuer* den EInsatz von Tabellen - also duerfen solche Sonderfaelle auch in der Gegenargumentation verwendet werden, so du an einer fairen Diskussion interessiert bist.
Nein dürfen sie nicht. Das ist eine ganz andere Ebene.
Immer so, wie's dir am besten in den Kram passt ...
Ich gehe außerdem nicht von Sonderfällen aus (es ist das falsche Wort) sondern von selten geäußerten Wünschen. Nun nehme ich mir einen solchen Wunsch und versuche ihn zu verwirklichen. (1. Ebene)
Dann kann es bei der Verwirklichung wiederum inhaltliche Sonderfälle geben (2. Ebene), die gibt's aber auch bei CSS.
Gut, also in dem Punkt kein Vorteil auf einer Seite, sondern ein Unentschieden.
Aber im Rahmen des technisch und optisch sinnvollen.
Ja und mir ist der Rahmen zu eng. Mit Tabellen kann ich ihn für einen gewissen Preis erweitern.
Gut, ich kann meinen mit CSS besser und sinnvoller erweitern.
Auf den Einwand, dass bei deinem Tabellenkonstrukt damit eine ewig breite Navigationsspalte herauskaeme, und der eigentliche Inhalt rechts daneben erst durch Scrolling zu erreichen waere, gehst du natuerlich wieder nicht ein [...]
Doch in einem anderen Post. Aber ich wiederhole es nochmal gerne für dich: Das ist natürlich schlecht. Mann kann es durch eine maximale Breite (CSS, der IE kennt's natürlich nicht) eindämmen und in der Navigation scrollen lassen. Auch CSS umgeht dieses Problem nicht. Es ist bei CSS nur nicht _ganz_ so schlimm.
Aha - also eher ein Punkt *fuer* CSS, und *gegen* Tabelle ("nicht ganz so schlimm == besser).
Weil es anscheinend Leute gibt (wie du?), welche meinen, dass man ja mit CSS alles lösen könnte.
Habe ich nicht behauptet.
Und das es reichen würde. Stimmt aber nicht. Nicht mal mit Tabellen zusammen.
Wenn nicht mal CSS und Tabelle *zusammen* etwas (begrenzt sinnvolles) erreichen koennen, die Tabelle *allein* aber noch weniger - dann faellt also auch das als Argument pro Tabelle flach.
Ganz einfach: Ich will dich *immer noch* die fixe Positionierung innerhalb deines Tabellenlayouts umsetzen sehen.
Mit inhaltlichen Hilfen oder ohne?
Mit inhaltlichen Hilfen: Tabelle mit zwei Spalten. Rechte Spalte beinhaltet den Inhalt. Link Spalte beinhaltet ein weiteres Element, in dem die Navigation zu finde ist. Dieses Element ist fixiert. Ein weiteres Element darunter enthält auch die Navigation, ist aber nicht fixiert und füllt somit den erforderliche Breite aus. Nachteil: zweimal diegleiche Navigation.
Jetzt sind wir also von der Diskussion um das fuer und wieder "ueberfluessiger" Tags/Elemente schon dabei angekommen, Teile des *Inhaltes* doppelt vorzuhalten?
Wenn du das ernst meinst, ist deine Bereitschaft zu absolutem Unfug doch noch groesser ausgepraegt, als von mir bisher angenommen.
Ist aber theoretisch mit irgendwelchen Tricks möglich.
*Du* hast die Diskussion u.a. damit begonnen, ein paar (eher harmlose) CSS-Hacks als "Tricks" und damit beinahe "Teufelswerk" zu verdammen - und jetzt willst du mit noch fieseren (theoretischen) "Tricks" kommen, um immer noch auf Deibel komm raus den Einsatz einer Tabelle rechtfertigen zu koennen?
Es wird immer laecherlichr mit deiner Argumentation bzw. den Widerspruechlichkeiten, in denen du dich verstrickst.
So zufrieden?
Nein, ganz und gar nicht.
Deine Abweichung von dem, was ich sinnvollen Code nennen mag, waechst immer weiter.
Nenne du mir bitte den Fall, in dem "em" *fix* ist.
Fix? Es hat _immer die gleiche_ Größe wie ein Buchstabe (oder irgendwie sowas, ich weiß nicht genau, wie groß ein em ist. Die Größe eines "M"?). Es ist also _nicht_ vom Inhalt abhängig.
Wenn eben das gewuenscht ist, was waere dann falsch daran?
em *ausgerechnet* fuer die Angabe von Bildmaszen ins Feld zu fuehren, ist dann noch mal wieder gesteigerter Bloedsinn deinerseits.
Für die Angabe von Bildmaßen? Das habe ich gar nicht, aber das scheint dir egal zu sein.
Da stellst du einen direkten Zusammenhang zwischen Angaben in em und Bildmaszen her. Ob das beabsichtigt war, oder du einfach nicht in der Lage warst, dich korrekt auszudruecken, vermag ich nicht zu beurteilen.
MfG ChrisB
Hi,
Du argumentierst mit ganz bestimmten Sonderfaellen *fuer* den EInsatz von Tabellen - also duerfen solche Sonderfaelle auch in der Gegenargumentation verwendet werden, so du an einer fairen Diskussion interessiert bist.
Nein dürfen sie nicht. Das ist eine ganz andere Ebene.
Immer so, wie's dir am besten in den Kram passt ...
Nein. Immer so, wie es eine logische Tatsache ist.
Ich gehe außerdem nicht von Sonderfällen aus (es ist das falsche Wort) sondern von selten geäußerten Wünschen. Nun nehme ich mir einen solchen Wunsch und versuche ihn zu verwirklichen. (1. Ebene)
Dann kann es bei der Verwirklichung wiederum inhaltliche Sonderfälle geben (2. Ebene), die gibt's aber auch bei CSS.Gut, also in dem Punkt kein Vorteil auf einer Seite, sondern ein Unentschieden.
Nein. s.u.
Aber im Rahmen des technisch und optisch sinnvollen.
Ja und mir ist der Rahmen zu eng. Mit Tabellen kann ich ihn für einen gewissen Preis erweitern.
Gut, ich kann meinen mit CSS besser und sinnvoller erweitern.
Auf den Einwand, dass bei deinem Tabellenkonstrukt damit eine ewig breite Navigationsspalte herauskaeme, und der eigentliche Inhalt rechts daneben erst durch Scrolling zu erreichen waere, gehst du natuerlich wieder nicht ein [...]
Doch in einem anderen Post. Aber ich wiederhole es nochmal gerne für dich: Das ist natürlich schlecht. Mann kann es durch eine maximale Breite (CSS, der IE kennt's natürlich nicht) eindämmen und in der Navigation scrollen lassen. Auch CSS umgeht dieses Problem nicht. Es ist bei CSS nur nicht _ganz_ so schlimm.Aha - also eher ein Punkt *fuer* CSS, und *gegen* Tabelle ("nicht ganz so schlimm == besser).
Ja. Aber nur ein kleiner, weil das eigentlich Problem nicht gelöst ist. Es ist nur ein wenig gemildert.
Weil es anscheinend Leute gibt (wie du?), welche meinen, dass man ja mit CSS alles lösen könnte.
Habe ich nicht behauptet.
Ich wollte dich nur ein bisschen ärgern. ;)
Und das es reichen würde. Stimmt aber nicht. Nicht mal mit Tabellen zusammen.
Wenn nicht mal CSS und Tabelle *zusammen* etwas (begrenzt sinnvolles) erreichen koennen, die Tabelle *allein* aber noch weniger - dann faellt also auch das als Argument pro Tabelle flach.
Nochmal: ich habe nie geschrieben, dass man statt CSS generell Tabellen verwenden sollte. Lies nochmal mein erstes Posting.
Ganz einfach: Ich will dich *immer noch* die fixe Positionierung innerhalb deines Tabellenlayouts umsetzen sehen.
Mit inhaltlichen Hilfen oder ohne?
Mit inhaltlichen Hilfen: Tabelle mit zwei Spalten. Rechte Spalte beinhaltet den Inhalt. Link Spalte beinhaltet ein weiteres Element, in dem die Navigation zu finde ist. Dieses Element ist fixiert. Ein weiteres Element darunter enthält auch die Navigation, ist aber nicht fixiert und füllt somit den erforderliche Breite aus. Nachteil: zweimal diegleiche Navigation.Jetzt sind wir also von der Diskussion um das fuer und wieder "ueberfluessiger" Tags/Elemente schon dabei angekommen, Teile des *Inhaltes* doppelt vorzuhalten?
Wenn du das ernst meinst, ist deine Bereitschaft zu absolutem Unfug doch noch groesser ausgepraegt, als von mir bisher angenommen.
Wieso? So _ist_ es möglich. Dass das niemand so einsetzen würde ist klar, es ist ja nur ein Beispiel, um zu zeigen, _dass_ es irgendwie möglich ist. Bei CSS kommst du auch nicht drum herum, oder?
Ist aber theoretisch mit irgendwelchen Tricks möglich.
*Du* hast die Diskussion u.a. damit begonnen, ein paar (eher harmlose) CSS-Hacks als "Tricks" und damit beinahe "Teufelswerk" zu verdammen - und jetzt willst du mit noch fieseren (theoretischen) "Tricks" kommen, um immer noch auf Deibel komm raus den Einsatz einer Tabelle rechtfertigen zu koennen?
Nein. In diesem Fall brauchst du aber bei CSS ohne Tabellen genauso schlimme Hacks.
Nochmal meine Hauptaussage (extra für dich ganz klar und möglichst präzise formuliert): _Wenn_ man in einer Situation ist, in der die Vorteile gegenüber den Nachteilen überwiegen, wenn man ein Tabellenlayout (optional inklusive CSS und anderen Elementen) anstelle eines CSS Layouts einsetzt, weil letzteres unnötig viele Hacks nötig macht, dann sollte man das Tabellenlayout wählen und nicht aus Überzeugung das CSS Layout.
Alles klar? Ich schrieb _nie_, dass generell CSS Layouts durch Tabellenlayouts zu ersetzen seien. Das wäre Schwachsinn.
Es wird immer laecherlichr mit deiner Argumentation bzw. den Widerspruechlichkeiten, in denen du dich verstrickst.
Was für Widersprüche?
So zufrieden?
Nein, ganz und gar nicht.
Deine Abweichung von dem, was ich sinnvollen Code nennen mag, waechst immer weiter.
Ja, weil dieser eben _nicht_ mit aktuellen Mitteln möglich ist. Wenn man das nicht mit Tabellen und CSS kann, wie soll es dann ausschließlich mit CSS gehen?!?
Nenne du mir bitte den Fall, in dem "em" *fix* ist.
Fix? Es hat _immer die gleiche_ Größe wie ein Buchstabe (oder irgendwie sowas, ich weiß nicht genau, wie groß ein em ist. Die Größe eines "M"?). Es ist also _nicht_ vom Inhalt abhängig.
Wenn eben das gewuenscht ist, was waere dann falsch daran?
Was daran falsch wäre? Man verschwendet z.B. in vielen Fällen Anzeigefläche und auf einem kleinen Bildschirm nimmt die Navigation (dank fixer (du weißt was ich meine) em Größe) vielleicht den gesamten Bildschirm ein. Bei Tabellen würde vorher umgebrochen.
em *ausgerechnet* fuer die Angabe von Bildmaszen ins Feld zu fuehren, ist dann noch mal wieder gesteigerter Bloedsinn deinerseits.
Für die Angabe von Bildmaßen? Das habe ich gar nicht, aber das scheint dir egal zu sein.
Da stellst du einen direkten Zusammenhang zwischen Angaben in em und Bildmaszen her. Ob das beabsichtigt war, oder du einfach nicht in der Lage warst, dich korrekt auszudruecken, vermag ich nicht zu beurteilen.
Letzteres. Ich meinte nicht speziell em sondern eigentlich generell "fixe" Angaben (wie auch ex), die sich nicht nach dem Inhalt richten. In diesem speziellen Fall (Bilder) wären wohl eher Pixel angebracht. Allerdings: wenn man möchte, dass sich ein Bild mitvergrößert (auch in Browser, die nicht wie Opera und FF3 einen gesamten Seitenzoom besitzen), kann man die Größe in em angeben.
Hi,
Immer so, wie's dir am besten in den Kram passt ...
Nein. Immer so, wie es eine logische Tatsache ist.
Ach so, dann stammt also lediglich deine Definition von Logik aus einem anderen Universum.
Aha - also eher ein Punkt *fuer* CSS, und *gegen* Tabelle ("nicht ganz so schlimm == besser).
Ja. Aber nur ein kleiner, weil das eigentlich Problem nicht gelöst ist. Es ist nur ein wenig gemildert.
Wir halten also nichts desto Trotz fest:
CSS hier *besser* als Tabelle.
Jetzt sind wir also von der Diskussion um das fuer und wieder "ueberfluessiger" Tags/Elemente schon dabei angekommen, Teile des *Inhaltes* doppelt vorzuhalten?
Wenn du das ernst meinst, ist deine Bereitschaft zu absolutem Unfug doch noch groesser ausgepraegt, als von mir bisher angenommen.
Wieso? So _ist_ es möglich. Dass das niemand so einsetzen würde ist klar, es ist ja nur ein Beispiel, um zu zeigen, _dass_ es irgendwie möglich ist.
Deine Gegenseite in diesem Thread hat von Anfang an versucht, mit dem was *sinnvoll* moeglich ist zu argumentieren.
Dass du das auf "es ist moeglich" reduzierst, und das Attribut sinnvoll dabei unterschlaegst, ist zwar einer fachlich fundierten Diskussion nicht foerderlich, mag aber als Zeichen deiner Argumentlosigkeit durchgehen.
Nochmal meine Hauptaussage (extra für dich ganz klar und möglichst präzise formuliert): _Wenn_ man in einer Situation ist, in der die Vorteile gegenüber den Nachteilen überwiegen, wenn man ein Tabellenlayout (optional inklusive CSS und anderen Elementen) anstelle eines CSS Layouts einsetzt, weil letzteres unnötig viele Hacks nötig macht, dann sollte man das Tabellenlayout wählen und nicht aus Überzeugung das CSS Layout.
Das wurde von Anfang an kaum bestritten.
Nur wirklich sinnvolle und nicht lichtjahrweit praxisferne Beispiele fuer ein solches Layout hast du bisher immer noch nicht gebracht.
Deinen Versuch, irgendwas obskures theoretisches zu beschreiben, bei dem immer noch fast alles schoen vage bleibt (vermutlich wieder mal fuer eine nachfolgende Zurechtbiegung deinerseits ausgelegt - ich merke, du denkst voraus, wenn auch in komische Richtungen) oder sogar reichlich widerspruechlich ist, hat Sven ja eben schon schoen zerpflueckt :-)
Alles klar? Ich schrieb _nie_, dass generell CSS Layouts durch Tabellenlayouts zu ersetzen seien. Das wäre Schwachsinn.
Ja, aber vernuenftige Beispiele, die deinen Standpunkt wirklich argumentativ *und* nachvollziehbar untermauern wuerden, bleibst du immer noch weitestgehend schuldig.
Du fluechtest dich nur noch in "es gibt gewisse spezielle Konstellationen, die da wie wo so gelagert sind, dass ..."
MfG ChrisB
Hi,
Immer so, wie's dir am besten in den Kram passt ...
Nein. Immer so, wie es eine logische Tatsache ist.
Ach so, dann stammt also lediglich deine Definition von Logik aus einem anderen Universum.
Aha - also eher ein Punkt *fuer* CSS, und *gegen* Tabelle ("nicht ganz so schlimm == besser).
Ja. Aber nur ein kleiner, weil das eigentlich Problem nicht gelöst ist. Es ist nur ein wenig gemildert.
Wir halten also nichts desto Trotz fest:
CSS hier *besser* als Tabelle.
Ja.
Jetzt sind wir also von der Diskussion um das fuer und wieder "ueberfluessiger" Tags/Elemente schon dabei angekommen, Teile des *Inhaltes* doppelt vorzuhalten?
Wenn du das ernst meinst, ist deine Bereitschaft zu absolutem Unfug doch noch groesser ausgepraegt, als von mir bisher angenommen.
Wieso? So _ist_ es möglich. Dass das niemand so einsetzen würde ist klar, es ist ja nur ein Beispiel, um zu zeigen, _dass_ es irgendwie möglich ist.
Deine Gegenseite in diesem Thread hat von Anfang an versucht, mit dem was *sinnvoll* moeglich ist zu argumentieren.
Dass du das auf "es ist moeglich" reduzierst, und das Attribut sinnvoll dabei unterschlaegst, ist zwar einer fachlich fundierten Diskussion nicht foerderlich, mag aber als Zeichen deiner Argumentlosigkeit durchgehen.
Nochmal meine Hauptaussage (extra für dich ganz klar und möglichst präzise formuliert): _Wenn_ man in einer Situation ist, in der die Vorteile gegenüber den Nachteilen überwiegen, wenn man ein Tabellenlayout (optional inklusive CSS und anderen Elementen) anstelle eines CSS Layouts einsetzt, weil letzteres unnötig viele Hacks nötig macht, dann sollte man das Tabellenlayout wählen und nicht aus Überzeugung das CSS Layout.
Das wurde von Anfang an kaum bestritten.
Nur wirklich sinnvolle und nicht lichtjahrweit praxisferne Beispiele fuer ein solches Layout hast du bisher immer noch nicht gebracht.
Gut, ich gebe dir eins:
richte einen Footer so aus, dass er am unteren Rand des Browser klebt, wenn der Inhalt nicht bis nach ganz unten reicht, sich aber (wenn der Inhalt hoch genug wird) mit nach unten bewegt.
Das geht nur mit CSS hacks, die ich nicht möchte. Da nehme ich lieber nicht gehackte Tabellen. So, ist das praxisnah genug? Es finden sich dazu unzählige Postings im Archiv.
Deinen Versuch, irgendwas obskures theoretisches zu beschreiben, bei dem immer noch fast alles schoen vage bleibt (vermutlich wieder mal fuer eine nachfolgende Zurechtbiegung deinerseits ausgelegt - ich merke, du denkst voraus, wenn auch in komische Richtungen) oder sogar reichlich widerspruechlich ist, hat Sven ja eben schon schoen zerpflueckt :-)
Alles klar? Ich schrieb _nie_, dass generell CSS Layouts durch Tabellenlayouts zu ersetzen seien. Das wäre Schwachsinn.
Ja, aber vernuenftige Beispiele, die deinen Standpunkt wirklich argumentativ *und* nachvollziehbar untermauern wuerden, bleibst du immer noch weitestgehend schuldig.
Du fluechtest dich nur noch in "es gibt gewisse spezielle Konstellationen, die da wie wo so gelagert sind, dass ..."
Ja, das ist mit Teil meiner Kritik an CSS. Es ist nicht genug möglich. Ich möchte (aus Prinzip), dass _alles_ möglich ist. Es könnte ja doch irgendwann mal zu der Situation kommen. Aber das Beispiel oben sollte dir genügen. Und falls meine Formulierung für dich wieder nicht reicht: ich habe es Sven afair schon erklärt. Musst mal die Postings durchgucken.
Ich
will
schlafen...
*schnarch*
Hi,
richte einen Footer so aus, dass er am unteren Rand des Browser klebt, wenn der Inhalt nicht bis nach ganz unten reicht, sich aber (wenn der Inhalt hoch genug wird) mit nach unten bewegt.
Der A List Apart-Artikel zur Thematik ist dir ein Begriff?
Das geht nur mit CSS hacks, die ich nicht möchte.
Ich halte sie fuer durchaus vertretbar, in dem recht geringen Umfang, in dem sie dort erforderlich sind.
Aber wenn du sie einfach "nicht willst", gut - dagegen kann man nicht argumentieren.
Da nehme ich lieber nicht gehackte Tabellen.
Tabellen zur Auszeichnung nicht-tabellaerischer Daten sind fuer mich ein "HTML Hack" - den moechte ich wiederum nicht einsetzen.
So, ist das praxisnah genug?
Ja, aber auch nur wieder eins, welches keine der beiden in Rede stehenden Techniken als "die Bessere" aus dem Ring klettern laesst.
Unseren verschiedenen Loesungsansaetzen laegen lediglich unterschiedliche X in "ich moechte X (nicht) verwenden, wenn es auch anders geht" zu Grunde.
Ja, das ist mit Teil meiner Kritik an CSS. Es ist nicht genug möglich.
Wie schon mehrfach gesagt - selbst das einfache Umfliessen eines links oder rechts ausgerichteten Bildes durch Text ermoeglicht mir eine Tabelle nicht mal *ansatzweise*.
Ich möchte (aus Prinzip), dass _alles_ möglich ist.
Das hast du weder mit Tabellen, noch mit CSS - noch mit einer Kombination aus beiden.
Mir persoenlich bietet CSS allerdings mehr Flexibilitaet und damit (potentielle) Moeglichkeiten, als dass die Tabelle je koennte - prinzipbedingt, denn eine Tabelle besteht nun mal nach wie vor im wesentlichen aus Rechtecken, deren Seiten buendig aneinander ausgerichtet sind.
Aber das Beispiel oben sollte dir genügen.
Und dir das mit dem Umfluss ...
MfG ChrisB
Hallo Die_Antwort
Abgesehen davon, dass so lange zusammenhaengende Woerter auch wieder einen extremen Sonderfall darstellen -
Ich möchte kein Layout haben, was nur in manchen Fällen funktioniert.
Soll sich das Design an meine Inhalte anpassen oder meine Inhalte an das Design? Eher ersteres oder nicht? Und: wer sagt, dass eine lange Aneinanderreihung von Buchstaben nicht sinnvoll sein muss?
Du würdest ein Layout, bei dem die seitliche Navigation das gesamte Browserfenster ausfüllt und der eigentliche Inhalt dann in einer nur durch seitliches scrollen erreichbaren schmalen Spalte mit einem Wort pro Zeile untergebracht ist, als funktionierendes Layout bezeichnen?
Da ist eine serverseitige Begrenzung der Linktextlänge, ein overflow:auto oder zur Not selbst ein overflow:hidden sinnvoller. Und das braucht definitiv _keine_ Tabelle.
Wenn das Layout zuerst kommt, und danach erst die Inhalte - dann machst du ganz sicher etwas falsch (oder du hast eigentlich keine Inhalte, willst aber mal eine "toll aussehende" Webseite basteln).
Sag das allen CMS Benutzern.
Auch bei Verwendung eines CMS muss die Größenordnung und Struktur der eingepflegten bzw. der einzupflegenden Inhalte festgelegt sein, sonst ist jegliches Layout dafür absolut sinnlos.
Auf Wiederlesen
Detlef
Hallo Die_Antwort
Huhu!
Abgesehen davon, dass so lange zusammenhaengende Woerter auch wieder einen extremen Sonderfall darstellen -
Ich möchte kein Layout haben, was nur in manchen Fällen funktioniert.
Soll sich das Design an meine Inhalte anpassen oder meine Inhalte an das Design? Eher ersteres oder nicht? Und: wer sagt, dass eine lange Aneinanderreihung von Buchstaben nicht sinnvoll sein muss?
Du würdest ein Layout, bei dem die seitliche Navigation das gesamte Browserfenster ausfüllt und der eigentliche Inhalt dann in einer nur durch seitliches scrollen erreichbaren schmalen Spalte mit einem Wort pro Zeile untergebracht ist, als funktionierendes Layout bezeichnen?
Ja, mit CSS geht es zwar besser, aber das ursprüngliche Problem bleibt dasselbe.
Da ist eine serverseitige Begrenzung der Linktextlänge, ein overflow:auto oder zur Not selbst ein overflow:hidden sinnvoller. Und das braucht definitiv _keine_ Tabelle.
Hä? Ich dachte Code und Design strikt trennen? Oder doch in den Code eingreifen, um das Design zu bewahren? Ja was denn nun? Außerdem gibt es Fälle in denen selbst das nicht möglich ist.
Auf Wiederlesen
Detlef
Na hoffentlich ;)
Die_Antwort
Hi,
Du würdest ein Layout, bei dem die seitliche Navigation das gesamte Browserfenster ausfüllt und der eigentliche Inhalt dann in einer nur durch seitliches scrollen erreichbaren schmalen Spalte mit einem Wort pro Zeile untergebracht ist, als funktionierendes Layout bezeichnen?
Ja, mit CSS geht es zwar besser, aber das ursprüngliche Problem bleibt dasselbe.
Aber deine Argumentation pro Tabelle faellt damit in diesem Punkt in sich zusammen.
Da ist eine serverseitige Begrenzung der Linktextlänge, ein overflow:auto oder zur Not selbst ein overflow:hidden sinnvoller. Und das braucht definitiv _keine_ Tabelle.
Hä? Ich dachte Code und Design strikt trennen?
Im Allgemeinen - ja, natuerlich.
Aber in einem solchen *Sonderfall* den sinnvollsten Kompromiss finden - oder eine die sinnvolle Nutzung der Seite behindernde Darstellungsform waehlen?
Oder doch in den Code eingreifen, um das Design zu bewahren?
Das war nur die erste genannte Moeglichkeit. Die anderen beiden greifen nicht in den HTML-Code ein.
Außerdem gibt es Fälle in denen selbst das nicht möglich ist.
Auch damit argumentierst du immer wieder und sehr gern - allerdings wieder mal ohne jeglichen Beleg.
MfG ChrisB
Hi,
Du würdest ein Layout, bei dem die seitliche Navigation das gesamte Browserfenster ausfüllt und der eigentliche Inhalt dann in einer nur durch seitliches scrollen erreichbaren schmalen Spalte mit einem Wort pro Zeile untergebracht ist, als funktionierendes Layout bezeichnen?
Ja, mit CSS geht es zwar besser, aber das ursprüngliche Problem bleibt dasselbe.
Aber deine Argumentation pro Tabelle faellt damit in diesem Punkt in sich zusammen.
Weil CSS einen in 0.0000001% aller Fälle geringen Vorteil hat? Gut, ich gebe mich geschlagen...
Da ist eine serverseitige Begrenzung der Linktextlänge, ein overflow:auto oder zur Not selbst ein overflow:hidden sinnvoller. Und das braucht definitiv _keine_ Tabelle.
Hä? Ich dachte Code und Design strikt trennen?
Im Allgemeinen - ja, natuerlich.
Aber in einem solchen *Sonderfall* den sinnvollsten Kompromiss finden - oder eine die sinnvolle Nutzung der Seite behindernde Darstellungsform waehlen?
Ich mag Kompromisse nicht. Kompromisse werden immer dann gemacht, wenn bereits die Grundlage nicht stimmt.
Oder doch in den Code eingreifen, um das Design zu bewahren?
Das war nur die erste genannte Moeglichkeit. Die anderen beiden greifen nicht in den HTML-Code ein.
Und das kann ich mit zusätzlichen Tabellen für meine inhaltsangepasste Spalte und CSS nicht?
Außerdem gibt es Fälle in denen selbst das nicht möglich ist.
Auch damit argumentierst du immer wieder und sehr gern - allerdings wieder mal ohne jeglichen Beleg.
Achso? Angenommen ich habe einen Link, der unbedingt ausgeschrieben werden muss. Und der Link ist seeeehr lang. Dann kommt es vor allem auf kleineren Bildschirmen schonmal dazu, dass der Link länger ist als der Bildschirm. Und nun? Willst du ihn einfach abschneiden?
Hallo
Du würdest ein Layout, bei dem die seitliche Navigation das gesamte Browserfenster ausfüllt und der eigentliche Inhalt dann in einer nur durch seitliches scrollen erreichbaren schmalen Spalte mit einem Wort pro Zeile untergebracht ist, als funktionierendes Layout bezeichnen?
Ja, mit CSS geht es zwar besser, aber das ursprüngliche Problem bleibt dasselbe.
Wozu ist dann deine hochgelobte Tabelle nötig, wenn du selbst schreibst, dass es mit CSS besser geht?
Da ist eine serverseitige Begrenzung der Linktextlänge, ein overflow:auto oder zur Not selbst ein overflow:hidden sinnvoller. Und das braucht definitiv _keine_ Tabelle.
Hä? Ich dachte Code und Design strikt trennen? Oder doch in den Code eingreifen, um das Design zu bewahren? Ja was denn nun? Außerdem gibt es Fälle in denen selbst das nicht möglich ist.
Ein vernünftiges CMS sollte solche Extremfälle entsprechend verarbeiten.
Und wenn es das nicht tut, seit wann ist ein overflow:auto ein Eingriff in den (HTML)-Code?
Auf Wiederlesen
Detlef
Hallo
Du würdest ein Layout, bei dem die seitliche Navigation das gesamte Browserfenster ausfüllt und der eigentliche Inhalt dann in einer nur durch seitliches scrollen erreichbaren schmalen Spalte mit einem Wort pro Zeile untergebracht ist, als funktionierendes Layout bezeichnen?
Ja, mit CSS geht es zwar besser, aber das ursprüngliche Problem bleibt dasselbe.
Wozu ist dann deine hochgelobte Tabelle nötig, wenn du selbst schreibst, dass es mit CSS besser geht?
Damit ich eine an den Inhalt angepasste Spalte habe. Geht mit CSS nicht.
Da ist eine serverseitige Begrenzung der Linktextlänge, ein overflow:auto oder zur Not selbst ein overflow:hidden sinnvoller. Und das braucht definitiv _keine_ Tabelle.
Hä? Ich dachte Code und Design strikt trennen? Oder doch in den Code eingreifen, um das Design zu bewahren? Ja was denn nun? Außerdem gibt es Fälle in denen selbst das nicht möglich ist.
Ein vernünftiges CMS sollte solche Extremfälle entsprechend verarbeiten.
Und wenn es das nicht tut, seit wann ist ein overflow:auto ein Eingriff in den (HTML)-Code?
Ich bezog mich auf das CMS. overflow:auto ist selbstverständlich kein Eingriff in die Code. das kann auch aber auch in Tabellen für meine Zwecke verwenden.
Ich bezog mich auf das CMS. overflow:auto ist selbstverständlich kein Eingriff in die Code. das kann auch aber auch in Tabellen für meine Zwecke verwenden.
Aber nicht auf das Element das die Maße hat (td), sondern du musst ein zusätzliches sinnloses Element einfügen.
Struppi.
Hi,
Zudem haben Tabellen Probleme mit Minimal- und Maximal-Breitenangaben. Das macht es schwirig, einen guten Lesefluss zu erzeugen.
? Verstehe ich nicht.
Merkt man.
Da ich so gut wie nie Layouts gestalte, in denen irgendein Bereich in Prozent oder em oder sonstwas angegeben ist (außer selten 100%), verwende ich solche Breitenangaben gar nicht.
So viel also zum Thema "Erfahrung" mit beiden Welten, mit der du dich hier bruestest.
Solche Angaben sind böse und unflexibel.
Aua.
Kopier dir mal den Quelltext vom Zen Garden und schreib in einen der Navigationspunkte mal "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" hinein. Der Text geht über die Navigation hinaus. Das ist imho schlecht und sollte wenn möglich vermieden werden. Dafür muss die Navigation ihre Größe ausschließlich dem Inhalt anpassen.
Und in deiner Tabellenwelt? Da habe ich ploetzlich eine Navigation(sspalte), die die komplette Viewportbreite einnimmt, und muss nach rechts scrollen, um den eigentlichen Inhalt zu erreichen.
MfG ChrisB
Da ich so gut wie nie Layouts gestalte, in denen irgendein Bereich in Prozent oder em oder sonstwas angegeben ist (außer selten 100%), verwende ich solche Breitenangaben gar nicht.
So viel also zum Thema "Erfahrung" mit beiden Welten, mit der du dich hier bruestest.
Zusammenhang?
Solche Angaben sind böse und unflexibel.
Aua.
Und doch ist es so. Es sei denn man mag zusätzlichen Aufwand.
Kopier dir mal den Quelltext vom Zen Garden und schreib in einen der Navigationspunkte mal "WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW" hinein. Der Text geht über die Navigation hinaus. Das ist imho schlecht und sollte wenn möglich vermieden werden. Dafür muss die Navigation ihre Größe ausschließlich dem Inhalt anpassen.
Und in deiner Tabellenwelt? Da habe ich ploetzlich eine Navigation(sspalte), die die komplette Viewportbreite einnimmt, und muss nach rechts scrollen, um den eigentlichen Inhalt zu erreichen.
Das ist zugegebenermaßen nicht sehr toll. Allerdings wird das in 0.0001% aller Fälle vorkommen. Auf Handys oder ähnliche mobilen Browsern. Und selbst diese kommen mit Tabellen teilweise viel besser klar. Aber immerhin gibst du zu, dass diese Navigation einen gehörigen Nachteil hat.
Hi,
Und in deiner Tabellenwelt? Da habe ich ploetzlich eine Navigation(sspalte), die die komplette Viewportbreite einnimmt, und muss nach rechts scrollen, um den eigentlichen Inhalt zu erreichen.
Das ist zugegebenermaßen nicht sehr toll. Allerdings wird das in 0.0001% aller Fälle vorkommen.
Schoen zu sehen, wie du dich im Kreise drehst, um den Luecken deiner eigenen Argumentation irgendwie wieder zu entkommen :-)
Der ueberbreite Linktext in der Navigation *war* eines deiner Argumente - und jetzt stellt er ploetzlich doch wieder einen extrem seltenen Sonderfall dar - seltsam.
Auf Handys oder ähnliche mobilen Browsern. Und selbst diese kommen mit Tabellen teilweise viel besser klar. Aber immerhin gibst du zu, dass diese Navigation einen gehörigen Nachteil hat.
Das gebe ich nicht zu, das war von Anfang an mein Argument, und zwar ein gegen deine Auffassung gerichtetes.
MfG ChrisB
Hi,
Und in deiner Tabellenwelt? Da habe ich ploetzlich eine Navigation(sspalte), die die komplette Viewportbreite einnimmt, und muss nach rechts scrollen, um den eigentlichen Inhalt zu erreichen.
Das ist zugegebenermaßen nicht sehr toll. Allerdings wird das in 0.0001% aller Fälle vorkommen.
Schoen zu sehen, wie du dich im Kreise drehst, um den Luecken deiner eigenen Argumentation irgendwie wieder zu entkommen :-)
Der ueberbreite Linktext in der Navigation *war* eines deiner Argumente - und jetzt stellt er ploetzlich doch wieder einen extrem seltenen Sonderfall dar - seltsam.
Er stellt nur einen Sonderfall in einem speziellen Anzeigemedium dar. Genauso wie ein vielleicht alter Browser gar kein CSS darstellen kann oder Handhelds Probleme damit haben. Ebenso kann man auf einer 1x1 Pixel großen Anzeige _weder_ die Tabelle noch das CSS darstellen. Darum geht es hier aber nicht.
Abgesehen davon gilt dasselbe auch fürs CSS. Ist der Text zu lang, nimmt das eine mit CSS formatierte Element die gesamte Breite ein. Der Text muss dazu vielleicht etwas länger sein, das ändert aber nichts am Prinzip. Übrigens kann man um das zu vermeiden, eine maximale Größe zuweisen (um die sich der IE natürlich nicht kümmert, aber das nur nebenbei).
Hi,
Er stellt nur einen Sonderfall in einem speziellen Anzeigemedium dar.
Der weder mit der Tabelle noch mit CSS zufriedenstellen loesbar ist - also in deiner Argumentation pro Tabelle auch sinnfrei ist.
Ebenso kann man auf einer 1x1 Pixel großen Anzeige _weder_ die Tabelle noch das CSS darstellen. Darum geht es hier aber nicht.
Warum fuehrst es dann hier ueberhaupt an - also weiteres in deiner immer weiter wachsenden Aneinanderreihung von Nullargumenten?
Abgesehen davon gilt dasselbe auch fürs CSS. Ist der Text zu lang, nimmt das eine mit CSS formatierte Element die gesamte Breite ein.
Oder der zu lange Inhalt wird abgeschnitten,
oder der zu lange Inhalt ergibt einen Element-internen Scrollbalken, der die beabsichtigten Dimensionen bewahrt, und nur an dieser einen Stelle einen kleineren Kompromiss in Sachen Nutzbarkeit und Optik eingeht.
Beide ueberdenkenswerten Alternativen vermag deine Tabelle *nicht* anzubieten.
Übrigens kann man um das zu vermeiden, eine maximale Größe zuweisen (um die sich der IE natürlich nicht kümmert, aber das nur nebenbei).
Wieder CSS, nicht Tabelle.
MfG ChrisB
Hi,
Er stellt nur einen Sonderfall in einem speziellen Anzeigemedium dar.
Der weder mit der Tabelle noch mit CSS zufriedenstellen loesbar ist - also in deiner Argumentation pro Tabelle auch sinnfrei ist.
Wer hat denn damit angefangen?
Ebenso kann man auf einer 1x1 Pixel großen Anzeige _weder_ die Tabelle noch das CSS darstellen. Darum geht es hier aber nicht.
Warum fuehrst es dann hier ueberhaupt an - also weiteres in deiner immer weiter wachsenden Aneinanderreihung von Nullargumenten?
Um dir zu zeigen, dass du nicht mit solchen sinnfreien Beispielen anfangen sollst.
Abgesehen davon gilt dasselbe auch fürs CSS. Ist der Text zu lang, nimmt das eine mit CSS formatierte Element die gesamte Breite ein.
Oder der zu lange Inhalt wird abgeschnitten,
Oh ja, viel besser. Dann kann der Anwender nicht mal mehr scrollen :) DAS ist die Lösung! ;)
oder der zu lange Inhalt ergibt einen Element-internen Scrollbalken, der die beabsichtigten Dimensionen bewahrt, und nur an dieser einen Stelle einen kleineren Kompromiss in Sachen Nutzbarkeit und Optik eingeht.
Auf _diese_ Weise kann ich's auch mit Tabellen und CSS machen (ggf. einem anderen Element). Oder willst du mir sagen, dass dort "max-width" keine Auswirkungen hat?
Beide ueberdenkenswerten Alternativen vermag deine Tabelle *nicht* anzubieten.
Übrigens kann man um das zu vermeiden, eine maximale Größe zuweisen (um die sich der IE natürlich nicht kümmert, aber das nur nebenbei).
Wieder CSS, nicht Tabelle.
Ich hab eine Aufgabe für dich: du suchst jetzt bitte alle Posts hier von mir durch und zitierst die Stelle, an der ich etwa folgendes sage:
"Tabellen sind viel besser als CSS man sollte ausschließlich Tabellen _anstatt_ CSS einsetzen". Nachdem du festegestellt hast, dass ich das nicht gesagt habe, merkst du auch, dass du sinnlos diskutierst. Und zwar deinentwegen.
Moin!
Ich hab eine Aufgabe für dich: du suchst jetzt bitte alle Posts hier von mir durch und zitierst die Stelle, an der ich etwa folgendes sage:
"Tabellen sind viel besser als CSS man sollte ausschließlich Tabellen _anstatt_ CSS einsetzen". Nachdem du festegestellt hast, dass ich das nicht gesagt habe, merkst du auch, dass du sinnlos diskutierst. Und zwar deinentwegen.
Der Titel deines Eröffnungspostings lautet:
"Warum Tabellen für Layouts manchmal besser als CSS sind"
Unter diesem Titel laufen fast alle deine Postings (mit Ausnahme der Zweige, in denen andere Poster den Titel abgeändert haben).
- Sven Rautenberg
Moin!
Ich hab eine Aufgabe für dich: du suchst jetzt bitte alle Posts hier von mir durch und zitierst die Stelle, an der ich etwa folgendes sage:
"Tabellen sind viel besser als CSS man sollte ausschließlich Tabellen _anstatt_ CSS einsetzen". Nachdem du festegestellt hast, dass ich das nicht gesagt habe, merkst du auch, dass du sinnlos diskutierst. Und zwar deinentwegen.
Der Titel deines Eröffnungspostings lautet:
"Warum Tabellen für Layouts manchmal besser als CSS sind"
Nun, ich wollte den Titel nicht noch größer werden lassen. Schließlich passt sich das Layout nicht an den Titel an, sondern der Titel wird einfach abgeschnitten =(.
;)
Und selbst dann ist diese Aussage nicht falsch.
Hallo,
Auf _diese_ Weise kann ich's auch mit Tabellen und CSS machen (ggf. einem anderen Element). Oder willst du mir sagen, dass dort "max-width" keine Auswirkungen hat?
Eben. Wenn du versuchst, max-width innerhalb einer Tabellenzelle oder auf eine Tabellenzelle anzuwenden wirst du scheitern. max-width spielt bei der Berechnung der Tabelle keine Rolle.
Gruß
Hi,
Ja, nimmst du Divisionen, dann brauchst du nicht 3 Plakate sondern 6 und drei davon sind inhaltslos und stehen schräg in der Gegend herum. Ist das wirklich besser?
[...]
Ja tut man. Und man fügt nicht zusätzliche sinnfreie und ggf. verwirrende Informationen ein, oder?
Ich stelle zwei Informationseinheiten in zwei DIVs dar, du in Zwei TDs.
Ich benoetige vielleicht noch ein weiteres gruppierendes DIV drumherum - und du noch mindestens ein TR und ein TABLE :-)
Ich persönliche habe es lieber, ein Element zweckzuentfremden, als zusätzlich Elemente hinzuzufügen, bei denen ich mich vielleicht nach einiger Zeit frage: "wozu waren die jetzt nochmal hier?".
TABLE, TR, ... was hab ich mir noch mal dabei gedacht damals? *Gruebel*
MfG ChrisB
Moin,
ich bin nicht der Meinung, das Tabellen die bessere Wahl. Einige angebliche Probleme werden meiner Meinung dadurch hervorgerufen, das die Designer immer noch versuchen, Print-Designs ins Web zu übertragen. Außerdem erwarten viele, dass ihre Positionierungen exakt und fix sind, sozusagen in Stein gemeißelt sind. Das war nie so gedacht.
Mittels CSS gibt man Empfehlungen/Vorschläge an, wo einzelne Elemente stehen sollen. Der Browser entscheidet dann, ob an der Stelle genug Platz ist, und setzt die Elemente dann dorthin. Falls nicht genug Platz da ist, werden Sie halt untereinander gesetzt.
Es gäbe ja schon Möglichkeiten, um Tabellenlayouts mit CSS zu simulieren (display:table und Konsorten), aber leider kann der IE das immer noch nicht...
Das anderen Probleme wurden hier schon angesprochen:
In CSS3 sind diese Probleme übrigens mit hoher Wahrscheinlichkeit Vergangenheit. Es gibt dort zwei Ansätze, um die "typischen" Layouts zu erzeugen: Grid Layout und Advanced Layout.
Leider wird es wohl noch ein paar Jahre (Jahrzehnte?) dauern, bis die Browser das können. Firefox 3 z.B. wird es meines Wissens nach nicht können.
Gruß
Stareagle
Hallo,
Leider wird es wohl noch ein paar Jahre (Jahrzehnte?) dauern, bis die Browser das können. Firefox 3 z.B. wird es meines Wissens nach nicht können.
Bedenke dabei aber bitte, dass diese Entwürfe noch Arbeitsentwürfe sind und daher von einer Implementierung abgeraten wird.
Ie ist jetzt zum Glück auf dem besten Weg, CSS 2.1 (richtig) zu implementieren, d. h. in wenigen jahren wird hier wesentlich einfachere Arbeit möglich sein.
Gruß
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen. Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Das Modell hat sicher Macken, aber natürlich muss das Layout auch an die Technik angepaßt werden. Im Printbereich ist es selbstverständlich, warum sollte es beim Webdesign anders sein. Wenn du es nicht schaffst ein Design zu entwickeln, was sich mit CSS umsetzten läßt, dann ist der Entschluss Tabellen zu verwenden für dich wahrscheinlich der Richtige. Dann hast du aber vermutlich nicht erkannt, welche Vorteile und was für eine Flexibilität ein CSS Design haben kann.
Struppi.
Hallo Anonymer!
Vorweg: Ich finde es etwas bedauerlich, dass du zwar einerseits gerne Diskutieren möchtest, das aber andererseits dann "anonym" machst.
Es wird ja nun hier auf SELFHTML, SELFHTML Forum und auch in vielen anderen Foren und vielen anderen Seiten "gepredigt", statt Tabellen lieber Divisionen einzusetzen (oder andere Elemente, je nach Einsatzzweck) und diese mit CSS wie gewünscht zu formatieren.
Und das aus gutem Grund (guten Gründen).
Dabei entstehen Probleme. Entwickler wünschen sich, dass zwei Elemente gleich lang sind, also in der Höhe immer gleich groß sind, was meist bei dreispaltigen Layouts zum Einsatz kommen soll.
Warum eigentlich?
Weiterhin wird sich gewünscht, dass der Footer auch dann ganz am Ende gezeigt wird, wenn der Inhalt und die restlichen Elemente nicht bis zum Ende des Dokuments reichen.
Wozu eigentlich?
Die Antwort lautet (leider) immer noch: es ist nicht möglich!
"Doch!" werden nun sicherliche einige von euch rufen und es stimmt. Es _ist_ möglich. Aber zu welchem Preis?
Wenn man - um einen Footer am Boden eines Dokuments zu platzieren - zusätzliche (sinnfreie, nur zur Formatierung vorhandene) Elemente (z.B. Divisionen) braucht, u.a. einen großen Container und ein "gecleartes" Element, wo bleiben dann die Vorteile? Die Semantik geht kaputt. Es existieren plötzlich Elemente, die gar nicht gewünscht sind. Elemente, die nur dank einer unvollständigen Technik vorhanden sind und die gar nicht in die Gedankenwelt eines Entwicklers passen. Warum dann nicht eine Tabelle einsetzen?
Die Frage hast du dir doch schon selber beantwortet.
Es ist doch gerade so, dass die Verwendung sog. inhaltsleerer Elemente (die eben genau keinerlei Semantik beinhalten), die Semantik _nicht_ kaputt macht, im Gegensatz zur missbräuchlichen Verwendung von Tabellen für nicht tabellarische Daten.
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immer noch Funktion und Layout voneinander trennen.
Nein. In diesem Punkt irrst du.
Eine andere Möglichkeit, sind optische Effekte (faux columns). Aber wir müssen bedenken: warum wollten wir nochmal von den Tabellen weg? Achja, die Semankik. Aber wo bleibt die, wenn sich die Elemente gar nicht so verhalten, wie wir wollen sondern nur so aussehen? Das tun die Tabellen doch auch. Und sie tun es besser!
Diesen Absatz verstehe ich nicht. Bezüglich der Semantik siehe oben.
Nun kann man darüber streiten, ob es "schlimmer" ist, eine Tabelle zur Formatierung einzusetzen oder etliche sinnfreie überflüssige Divisionen in Quelltext zu haben, die letztendlich auch nur der Formatierung dienen, obwohl wir genau _das_ verhindern wollten.
Darüber zu streiten lohnt sich imho nicht, da die Antwort ganz klar ist.
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen.
Da das aber _immer_ geht, kannst du dazu übergehen zu sagen:"Verwendet CSS für das Layout und Tabellen für tabellarische Daten!".
Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Sollten wir aus bereits genannten Gründen natürlich nicht.
Ich freue mich auf eure Meinungen und besonders auf stark abweichende Meinungen!
Deine Ausführungen zeugen eigentlich davon, dass du nur einen kleinen Ausschnitt des Ganzen betrachtest, und den auch noch aus einer sehr "ungünstigen" Perspektive.
Das Web ist mehr als bloß die Darstellung von Seiten in einem Browser.
Aber deine Ausführungen zu Tabellen für das Layout würden, abgesehen von der semantischen Unkorrektheit, wenn überhaupt nur für diesen Fall einigermaßen zutreffen. Sobald du andere Ausgabemedien, wie z.B. Braillezeilen oder Screenreader hast, wird der Unterschied zwischen der Verwendung von CSS und Tabellen für das Layout mehr als deutlich.
Ich will keineswegs behaupten, dass CSS perfekt ist, oder das "ideale" Werkzeug für die Layoutgestaltung, aber es ist mit Sicherheit aktuell das Beste, was zur Verfügung steht.
Und wenn du mal ein Stückchen über deinen eigenen Tellerrand rüberguckst, wirst du das früher oder später auch erkennen.
Im übrigen wurde ja bereits hier im Thread auch schon erwähnt, dass die "gewünschte" Darstellung von Tabellen browserübergreifend weit weniger konsistent ist, als du vielleicht annimmst. Im übrigen gibt man als Designer auch immer ein Stück der Gestaltung aus der Hand (nämlich an den jeweiligen Browser), wenn man Tabellen (semantisch korrekt) verwendet.
Gruß Gunther
Hi,
Hallo Anonymer!
Vorweg: Ich finde es etwas bedauerlich, dass du zwar einerseits gerne Diskutieren möchtest, das aber andererseits dann "anonym" machst.
Und dann auch noch mit einem so unguenstig gewaehlten Nick wie "Die_Antwort" - und damit eine Allgemeingueltigkeit der eigenen Aussagen implizierend, die absolut nicht gegeben ist - was man im Threadverlauf ja auch merkt, da er/sie selbst zugibt, dass sein (immer noch reichlich ominoeses und kaum greifbares) umzusetzendes "Beispiellayout" einen ziemlich raren Sonderfall darstellt ...
"Die_Ausnahme" waere vielleicht eine passendere Nickwahl gewesen.
MfG ChrisB
"gepredigt", statt Tabellen lieber Divisionen einzusetzen
Genau, Divisionen, Marsch, Marsch, der Feind steht ostwärts!!1 Wie nennst du eigentlich <span>-Elemente, Spanner?
Dabei entstehen Probleme. Entwickler wünschen sich, dass zwei Elemente gleich lang sind, also in der Höhe immer gleich groß sind, was meist bei dreispaltigen Layouts zum Einsatz kommen soll.
Durchaus ohne Handstand möglich, kommt aber zugegebenermaßen auf den Einzelfall an.
Weiterhin wird sich gewünscht, dass der Footer auch dann ganz am Ende gezeigt wird, wenn der Inhalt und die restlichen Elemente nicht bis zum Ende des Dokuments reichen.
Da möchte ich hinterfragen, wer denn das Ende bei Webseiten definiert. Eine Webseite hat kein physikalisch vorgebenes Ende wie es bei einem Blatt Papier der Fall ist. Deshalb ist bei mir das Ende genau dort, wo der vorangehende „Inhalt und die restlichen Elemente“ zu Ende sind. Sie können also gar nicht „nicht bis zum Ende reichen“, sie sind das Ende.
Die Antwort lautet (leider) immernoch: es ist nicht möglich!
Gegenfrage: Muss es denn möglich sein? Ich möchte niemandem seinen Gestaltungswunsch in Abrede stellen, aber ich habe den Eindruck, dass sich die technischen Probleme bisweilen erst dadurch ergeben, dass jemand mit dem Kopf durch die Wand will und nicht vom Althergebrachten abweichen kann. „Aber ich mache doch seit Jahren dreispaltige Seiten …“
Die Vorteile [des Tabellenlayouts] sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller)
Alles geht schnell, wenn man's erstmal kann. Die Systematik des Tabellenlayouts ist lediglich leichter zu durchblicken.
Eine andere Möglichkeit, sind optische Effekte (faux columns). Aber wir müssen bedenken: warum wollten wir nochmal von den Tabellen weg? Achja, die Semankik. Aber wo bleibt die, wenn sich die Elemente gar nicht so verhalten, wie wir wollen sondern nur so aussehen?
Ich kann den Punkt nicht so ganz nachvollziehen, aber ein <div> und Semantik in einen Satz zu stellen, erscheint mir in dieser Hinsicht gewagt, Grund siehe nächster Absatz.
Nun kann man darüber streiten, ob es "schlimmer" ist, eine Tabelle zur Formatierung einzusetzen oder etliche sinnfreie überflüssige Divisionen in Quelltext zu haben, die letztendlich auch nur der Formatierung dienen, obwohl wir genau _das_ verhindern wollten.
Du irrst. Eine Tabelle hat eine Aussage, sie stellt ihre Inhalte in eine Beziehung zueinander. Die Eigenschaft der Elemente <div> und <span> ist gerade, dass sie letztlich (fast) keine haben, ihr einziger Zweck _ist_ die Formatierung.
Deshalb wundert mich deine Verwendung des Wörtchens Semantik (Sinn, Bedeutung) oben. <div> und <span> sind dazu da, Bereiche mehr oder weniger bedeutungslos zu gruppieren, im Gegensatz zu beispielsweise dem <p>, das einen Absatz kennzeichnet.
So, wie du auf dem <div> rumreitest, habe ich den Verdacht, dass es dir nicht um CSS geht, sondern du vielmehr der weitverbreiteten <div>-Wüste aufgesessen bist, einer Seite, die fast ausschließlich aus <div>s und <span>s besteht und sich nicht um den Einsatz besser passende Elemente kümmert - genau das ist aber nicht im Sinne der Entwickler. CSS-Einsatz bedeutet nicht <div>-Einsatz! Zu allererst haben andere HTML-Elemente eingesetzt zu werden, erst wenn wirklich nichts passt, kommen die sinnfreien Elemente <div> und <span> ins Spiel.
Bezeichnenderweise scheinen häufig ausgerechnet die Leute <div>-Wüsten zu verbrechen, die sich früher schon keinen Gedanken über das Tabellenlayout gemacht haben.
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen.
Es ist nicht so, dass Tabellen grundsätzlich pfui sind. Ganz im Gegenteil, mittlerweile kann man über Fälle stolpern, in denen eine Tabelle in jeglicher Hinsicht hervorragend geeignet wäre, der Autor aber meinte, auf Teufel komm raus alles in <div>s zu würgen, „weil ich doch kein Tabellenlayout haben will“. Das ist natürlich auch Unsinn.
Hallo,
Da wird einem richtig nostalgisch. Diese »Tabellen, div und Semantik«-Debatten wurden hier 2002 ad nauseaum geführt. Kann man mehr Bände mit füllen als dem Brockhaus seine Enzyklopädie. Faszinierend, dass es noch Leute gibt, die Lust dazu haben, was zu schreiben. Und man kann doch nur schreiben, was schon 7452mal geschrieben wurde. Aber Daumen hoch!
Ich kann nur auf meinen Artikel http://aktuell.de.selfhtml.org/weblog/css-spaltenlayout von 2005/2006 verweisen, der die Frage »Tabellenlayout vs. CSS-Spalten« diskutiert.
Mathias
Hallo Mathias!
Da wird einem richtig nostalgisch. Diese »Tabellen, div und Semantik«-Debatten wurden hier 2002 ad nauseaum geführt. Kann man mehr Bände mit füllen als dem Brockhaus seine Enzyklopädie.
Ja, der werte OP hinkt der Zeit etwas hinterher. ;-)
Faszinierend, dass es noch Leute gibt, die Lust dazu haben, was zu schreiben. Und man kann doch nur schreiben, was schon 7452mal geschrieben wurde. Aber Daumen hoch!
Nun, es ist doch mal wieder ein Anlass, die Verwendung "als selbstverständlich" vorausgesetzter Techniken zu hinterfragen und argumentativ zu formulieren. Auch wenn sich an den Argumenten seit damals eigentlich nichts geändert hat - aber schließlich beschäftigt sich ja nicht zwangsläufig jeder schon so lange mit der Materie.
Und ich bin mir sicher, dass es auch etliche Autoren gibt, die zwar CSS verwenden, aber eigentlich gar nicht so genau wissen, warum eigentlich.
Wobei mich persönlich heutzutage natürlich andere Fragen vielmehr interessieren. So z.B. die Frage, ob CSS als "eierlegende Wollmilchsau" wirklich auf Dauer die beste/ ideale Lösung ist?
Und du selbst hast ja eine ähnliche Thematik in deinem jüngsten Weblog-Artikel "Ignoriert den Browser nicht" angestoßen.
Gruß Gunther
Ich kann nur auf meinen Artikel http://aktuell.de.selfhtml.org/weblog/css-spaltenlayout von 2005/2006 verweisen, der die Frage »Tabellenlayout vs. CSS-Spalten« diskutiert.
Aha, einer, der alles schon früher weiß und vor allen Dingen schon vor Urzeiten ein für alle Mal endgültig geklärt hat. Daumen hoch, auch wenn es deinem überheblichen Gähnen noch besser zu Gesicht gestanden hätte, wenn du „1995/1996“ geschrieben hättest (ging natürlich nicht, ist klar).
Moin!
Aha, einer, der alles schon früher weiß und vor allen Dingen schon vor Urzeiten ein für alle Mal endgültig geklärt hat. Daumen hoch, auch wenn es deinem überheblichen Gähnen noch besser zu Gesicht gestanden hätte, wenn du „1995/1996“ geschrieben hättest (ging natürlich nicht, ist klar).
Und du meinst, deine gelangweilte Replik "Ja, du wußtest schon immer alles besser", ohne den verlinkten Inhalt auch nur wahrgenommen zu haben, kommt weniger überheblich rüber?
- Sven Rautenberg
Aha, einer, der alles schon früher weiß und vor allen Dingen schon vor Urzeiten ein für alle Mal endgültig geklärt hat. Daumen hoch, auch wenn es deinem überheblichen Gähnen noch besser zu Gesicht gestanden hätte, wenn du „1995/1996“ geschrieben hättest (ging natürlich nicht, ist klar).
Und du meinst, deine gelangweilte Replik "Ja, du wußtest schon immer alles besser", […], kommt weniger überheblich rüber?
Offenbar ist sie ja zumindest nicht als Reaktion à la "Seht, der Meister hat ob unseres nutzlosen Palavers gegähnt! Kniet nieder und staunet ob seiner schon vor langer Zeit errungenen Weisheiten!" rübergekommen, und mehr tut nicht not.
ohne den verlinkten Inhalt auch nur wahrgenommen zu haben
Ich hätte ihn womöglich wahrgenommen, hätte man ihn mir nicht mit einer "Hier, nimm meine alten Plünnen, geh damit fein spielen, auf das hier bald wieder Ruhe herrscht"-Geste vor die Füße geknallt.
Da ist mir gestern Abend noch eine Anmerkung von Stefan eingefallen, einmal schrieb, in diesem Forum ginge es ja nur noch wie beim Ping Pong zu, immer brav Frage, Antwort, Frage, Antwort. Auch wenn's Jahre her ist, Stefan sich inzwischen anders beschäftigt und der Satz ganz sicher nicht gar so ernst zu nehmen war: Ich find's amüsant, dass sich einer aus seiner Entourage jetzt darüber mokiert, hier würde diskutiert :->
Hallo,
Ich hätte ihn womöglich wahrgenommen, hätte man ihn mir nicht mit einer "Hier, nimm meine alten Plünnen, geh damit fein spielen, auf das hier bald wieder Ruhe herrscht"-Geste vor die Füße geknallt.
Es ging um die Frage, wie man zwei Spalten nebeneinanderbekommt und beide durchgehende Hintergrundfarben haben. Das ist ziemlich trivial, da kann ich nur sagen: RTFM, ob meinen Artikel oder siebentausend andere Tutorials im Netz zu dieser Frage. Und, wie ich schon sagte, über genauere Fragen muss man im Einzelnen diskutieren.
Ich find's amüsant, dass sich einer aus seiner Entourage jetzt darüber mokiert, hier würde diskutiert :->
Sorry, aber das ist Blödsinn.
Ich habe nichts gegen Diskutieren, sondern gegen Reden über etwas, als hätte noch nie jemand darüber nachgedacht, als gäbe es keine schriftlichen Zeugnisse darüber, als gäbe es keine abertausenden funktionierenden CSS-Layouts da draußen, die von vielen in einem Prozess erarbeiteten Techniken Gebrauch machen. Dieses Reden ist dann nichtmal wiederkäuen.
Mathias
Hallo,
der Meister hat ob unseres nutzlosen Palavers gegähnt!
Mal so gefragt: Für was ist diese Diskussion deiner Meinung nach nützlich?
Aber ja, ich gähne tatsächlich, denn bisher bin ich nicht sonderlich schlauer geworden aus diesem Thread hinsichtlich der Frage, was nun mit Tabellenlayout respektive CSS-Layout möglich bzw. unmöglich ist, weil sie auf einer äußerst abstrakten Ebene abläuft. Natürlich muss man sich über die Theorie streiten, das habe ich auch nie bezweifelt, sondern immer fleißig mitgemacht. Aber das ist etwas anderes, als die wichtige praktische Frage nach der konkreten technischen Umsetzung bestimmter realistischer Anforderungen. Dazu wurde hier bisher von beiden Seiten sehr viel heiße Luft produziert. Auf einer dermaßen allgemeinen Ebene kann man dazu m.E. nicht viel sinnvolles sagen.
Mathias
Hallo,
Versuchs doch mal mit Argumenten und gehe auf den Inhalt meiner Aussage ein, anstatt mir bloß Arroganz zu unterstellen.
Ich weise hier nicht ständig darauf hin, dass das Thema schon vor langer Zeit diskutiert wurde, um zu zeigen, was für ein Held ich bin. Dass ich irgendetwas früher als andere wusste, ist höchstens Zufall und völlig irrelevant. Aber tatsächlich ist vieles bereits geklärt, und darauf will ich hinweisen.
Wir befinden uns eben nicht mehr im Jahr 2001, sondern seitdem wurde viel Wissen erarbeitet und steht uns heute zur Verfügung. Deshalb müssen wir glücklicherweise nicht bei Null anfangen und das Rad mühsam neu erfinden. Diese Diskussion scheint mir hinter das Niveau von vor mehreren Jahren zurückzufallen.
Klar, nicht jeder ist solange dabei und kann sich daran erinnern, aber jeder kann recherchieren und würde darauf stoßen, dass diese Fragen schon detailreich und kontrovers diskutiert wurden. Man findet eine Fülle an CSS-Techniken einerseits und theoretische Diskussionen um Semantik und Trennung von Inhalt und Layout andererseits. Daran sollte man anknüpfen, wenn man eine Diskussion starten will, die auf der Höhe der Zeit ablaufen soll.
Ich schreibe an der SELFHTML-Dokumentation und hier im Forum mit, um Wissen festzuhalten und weiterzugeben. Wenn man dieses gespeicherte Wissen nicht abruft, dann ist man dazu verdammt, die gleichen Diskussionen zu führen, die 2001 erst am Anfang standen, als CSS-Layout noch als ein Ding von hartnäckigen Spinnern gehandelt wurde, weil grundlegende Praxistechniken noch nicht erarbeitet waren. Diese Diskussionen kann man meinetwegen führen, aber sie sind inhaltlich anachronistisch und verlieren Bezug zur Praxis.
Mathias
"gepredigt", statt Tabellen lieber Divisionen einzusetzen
Genau, Divisionen, Marsch, Marsch, der Feind steht ostwärts!!1
Wie würdest du sie denn bezeichnen?
Dabei entstehen Probleme. Entwickler wünschen sich, dass zwei Elemente gleich lang sind, also in der Höhe immer gleich groß sind, was meist bei dreispaltigen Layouts zum Einsatz kommen soll.
Durchaus ohne Handstand möglich, kommt aber zugegebenermaßen auf den Einzelfall an.
Sollte es aber nicht. Bei der Tabelle tut es das auch nicht. (oder hab ich "Einzelfall" falsch verstanden?)
Weiterhin wird sich gewünscht, dass der Footer auch dann ganz am Ende gezeigt wird, wenn der Inhalt und die restlichen Elemente nicht bis zum Ende des Dokuments reichen.
Da möchte ich hinterfragen, wer denn das Ende bei Webseiten definiert.
Ich habe mich falsch ausgedrückt. Dokument sollte Viewport sein. Aber du hast ja trotzdem verstanden, was ich meinte.
Die Antwort lautet (leider) immernoch: es ist nicht möglich!
Gegenfrage: Muss es denn möglich sein?
Ja! Mit CSS sollte (oder muss) jede menschenvorstellbare Formatierung möglich sein. Mit Tabellen geht's doch schließlich auch ;).
Ich möchte niemandem seinen Gestaltungswunsch in Abrede stellen, aber ich habe den Eindruck, dass sich die technischen Probleme bisweilen erst dadurch ergeben, dass jemand mit dem Kopf durch die Wand will und nicht vom Althergebrachten abweichen kann. „Aber ich mache doch seit Jahren dreispaltige Seiten …“
Bitte halte dich damit zurück. Keine meiner privaten Seiten hat ein Tabellenlayout als Grundgerüst.
Die Vorteile [des Tabellenlayouts] sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller)
Alles geht schnell, wenn man's erstmal kann. Die Systematik des Tabellenlayouts ist lediglich leichter zu durchblicken.
In manchen Fällen geht's mit Tabellen schneller, in manchen mit CSS. Ich bezog mich nur auf erstere Fälle. Oder behauptest du, dass es die nicht gibt?
Nun kann man darüber streiten, ob es "schlimmer" ist, eine Tabelle zur Formatierung einzusetzen oder etliche sinnfreie überflüssige Divisionen in Quelltext zu haben, die letztendlich auch nur der Formatierung dienen, obwohl wir genau _das_ verhindern wollten.
Du irrst. Eine Tabelle hat eine Aussage, sie stellt ihre Inhalte in eine Beziehung zueinander. Die Eigenschaft der Elemente <div> und <span> ist gerade, dass sie letztlich (fast) keine haben, ihr einziger Zweck _ist_ die Formatierung.
Deshalb wundert mich deine Verwendung des Wörtchens Semantik (Sinn, Bedeutung) oben. <div> und <span> sind dazu da, Bereiche mehr oder weniger bedeutungslos zu gruppieren, im Gegensatz zu beispielsweise dem <p>, das einen Absatz kennzeichnet.
Ja, das ist schon schlimm genug. Schlimmer noch, es gibt dann zusätzliche sinnlose inhaltslose Elemente.
So, wie du auf dem <div> rumreitest, habe ich den Verdacht, dass es dir nicht um CSS geht, sondern du vielmehr der weitverbreiteten <div>-Wüste aufgesessen bist, einer Seite, die fast ausschließlich aus <div>s und <span>s besteht und sich nicht um den Einsatz besser passende Elemente kümmert - genau das ist aber nicht im Sinne der Entwickler.
Du hast folgendes in meinem Posting überlesen: "(oder andere Elemente, je nach Einsatzzweck)". Das weitere erspart sich dann wohl. Wirf mir nicht vor, ich würde mich nicht auskennen.
"gepredigt", statt Tabellen lieber Divisionen einzusetzen
Genau, Divisionen, Marsch, Marsch, der Feind steht ostwärts!!1
Wie würdest du sie denn bezeichnen?
Als <div>-Elemente. Eine Division ist eine mathematische Operation oder eine militärische Einheit, selten noch darüber hinaus eine allgemeine Organisationsform. Im Deutschen bezeichnet niemand einen halben Apfel als Apfeldivision, ein Grundstück als Flächendivision oder einen Bereich auf einem Blatt Papier als Papierdivision. IMO beinahe ein typischer Fall von nicht durchdachter Übersetzung aus dem Englischen, neigt sich schon leicht in Richtung Moonshine-Tarif.
Entwickler wünschen sich, dass zwei Elemente gleich lang sind, also in der Höhe immer gleich groß sind, was meist bei dreispaltigen Layouts zum Einsatz kommen soll.
Durchaus ohne Handstand möglich, kommt aber zugegebenermaßen auf den Einzelfall an.
Sollte es aber nicht.
Richtig, sollte es nicht. Man kann's aber versuchen oder sich eine Alternative ausdenken, die dem Medium besser steht. Wer sagt denn, dass die drei Spalten, die in der Tabelle auf Gedeih und Verderb nebeneinander stehen müssen, in allen Browserfenstern auch Platz haben? Beim üblichen CSS-Äquivalent kein Problem, dann rutscht eine Spalte nach unten. Es ist nicht so, dass Tabellen „häufig besser“ wären als CSS, das eine kann wie das andere Nachteile haben, auch schwerwiegende.
Weiterhin wird sich gewünscht, dass der Footer auch dann ganz am Ende gezeigt wird
Dokument sollte Viewport sein.
Da hast du nun ein grundsätzliches Problem, nämlich dass ein Dokument mal so, mal so lang sein kann, je nachdem, wie groß der Inhalt (lies: die vom Leser gewählte Schriftgröße) ist und wie klein sich im Verhaltnis dazu die Anzeigefläche gibt.
Sicherlich ist es in mancher Gestaltungshinsicht wünschenswert, das Fenster quasi wie ein Blatt Papier als abgeschlossenen Bereich anzusehen, das beißt sich aber mit der grundsätzlichen Auslegung von HTML als anzeigeunabhängigem Format, und zwar sowohl beim Tabellen- wie auch beim CSS-Layout.
Die Antwort lautet (leider) immernoch: es ist nicht möglich!
Gegenfrage: Muss es denn möglich sein?
Ja! Mit CSS sollte (oder muss) jede menschenvorstellbare Formatierung möglich sein.
Finde ich in dieser Absolutheit nicht. Wer ein Dokument zum Beispiel zu Papier bringen möchte, sollte auch ein auf die Eigenschaften der Papierausgabe ausgerichtetes Werkzeug benutzen. HTML und CSS sind das nicht, sie konzentrieren sich auf universelle Einsetzbarkeit. Gelegentliche Einschränkungen sind unvermeidbar, hier wie dort.
Das soll nun nicht bedeuten, dass CSS nicht noch verbessert werden könnte, lediglich, dass man sich gewissen Gegebenheiten in der Praxis anpassen muss, womit ich wieder beim Grundtenor wäre:
Ich möchte niemandem seinen Gestaltungswunsch in Abrede stellen, aber ich habe den Eindruck, dass sich die technischen Probleme bisweilen erst dadurch ergeben, dass jemand mit dem Kopf durch die Wand will und nicht vom Althergebrachten abweichen kann. „Aber ich mache doch seit Jahren dreispaltige Seiten …“
Man kann nicht einfach bekannte Layoutprozedere 1:1 von einem Medium in ein anderes übertragen und davon ausgehen, alles bliebe beim Alten. Die drei Spalten, die unbedingt nebeneinander stehen müssen, das Seitenende, dass unbedingt mit dem Ende des Anzeigebereichs übereinstimmen muss, das sind erst einmal Beispiele, die aus der Papierwelt kommen und nicht zwangsläufig 1:1 in einer flexiblen Ausgabe anwendbar sind.
Und genau da liegt meiner Meinung nach die Ursache, nicht primär in der eingeschränkten Funktionalität von CSS. Wer unbedingt eine Tabelle als Layoutmittel nutzen möchte, soll das von mir aus in Dreigottesnamen tun, aber nicht behaupten, er hätte ja überhaupt und ganz und gar keine andere Wahl. Die Wahl fängt nur nicht erst bei der Technik an, sondern schon vorher bei der Gestaltungsidee.
Bitte halte dich damit zurück. Keine meiner privaten Seiten hat ein Tabellenlayout als Grundgerüst.
Habe ich behauptet, dass das bei dir so ist? Wenn dir ein Argument unangenehm ist und du jede Gegenrede persönlich nimmst, halte du dich damit zurück.
Die Vorteile [des Tabellenlayouts] sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller)
Alles geht schnell, wenn man's erstmal kann. Die Systematik des Tabellenlayouts ist lediglich leichter zu durchblicken.
In manchen Fällen geht's mit Tabellen schneller, in manchen mit CSS. Ich bezog mich nur auf erstere Fälle. Oder behauptest du, dass es die nicht gibt?
Ich schrieb doch: Alles geht schnell, wenn man's kann. Wie sollte ich da behaupten können, es gäbe keine Fälle, in denen es mit Tabellen schneller ginge?
Hallo,
Als <div>-Elemente. Eine Division ist eine mathematische Operation [...]
„div-Elemente“ oder „<div>“ macht imho mehr Sinn. Die Spitzklammern weisen ja schon darauf hin, dass es sich um ein Element handelt.
Nebenbei: der Elementname „div“ stammt aus HTML 3 und ist die Abkürzung für „contnent division“. Das Element ist als allgemeines blockelement definiert, das zur Gruppierung anderer Elemente und als Gestaltungshilfe bei der Verwendung von Stylesheets gedacht.
Gruß
"gepredigt", statt Tabellen lieber Divisionen einzusetzen
Genau, Divisionen, Marsch, Marsch, der Feind steht ostwärts!!1
Wie würdest du sie denn bezeichnen?
Als <div>-Elemente. Eine Division ist eine mathematische Operation oder eine militärische Einheit, selten noch darüber hinaus eine allgemeine Organisationsform.
Ich habe kein Problem damit, Sprachen zu vermischen.
Weiterhin wird sich gewünscht, dass der Footer auch dann ganz am Ende gezeigt wird
Dokument sollte Viewport sein.
Da hast du nun ein grundsätzliches Problem, nämlich dass ein Dokument mal so, mal so lang sein kann, je nachdem, wie groß der Inhalt (lies: die vom Leser gewählte Schriftgröße) ist und wie klein sich im Verhaltnis dazu die Anzeigefläche gibt.
Musst du mir jedes Wort im Mund umdrehen? Du weißt, dass ich meinte, dass der Viewport _mindestens_ so groß sein muss. Größer kann er auch sein.
Sicherlich ist es in mancher Gestaltungshinsicht wünschenswert, das Fenster quasi wie ein Blatt Papier als abgeschlossenen Bereich anzusehen, das beißt sich aber mit der grundsätzlichen Auslegung von HTML als anzeigeunabhängigem Format, und zwar sowohl beim Tabellen- wie auch beim CSS-Layout.
Wieso?
Die Antwort lautet (leider) immernoch: es ist nicht möglich!
Gegenfrage: Muss es denn möglich sein?
Ja! Mit CSS sollte (oder muss) jede menschenvorstellbare Formatierung möglich sein.
Finde ich in dieser Absolutheit nicht. Wer ein Dokument zum Beispiel zu Papier bringen möchte, sollte auch ein auf die Eigenschaften der Papierausgabe ausgerichtetes Werkzeug benutzen.
Klar. Wir reden hier aber momentan über die Anzeige in einem handelsüblichen Monitor. Der Entwickler kann seine Seite für andere Anzeigegeräte immernoch ändern (z.B. für einen Ausdruck). Aber der Entwickler kann nicht mal bei *einem* Ausgabegerät alles tun, was er möchte. Warum nicht? Und sag mir nicht, dass das gut sei.
Ich möchte niemandem seinen Gestaltungswunsch in Abrede stellen, aber ich habe den Eindruck, dass sich die technischen Probleme bisweilen erst dadurch ergeben, dass jemand mit dem Kopf durch die Wand will und nicht vom Althergebrachten abweichen kann. „Aber ich mache doch seit Jahren dreispaltige Seiten …“
Man kann nicht einfach bekannte Layoutprozedere 1:1 von einem Medium in ein anderes übertragen und davon ausgehen, alles bliebe beim Alten.
Das war mir auch vorher bewusst...
Die drei Spalten, die unbedingt nebeneinander stehen müssen, das Seitenende, dass unbedingt mit dem Ende des Anzeigebereichs übereinstimmen muss, das sind erst einmal Beispiele, die aus der Papierwelt kommen
Irrtum, die kommen aus der Gedankenwelt. Und dann werden sie auf die Papierwelt oder irgendeine andere Welt (eine elektronische Anzeigewelt) angepasst.
Die Wahl fängt nur nicht erst bei der Technik an, sondern schon vorher bei der Gestaltungsidee.
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat. Sie soll so breit sein, wie der darin enthaltene Inhalt, nicht kleiner, nicht größer. Rechts daneben soll der restliche Platz durch einen anderen Text ausgefüllt werden. Die Navigation soll den Text _nicht_ verdecken.
Das ist momentan mit CSS nicht möglich. Und das hat _sicherlich_ nichts mit einer Papierwelt zu tun.
Bitte halte dich damit zurück. Keine meiner privaten Seiten hat ein Tabellenlayout als Grundgerüst.
Habe ich behauptet, dass das bei dir so ist?
Ja, implizit.
Ich kann auch sagen "du erinnerst mich an jemanden, der ein totales ***** ist". Und dann sage ich "aber nur, weil du so blaue Augen hast, du bist für mich kein *****"...
Die Vorteile [des Tabellenlayouts] sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller)
Alles geht schnell, wenn man's erstmal kann. Die Systematik des Tabellenlayouts ist lediglich leichter zu durchblicken.
Ich behaupte, dass es länger dauert die ganzen CSS Hacks abzutippten, als die Tabelle abzutippen. Ergo... äh, also geht's schneller.
Hallo Die_Antwort
… Aber der Entwickler kann nicht mal bei *einem* Ausgabegerät alles tun, was er möchte. Warum nicht? Und sag mir nicht, dass das gut sei.
Bei Tabellenlayout kann er _alles_ tun, ohne jede Einschränkung?
Irrtum, die kommen aus der Gedankenwelt. …
Die sehr stark von der gewohnten Papierwelt und von der (dank Tebellenlayout) auch aufs Web übertragenen Papierwelt geprägt ist.
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat. Sie soll so breit sein, wie der darin enthaltene Inhalt, nicht kleiner, nicht größer. Rechts daneben soll der restliche Platz durch einen anderen Text ausgefüllt werden. Die Navigation soll den Text _nicht_ verdecken.
Das ist momentan mit CSS nicht möglich. Und das hat _sicherlich_ nichts mit einer Papierwelt zu tun.
Und ich warte seit 15:32 darauf, dass du mir zeigst, wie dies mittels Tabellenlayout umgesetzt werden kann.
Ich behaupte, dass es länger dauert die ganzen CSS Hacks abzutippten, als die Tabelle abzutippen. Ergo... äh, also geht's schneller.
Die CSS Hacks tippe ich genau ein mal, die Tabellen auf jeder einzelnen Seite.
Auf Wiederlesen
Detlef
Hi,
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
Also moechtest du, dass sie *nicht* mit dem restlichen Seiteninhalt mitscrollt.
Sie soll so breit sein, wie der darin enthaltene Inhalt, nicht kleiner, nicht größer. Rechts daneben soll der restliche Platz durch einen anderen Text ausgefüllt werden. Die Navigation soll den Text _nicht_ verdecken.
Da ist ein Kompromiss erforderlich, ja - z.B. die Abschaetzung der Breite, die fuer die Navigation benoetigt wird.
Das ist momentan mit CSS nicht möglich.
Mit der Tabelle genauso wenig [1] - oder trittst du jetzt *endlich* mal denen Gegenbeweis an, statt dich in der Wiederholung reichlich unsinniger Pseudo-Argumente zu ergehen ...?
[1] Bezogen auf die Fixierung, nicht die Breite.
MfG ChrisB
Hi,
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
Also moechtest du, dass sie *nicht* mit dem restlichen Seiteninhalt mitscrollt.
Sie soll so breit sein, wie der darin enthaltene Inhalt, nicht kleiner, nicht größer. Rechts daneben soll der restliche Platz durch einen anderen Text ausgefüllt werden. Die Navigation soll den Text _nicht_ verdecken.
Da ist ein Kompromiss erforderlich, ja - z.B. die Abschaetzung der Breite, die fuer die Navigation benoetigt wird.
Was macht man, wenn die Navigation dynamisch generiert wird und man nicht weiß, wie lang der längste Punkt sein wird?
Das ist momentan mit CSS nicht möglich.
Mit der Tabelle genauso wenig [1] - oder trittst du jetzt *endlich* mal denen Gegenbeweis an, statt dich in der Wiederholung reichlich unsinniger Pseudo-Argumente zu ergehen ...?
Nein, habe ich auch nicht behauptet. In diesem Diskussionsfaden wollte ich nur aufzeigen, dass CSS eben nicht dazu in der Lage ist _alles_ umzusetzen, was man sich vorzustellen vermag. Mit Tabellen _und_ CSS geht auch nicht alles, aber deutlich mehr.
Hi,
Da ist ein Kompromiss erforderlich, ja - z.B. die Abschaetzung der Breite, die fuer die Navigation benoetigt wird.
Was macht man, wenn die Navigation dynamisch generiert wird und man nicht weiß, wie lang der längste Punkt sein wird?
Das, was ich sagte: *Abschaetzen*
Und dann ggf. *bei* der dynamischen Generierung entsprechende korrigierende Gegenmasznahmen ergreifen.
Mit der Tabelle genauso wenig [1] - oder trittst du jetzt *endlich* mal denen Gegenbeweis an, statt dich in der Wiederholung reichlich unsinniger Pseudo-Argumente zu ergehen ...?
Nein, habe ich auch nicht behauptet. In diesem Diskussionsfaden wollte ich nur aufzeigen, dass CSS eben nicht dazu in der Lage ist _alles_ umzusetzen, was man sich vorzustellen vermag. Mit Tabellen _und_ CSS geht auch nicht alles, aber deutlich mehr.
Auch mit den in die Tabelle gesteckten Daten *und* CSS moechte ich dich immer noch die Fixierung (browseruebergreifend) umsetzen sehen.
Anernfalls wuerde ich dich gerne auf Pseudoargumente verzichten sehen, die sich bei genauerer Betrachtung als heisse Luft herausstellen - besteht bzgl. dieses Punktes eventuell ein kleines bisschen berechtigter Hoffnung?
MfG ChrisB
Hi,
Da ist ein Kompromiss erforderlich, ja - z.B. die Abschaetzung der Breite, die fuer die Navigation benoetigt wird.
Was macht man, wenn die Navigation dynamisch generiert wird und man nicht weiß, wie lang der längste Punkt sein wird?
Das, was ich sagte: *Abschaetzen*
Wie soll das gehen? Schätzt du viel Platz für die Navigation ein, sie ist aber sehr klein, vergeudest du viel Anzeigefläche.
Und dann ggf. *bei* der dynamischen Generierung entsprechende korrigierende Gegenmasznahmen ergreifen.
_Dann_ verschmischt du aber wieder Design und Funtkion.
Mit der Tabelle genauso wenig [1] - oder trittst du jetzt *endlich* mal denen Gegenbeweis an, statt dich in der Wiederholung reichlich unsinniger Pseudo-Argumente zu ergehen ...?
Nein, habe ich auch nicht behauptet. In diesem Diskussionsfaden wollte ich nur aufzeigen, dass CSS eben nicht dazu in der Lage ist _alles_ umzusetzen, was man sich vorzustellen vermag. Mit Tabellen _und_ CSS geht auch nicht alles, aber deutlich mehr.
Auch mit den in die Tabelle gesteckten Daten *und* CSS moechte ich dich immer noch die Fixierung (browseruebergreifend) umsetzen sehen.
Soll ich mich selbst nochmal zitieren???
Du: »» »» »» [das geht] Mit der Tabelle genauso wenig
Ich: »» »» Nein, habe ich auch nicht behauptet.
Anernfalls wuerde ich dich gerne auf Pseudoargumente verzichten sehen, die sich bei genauerer Betrachtung als heisse Luft herausstellen - besteht bzgl. dieses Punktes eventuell ein kleines bisschen berechtigter Hoffnung?
Was für Pseudoargumente? "Mit Tabellen und CSS kann man mehr machen als mit CSS alleine" = Pseudoargument?
Hi,
Was für Pseudoargumente? "Mit Tabellen und CSS kann man mehr machen als mit CSS alleine" = Pseudoargument?
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
MfG ChrisB
Hi,
Was für Pseudoargumente? "Mit Tabellen und CSS kann man mehr machen als mit CSS alleine" = Pseudoargument?
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
- absolut kein Zusammenhang damit, ob diese Navigation nun mittels Tabellenzelle(n) ausgezeichnet wird oder nicht == Nullargument.
Diesen Zusammenhang sollte es auch gar nicht haben. Dir ist klar, worüber in diesem Diskussionsfaden geredet wird?
Hi,
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
- absolut kein Zusammenhang damit, ob diese Navigation nun mittels Tabellenzelle(n) ausgezeichnet wird oder nicht == Nullargument.
Diesen Zusammenhang sollte es auch gar nicht haben.
Zum wiederholten Male die Frage: *Warum* *bringst* *du* *es* *dann* *als* *vermeintliches* *Argument*?
Die einzig mir plausible Erklaerung dafuer lautet: Weil dir alle anderen (echten) laengst ausgegangen sind.
MfG ChrisB
Hi,
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
- absolut kein Zusammenhang damit, ob diese Navigation nun mittels Tabellenzelle(n) ausgezeichnet wird oder nicht == Nullargument.
Diesen Zusammenhang sollte es auch gar nicht haben.
Zum wiederholten Male die Frage: *Warum* *bringst* *du* *es* *dann* *als* *vermeintliches* *Argument*?
Um zu zeigen, dass CSS noch wesentliche Schwächen hat und es nicht (wie manche meinen) fast schon ausreicht und höchstens noch an kleinen Stellen verbessert werden müsste.
Die einzig mir plausible Erklaerung dafuer lautet: Weil dir alle anderen (echten) laengst ausgegangen sind.
Du meinst: die einzig _dir_ plausible (...).
Hi,
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
- absolut kein Zusammenhang damit, ob diese Navigation nun mittels Tabellenzelle(n) ausgezeichnet wird oder nicht == Nullargument.
Diesen Zusammenhang sollte es auch gar nicht haben.
Zum wiederholten Male die Frage: *Warum* *bringst* *du* *es* *dann* *als* *vermeintliches* *Argument*?
Um zu zeigen, dass CSS noch wesentliche Schwächen hat und es nicht (wie manche meinen) fast schon ausreicht und höchstens noch an kleinen Stellen verbessert werden müsste.
Mit CSS kann ich die Fixierung sehr einfach umsetzen.
Wie du das mit der Tabelle machst (ohne *ganz* fiese Workarounds), hast du immer noch nicht beschreiben koennen.
Also ist eine wesentliche Schwaeche der Tabelle damit klar herausgearbeitet, Danke.
MfG ChrisB
Hi,
Ich möchte eine Navigation auf der linken Seite haben, die mitscrollt, also "position:fixed;" hat.
- absolut kein Zusammenhang damit, ob diese Navigation nun mittels Tabellenzelle(n) ausgezeichnet wird oder nicht == Nullargument.
Diesen Zusammenhang sollte es auch gar nicht haben.
Zum wiederholten Male die Frage: *Warum* *bringst* *du* *es* *dann* *als* *vermeintliches* *Argument*?
Um zu zeigen, dass CSS noch wesentliche Schwächen hat und es nicht (wie manche meinen) fast schon ausreicht und höchstens noch an kleinen Stellen verbessert werden müsste.
Mit CSS kann ich die Fixierung sehr einfach umsetzen.
Nicht wenn die Größe der Navigation vom Inhalt abhängt. Falls doch: das will ich sehen.
Wie du das mit der Tabelle machst (ohne *ganz* fiese Workarounds), hast du immer noch nicht beschreiben koennen.
Also ist eine wesentliche Schwaeche der Tabelle damit klar herausgearbeitet, Danke.
Ja, ich habe gar nicht den Anspruch, dass die Tabelle das alleine kann. Das können die Tabelle _und_ CSS ja nicht mal gemeinsam (ohne fiese Tricks).
Hi,
Mit CSS kann ich die Fixierung sehr einfach umsetzen.
Nicht wenn die Größe der Navigation vom Inhalt abhängt.
Du meinst jetzt wieder die Breite, ja?
Ich schrieb bereits, dass hier eine vorgegebene Breite der Kompromiss waere, den ich fuer vernuenftig halten und damit einzugehen bereit waere.
Ja, ich habe gar nicht den Anspruch, dass die Tabelle das alleine kann. Das können die Tabelle _und_ CSS ja nicht mal gemeinsam (ohne fiese Tricks).
Also halten wir jetzt aber mal endgueltig fest, dass uns deine Tabelle hier keinerlei Vorteil braechte, und wir stattdessen in diesem Falle also gerne sinnvollere Elemente im HTML verwenden koennen.
Oder willst du dich um die Anerkennung dieser Aussage jetzt auch wieder herumwinden?
MfG ChrisB
Hi,
Mit CSS kann ich die Fixierung sehr einfach umsetzen.
Nicht wenn die Größe der Navigation vom Inhalt abhängt.
Du meinst jetzt wieder die Breite, ja?
Ich schrieb bereits, dass hier eine vorgegebene Breite der Kompromiss waere, den ich fuer vernuenftig halten und damit einzugehen bereit waere.
Ja, ich habe gar nicht den Anspruch, dass die Tabelle das alleine kann. Das können die Tabelle _und_ CSS ja nicht mal gemeinsam (ohne fiese Tricks).
Also halten wir jetzt aber mal endgueltig fest, dass uns deine Tabelle hier keinerlei Vorteil braechte,
Ja.
und wir stattdessen in diesem Falle also gerne sinnvollere Elemente im HTML verwenden koennen.
Nö. Die helfen uns auch nicht. Nur Javascript könnte jetzt noch etwas bewegen.
Moin!
Das ist momentan mit CSS nicht möglich.
Mit der Tabelle genauso wenig [1] - oder trittst du jetzt *endlich* mal denen Gegenbeweis an, statt dich in der Wiederholung reichlich unsinniger Pseudo-Argumente zu ergehen ...?
Nein, habe ich auch nicht behauptet. In diesem Diskussionsfaden wollte ich nur aufzeigen, dass CSS eben nicht dazu in der Lage ist _alles_ umzusetzen, was man sich vorzustellen vermag. Mit Tabellen _und_ CSS geht auch nicht alles, aber deutlich mehr.
Sorry, aber diese Aussage ist in dieser Form einfach falsch.
Technisch gesehen sind Tabellen auch nur stinknormale HTML-Elemente, die eine bestimmte Vorformatierung durch CSS genießen.
Technisch unterscheidet es sich also überhaupt nicht, ob man <table>, <tr> und <td> benutzt, oder <div>, <div> und <div>. Siehe dazu auch <http://de.selfhtml.org/css/eigenschaften/positionierung.htm#display@title=das DIV-Tabellen-Beispiel in SELFHTML>.
Allerdings unterscheidet sich die Umsetzung dieser Technik in den Browsern. IE6 und 7 scheitern. Nur deshalb ist es derzeit unmöglich, mit "beliebigem HTML und CSS" Tabellen nachzumachen. Und umgekehrt ist es unmöglich, HTML-Tabellen "beliebig mit CSS" zu stylen. Weil dort spezieller Programmcode zum Zuge kommt, wenn HTML-Tabellen im Spiel sind.
Insofern muß man konstatieren: HTML-Tabellen sind durch nichts zu ersetzen, wenn man deren Eigenschaften benötigt.
Allerdings benötigt man deren Eigenschaften nur äußerst selten für Layoutzwecke. Und eigentlich nie für Layouts, die keine tabellarischen Daten darstellen.
- Sven Rautenberg
Moin!
Das ist momentan mit CSS nicht möglich.
Mit der Tabelle genauso wenig [1] - oder trittst du jetzt *endlich* mal denen Gegenbeweis an, statt dich in der Wiederholung reichlich unsinniger Pseudo-Argumente zu ergehen ...?
Nein, habe ich auch nicht behauptet. In diesem Diskussionsfaden wollte ich nur aufzeigen, dass CSS eben nicht dazu in der Lage ist _alles_ umzusetzen, was man sich vorzustellen vermag. Mit Tabellen _und_ CSS geht auch nicht alles, aber deutlich mehr.
Sorry, aber diese Aussage ist in dieser Form einfach falsch.
(...)
Allerdings benötigt man deren Eigenschaften nur äußerst selten für Layoutzwecke.
Aber manchmal schon, weshalb die Aussage auch nicht falsch ist.
Hi,
Ja! Mit CSS sollte (oder muss) jede menschenvorstellbare Formatierung möglich sein. Mit Tabellen geht's doch schließlich auch ;).
https://forum.selfhtml.org/?t=168670&m=1100688, letzter Absatz.
Auf deine Umsetzung der Anforderung mittels (d)einer Tabelle warte ich noch.
MfG ChrisB
Hi there,
genau das ist aber nicht im Sinne der Entwickler.
Öhm, was ist mir, was die Entwickler im Sinne hatten? Die ganzen Für's und Wider's sind, wie Molily schreibt, ohnehin schon genug durchgekaut worden, der Sinn der Entwickler ist in dem Zusammenhang aber ein neuer Aspekt. Es ist letzten Endes doch nur das Ergebnis, das zählt. Und vielleicht fällt mir zur der einen oder anderen Anforderung ein Lösungsweg ein, an den die Entwickler nicht im Entferntesten gedacht hätten. Soll ich vielleicht deshalb hergehen und sagen, schade, gute Idee, war aber nix, weil das ja nicht im Sinne der Entwickler ist?
Es ist nicht so, dass Tabellen grundsätzlich pfui sind. Ganz im Gegenteil, mittlerweile kann man über Fälle stolpern, in denen eine Tabelle in jeglicher Hinsicht hervorragend geeignet wäre, der Autor aber meinte, auf Teufel komm raus alles in <div>s zu würgen, „weil ich doch kein Tabellenlayout haben will“. Das ist natürlich auch Unsinn.
Das kann nur Leuten passieren, die hier regelmäßig mitlesen. Ein normaler Autor entwickelt solche Berührungsängste erst gar nicht;)
genau das ist aber nicht im Sinne der Entwickler.
Öhm, was ist mir, was die Entwickler im Sinne hatten?
Das ist eine Redewendung, die so viel bedeuten soll wie: „Wenn jemand mit etwas entgegen des angedachten Verwendungszweckes Bockmist baut, dann soll er von mir aus tun, aber möge diesen Bockmist doch bitte nicht als Argument gegen das Etwas einsetzen.“
Du kannst auch mit einem Auto gegen einen Baum fahren, das ist aber kein Argument gegen Autos, da sie als Verkehrsmittel gedacht sind, nicht als Baumbummser.
Hi there,
Öhm, was ist mir, was die Entwickler im Sinne hatten?
Das ist eine Redewendung, die so viel bedeuten soll wie: „Wenn jemand mit etwas entgegen des angedachten Verwendungszweckes Bockmist baut, dann soll er von mir aus tun, aber möge diesen Bockmist doch bitte nicht als Argument gegen das Etwas einsetzen.“
Es geht aber genau um dieses "von mir aus tun", nichts anderes.
Du kannst auch mit einem Auto gegen einen Baum fahren, das ist aber kein Argument gegen Autos, da sie als Verkehrsmittel gedacht sind, nicht als Baumbummser.
Rallycross-Fahrer würden Dir da widersprechen...
Hallo,
statt Tabellen lieber Divisionen einzusetzen
Frieden schaffen ohne Waffen.
Mathias
Hallo,
statt Tabellen lieber Divisionen einzusetzen
Frieden schaffen ohne Waffen.
;)
Hi there,
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen. Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Hat etwas für sich. Abgesehen davon, daß sich die Browser in den Mobiltelefonen (Symbian bspw.) mit Tabellenlayouts wesentlich leichter tun. Entscheidend ist, man muss halt immer wissen, was wofür gedacht ist. Generell sollte man sich so etwas Unwichtigem wie Webdesign nur pragmatisch und nie dogmatisch näheren...
Hallo,
Abgesehen davon, daß sich die Browser in den Mobiltelefonen (Symbian bspw.) mit Tabellenlayouts wesentlich leichter tun.
Das kann man m.W. nicht so generalisieren. Ein aktueller Browser für SymbianOS ist Opera Mobile, der alle möglichen Layouts vernünftig linearisieren kann. Und IE Mobile, ein anderer verbreiteter Handheld-Browser, hat ziemliche Probleme mit Tabellenlayout gegenüber CSS-Spaltenlayout. Da gabs auch mal einen Thread zu, wo Screenshots gepostet wurden.
Mathias
Hi there,
Das kann man m.W. nicht so generalisieren. Ein aktueller Browser für SymbianOS ist Opera Mobile, der alle möglichen Layouts vernünftig linearisieren kann.
Ja, der Opera macht das ziemlich gut. Aber die in die Ericsson 9xx-Serie eingebauten Browser können css-Designs ebensowenig passabel darstellen wie die Browser in den Motorola-Telefonen der A-Serie. Möglich, daß das bei den Geräten der neuesten Generation schon besser ist. Aber die die von mir beschriebenen Telefontypen sind noch ziemlich verbreitet. (Lustigerweise haben die von mir genannten Browser mit javascript und dem DOM keine Probleme ;)
Hallo,
die in die Ericsson 9xx-Serie eingebauten Browser können css-Designs ebensowenig passabel darstellen wie die Browser in den Motorola-Telefonen der A-Serie.
Wie gehen sie denn mit Layouttabellen um? Linearisieren sie sie?
Und wie gehen sie mit float um? Nicht linearisieren? (Sinn?! ;))
Mathias
Hi there,
Wie gehen sie denn mit Layouttabellen um? Linearisieren sie sie?
Was meinst Du im Zusammenhang mit Tabellen mit linearisieren? Tabellen werden nicht anders als in herkömmlichen Browsern dargestellte; reicht der Platz nicht aus, was bei dieser Display-Auflösung natürlich öfter der Fall ist, muss halt horizontal gescrollt werden.
Im Detail kann ich Dir sagen, daß ich (kann ja immer sein, daß man es einmal benötigt;)) die vorige Version von selfhtml auf einer Speicherkarte als Nachschlagwerk habe, und die Darstellung ist bei einer Auflösung (ja, lieber Cheatah, es gibt Ausgabegeräte, da hängt die Darstellung von der Bildschirmauflösung ab!;) von 220x340px brauchbar. Irgendwo im Netz gab es einmal (oder gibt es) eine selfhtml-Version, die mit Stylesheetlayout realisiert wurde, und da wurde soweit überhaupt nichts angezeigt.
Und wie gehen sie mit float um? Nicht linearisieren? (Sinn?! ;))
Was meinst Du in dem Zusammenhang mit float?
Hallo,
ah, okay, habe auch den Thread wiedergefunden:
</archiv/2006/3/t126176/#m813674>
Wobei der Fehler dort eher nach Problemen mit XHTML klingt.
Was meinst Du im Zusammenhang mit Tabellen mit linearisieren?
Spalten untereinander statt nebeneinander anzeigen, wenn die Breite des Displays für ein lesbares Nebeneinander nicht ausreicht.
Was meinst Du in dem Zusammenhang mit float?
Naja, ob sie Mehrspaltigkeit / Nebeneinander mit float mit festen Breiten ebenso rigide umsetzen wie Tabellenlayout.
Mathias
Hi there,
</archiv/2006/3/t126176/#m813674>
ja, erinnere mich wieder;)
Spalten untereinander statt nebeneinander anzeigen, wenn die Breite des Displays für ein lesbares Nebeneinander nicht ausreicht.
ich bin mir nicht sicher, ob das ein Verhalten wäre, das in dem Zusammenhang gewünscht wäre.
Naja, ob sie Mehrspaltigkeit / Nebeneinander mit float mit festen Breiten ebenso rigide umsetzen wie Tabellenlayout.
Kann ich Dir adhoc nicht beantworten. Aber wenn es Dich interessiert, wäre ich bereit, es auszuprobieren resp. Screenshots anzufertigen. Eigentlich interessant, muss ich wirklich einmal schauen, was auf dem Telephon anders dargestellt wird als bei wenn ich zB mit body {width:220px} die Horizontalbreite des Handys "simuliere"...
... die Darstellung ist bei einer Auflösung (ja, lieber Cheatah, es gibt Ausgabegeräte, da hängt die Darstellung von der Bildschirmauflösung ab!;) von 220x340px brauchbar.
Nein hat sie nicht, sie hängt von der Größe des Viewport ab, du kannst ein kleines Fenster auch ohne Probleme bei jeder anderen Bildschirmauflösung einstellen.
Struppi.
Hi there.
Nein hat sie nicht, sie hängt von der Größe des Viewport ab, du kannst ein kleines Fenster auch ohne Probleme bei jeder anderen Bildschirmauflösung einstellen.
Na, dann stell einmal den Viewport ein, auf einem Telefon...
Moin!
[…]
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Funktion einer Tabelle: Inhalte _tabellarisch_ darstellen. Die von dir vorgeschlagenen Inhalte haben semantisch aber gar nichts Tabellarisches. Außerdem ein großer Vorteil von CSS-Layouts: Stell dir vor, du willst später die Navigation nicht links an der Seite sondern als Breadcrumb oben drüber. Mit CSS erfordert das keinerlei Code-Änderung in der HTML-Datei. Mit Tabellen …?
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen. Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Weißt du, was HTML bedeutet? Kleiner Tipp: Das L steht für Language, nicht Layout.
Frohe Ostern,
Robert
Moin!
[…]
Die Vorteile sind nicht nur das schnellere Entwickeln (ja, es _geht_ schneller) und die bessere Browserkompatibilität, sondern es lassen sich immernoch Funktion und Layout voneinander trennen.
Funktion einer Tabelle: Inhalte _tabellarisch_ darstellen. Die von dir vorgeschlagenen Inhalte haben semantisch aber gar nichts Tabellarisches.
Du erzählst mir nichts neues. Vielleicht ist es aus meinem Beitrag nicht deutlich geworden, aber ich weiß genau, warum man Tabellen eigentlich nicht einsetzen sollte.
Außerdem ein großer Vorteil von CSS-Layouts: Stell dir vor, du willst später die Navigation nicht links an der Seite sondern als Breadcrumb oben drüber. Mit CSS erfordert das keinerlei Code-Änderung in der HTML-Datei. Mit Tabellen …?
… erfordert es mich nicht mal eine Minute. Der der Gewinn, der mir bleibt, weil ich nicht tausende Hacks nachschlagen und ausprobieren muss, bleibt groß.
Ich sage deshalb: benutzt Tabellen, statt CSS, wenn es mit CSS nicht semantischer geht als mit Tabellen. Und bis das W3C und die Browserhersteller es endlich geschafft haben, ein vernünftiges Modell auf die Beine zu stellen, sollten wir in solchen Fällen bei den Tabellen bleiben.
Weißt du, was HTML bedeutet? Kleiner Tipp: Das L steht für Language, nicht Layout.
"How To Make Love"? :)
Aber Gegenfrage: weißt du was CSS bedeutet? Da findet sich nirgendswo ein "zweckentfremde mal alles, um mit hacks und Browserweichen ein halbwegs kompatibles Layout hinzubekommen".
Außerdem ein großer Vorteil von CSS-Layouts: Stell dir vor, du willst später die Navigation nicht links an der Seite sondern als Breadcrumb oben drüber. Mit CSS erfordert das keinerlei Code-Änderung in der HTML-Datei. Mit Tabellen …?
… erfordert es mich nicht mal eine Minute. Der der Gewinn, der mir bleibt, weil ich nicht tausende Hacks nachschlagen und ausprobieren muss, bleibt groß.
will ich sehen ;-)
Mal im Ernst, ich glaube ja vieles, aber wenn die Website ohne CMS läuft,
dann glaube ich nicht, dass Du n Seiten mit einer mehr oder weniger kom-
plexen Tabellenstruktur in einer Minute wie oben beschrieben ändern kannst.
Und wenn es eine (größere) Website mit CMS ist, dann glaube ich es auch
nicht, dann muß das System schon sehr komplex sein, damit Du von einer
Listennavigation links außen mal eben auf die neue Variante wechseln
kannst. Wie machst Du das eigentliche mit Deiner Tabellenstruktur, wenn
die Breadcrumb-Navigation dann unten rechts (als Footer quasi) stehen
soll und immer sichtbar bleiben muß? ;-)
Was mich an Deiner Argumentation sehr verwundert, mit welcher Vehemenz Du
für die Tabellenstruktur eintrittst und uns nicht einfach mal einige ganz
konkrete Beispiele (URL) nennst, wo es wirklich so sinnvoll ist. Vielleicht
gibt es da keine? Was ich nicht bestreite, für schnelle Erfolge ist eine
Tabellenstruktur einfacher umzusetzen, man muß sich einfach weniger Fach-
wissen aneignen, damit man "Header oben, Navi links, Inhalt rechts" zu-
stande bekommt. Die Frage ist, ob es um schnelle Erfolge oder um die
mittel- und langfristige richtigere Strategie geht. Und dann sollte man,
m.E., als ernsthafter Entwickler auch noch den Anspruch haben, dass die
Ergebnisse eine gewisse Qualität haben. Eine Website basierend auf einer
Tabellenstruktur wird diesem Anspruch heutzutage nicht mehr gerecht.
Wie gesagt, bitte verlinke mal einige Beispiele für Layouts, wo Deiner
Meinung nach sinnvollerweise eine Tabellenstruktur verwendet wird.
Viele Grüße,
Stefan
PS: Was hälst Du eigentlich von Frames? ;-)
Außerdem ein großer Vorteil von CSS-Layouts: Stell dir vor, du willst später die Navigation nicht links an der Seite sondern als Breadcrumb oben drüber. Mit CSS erfordert das keinerlei Code-Änderung in der HTML-Datei. Mit Tabellen …?
… erfordert es mich nicht mal eine Minute. Der der Gewinn, der mir bleibt, weil ich nicht tausende Hacks nachschlagen und ausprobieren muss, bleibt groß.
will ich sehen ;-)
Mal im Ernst, ich glaube ja vieles, aber wenn die Website ohne CMS läuft,
dann glaube ich nicht, dass Du n Seiten mit einer mehr oder weniger kom-
plexen Tabellenstruktur in einer Minute wie oben beschrieben ändern kannst.
Na, es gibt genug Editoren, die dateisystemweites Suchen & Ersetzen mit regulären Ausdrücken ermöglichen. Durch vergeben IDs also gar kein Problem.
Und wenn es eine (größere) Website mit CMS ist, dann glaube ich es auch
nicht, dann muß das System schon sehr komplex sein, damit Du von einer
Listennavigation links außen mal eben auf die neue Variante wechseln
kannst. Wie machst Du das eigentliche mit Deiner Tabellenstruktur, wenn
die Breadcrumb-Navigation dann unten rechts (als Footer quasi) stehen
soll und immer sichtbar bleiben muß? ;-)
Wer so etwas tut, gehört bestraft.
Was mich an Deiner Argumentation sehr verwundert, mit welcher Vehemenz Du
für die Tabellenstruktur eintrittst und uns nicht einfach mal einige ganz
konkrete Beispiele (URL) nennst, wo es wirklich so sinnvoll ist.
Was verstehst du jetzt unter einem konkreten Beispiel? Ein Beispiel, bei dem ein Tabellenlayout vorzufinden ist, welches man nicht oder nur schlecht mit CSS abbilden kann?
Vielleicht
gibt es da keine? Was ich nicht bestreite, für schnelle Erfolge ist eine
Tabellenstruktur einfacher umzusetzen, man muß sich einfach weniger Fach-
wissen aneignen, damit man "Header oben, Navi links, Inhalt rechts" zu-
stande bekommt. Die Frage ist, ob es um schnelle Erfolge oder um die
mittel- und langfristige richtigere Strategie geht. Und dann sollte man,
m.E., als ernsthafter Entwickler auch noch den Anspruch haben, dass die
Ergebnisse eine gewisse Qualität haben. Eine Website basierend auf einer
Tabellenstruktur wird diesem Anspruch heutzutage nicht mehr gerecht.Wie gesagt, bitte verlinke mal einige Beispiele für Layouts, wo Deiner
Meinung nach sinnvollerweise eine Tabellenstruktur verwendet wird.
Reicht es nicht, dass ich bereits etliche Beispiele aufgezählt habe, die mit CSS alleine nicht möglich sind? Ich hab doch keine Lust, dafür noch konkrete Beispiele zu suchen.
PS: Was hälst Du eigentlich von Frames? ;-)
Soviel wie von Tabellen. Man sollte sie vermeiden, wenn sie nicht nötig sind, manchmal geht es aber nicht ohne.
Na, es gibt genug Editoren, die dateisystemweites Suchen & Ersetzen mit regulären Ausdrücken ermöglichen. Durch vergeben IDs also gar kein Problem.
Genau das ist das Problem, du musst in die HTML Struktur eingreifen, wenn du auf Tabellen verzichtest in diesem Falle nicht. D.h. du kannst beides mit der gleichen HTML Struktur umsetzen (um z.b. alternative Layouts anzubieten). Das ist die Praxis, im gegensatz zu deinen Praxisfernen Beispielen (z.b. überlange Linktexte ohne whitespaces)
Und wenn es eine (größere) Website mit CMS ist, dann glaube ich es auch
nicht, dann muß das System schon sehr komplex sein, damit Du von einer
Listennavigation links außen mal eben auf die neue Variante wechseln
kannst. Wie machst Du das eigentliche mit Deiner Tabellenstruktur, wenn
die Breadcrumb-Navigation dann unten rechts (als Footer quasi) stehen
soll und immer sichtbar bleiben muß? ;-)Wer so etwas tut, gehört bestraft.
Das sind deine Argumente auf die Nachteile von Tabellen als Layouthilfsmittel, während du ständig mit irgendwelchen Konstrukten (deren Umsetzung mit Tabellen du noch nicht gezeigt hast) kommst, die nicht realistisch sind und wer sich mit HTML/CSS auskennt sich auch nie ausdenken würde.
Wie gesagt, bitte verlinke mal einige Beispiele für Layouts, wo Deiner
Meinung nach sinnvollerweise eine Tabellenstruktur verwendet wird.Reicht es nicht, dass ich bereits etliche Beispiele aufgezählt habe, die mit CSS alleine nicht möglich sind? Ich hab doch keine Lust, dafür noch konkrete Beispiele zu suchen.
Eben, da hätte ich auch keine Lust drauf, weil sie in der Praxis einfach nicht realistisch sind und auch mit Tabellen eine Aufwand bedeuten würden und durchaus andere Nachteile hätten.
Struppi.
Hallo Die_Antwort
… Der der Gewinn, der mir bleibt, weil ich nicht tausende Hacks nachschlagen und ausprobieren muss, bleibt groß.
Wenn du wirklich längere Erfahrung mit CSS-Layout hättest, dann bräuchtest du nicht „tausende Hacks nachschlagen und ausprobieren”, sondern würdest ganz selbstverständlich, fast automatisch genau die tippen, die für dein gewünschtes Layout notwendig sind.
Auf Wiederlesen
Detlef
Moin!
Außerdem ein großer Vorteil von CSS-Layouts: Stell dir vor, du willst später die Navigation nicht links an der Seite sondern als Breadcrumb oben drüber. Mit CSS erfordert das keinerlei Code-Änderung in der HTML-Datei. Mit Tabellen …?
… erfordert es mich nicht mal eine Minute. Der der Gewinn, der mir bleibt, weil ich nicht tausende Hacks nachschlagen und ausprobieren muss, bleibt groß.
Also ich brauche trotz toller Editoren™ und schneller Internetanbindung (für den Upload) mehr als eine Minute um die komplette Homepage zu aktualisieren. Eine CSS-Datei anzupassen dauert da nicht länger. Wenn man das weiterdenkt kommt man sogar zu einem vielleicht überraschenden Ergebnis: Der Aufwand, eine CSS-Datei zu ändern, ist konstant, während der Aufwand, alle HTML-Dateien zu ändern linear mit der Anzahl an HTML-Seiten zunimmt. Noch Fragen?
Aber Gegenfrage: weißt du was CSS bedeutet?
Ja.
Da findet sich nirgendswo ein "zweckentfremde mal alles, um mit hacks und Browserweichen ein halbwegs kompatibles Layout hinzubekommen".
Zweckentfremdung, Hacks, … – zu was soll dein Layout denn kompatibel sein? Und nein, du weißt anscheinend nicht, was das Wesen einer _Auszeichnungssprache_ auszeichnet.
Viele Grüße,
Robert
Hallo allerseits,
Da das hier gerade so schön passt, würde ich gerne mal einen alten Thread, den ich vor knapp fünf Jahren [1] mal eröffnet habe, wiederaufgreifen. Ich beziehe mich hierbei auf Überlauf verhindern und stattdessen das Element vergrößern. Damals gab es keine wirklich befriedigende Lösung für mein Problem, außer eben doch Tabellen zu nehmen. Klar, ich habe im Ausgangsposting einen Hack damals selbst vorgestellt, aber wirklich befriedigend war der nicht, ich habe den selbst nie praktisch eingesetzt. Achja, die Beispielseiten, die im Ausgangsposting verlinkt sind, habe ich nie gelöscht, sie funktionieren also noch.
Mich würde es interessieren: Wie sieht die Situation heute aus? Mein Problem damals war, dass das CSS-Modell bezüglich der Breite außer bei Tabellen sich immer nach den äußeren Randbedingungen richtet, nie aber nach dem Inhalt. Dies ist insbesondere dann ein Problem, wenn man im Vorfeld keinerlei Kontrolle über den einzupflegenden Inhalt hat, beispielsweise bei einem Forum, Weblog oder CMS. Ist inzwischen etwas für CSS3 geplant (selbst wenn das noch in weiter Ferne liegt)? Gibt es proprietäre Eigenschaften, die so etwas bewerkstelligen? Oder wird display: table/table-cell; inzwischen so gut unterstützt, dass es tatsächlich verwendbar ist? Wie sieht es da mit dem IE7 aus? Oder ist jemand in diesen fünf Jahren auf eine viel genialere Idee gekommen, die damals bloß keinem eingefallen ist? Oder ist die Situation diesbezüglich im Endeffekt immer noch die gleiche wie vor fünf Jahren? (Was dann bezeichnend für den tatsächlichen Fortschritt im Web wäre. ;-))
[1] Meine Güte, ist das lange her...
Viele Grüße,
Christian
Hallo Christian,
das ist imho durchaus nochmal diskussionswürdig, auch wenn sich an der Situation nichts verändert hat (haben kann).
Allerdings würde ich dafür dann doch der Übersichtlichkeit halber vorschlagen, dafür einen eigenen Thread zu eröffnen (dieser hier ist schon mehr als unübersichtlich und das Thema hat ja auch nicht direkt etwas mit dem Thema dieses Threads zu tun).
Gruß Gunther
Nur mal ein Beispiel was CSS so darstellerisch negativ anstellen kann.
http://www.songbirdnest.de/songbird
Jaaa, ich weiss, der Designer ist schuld, nicht etwa css....
Klar, er kennt halt nicht alle dämlichen Tücken und Workarounds von CSS.
Ach ja: IE6 SP2 1024 x 768
ciao
Johann
Nur mal ein Beispiel was CSS so darstellerisch negativ anstellen kann.
Ein gutes Beispiel. Man sieht schön, dass ganz rechts unten der Text (selbst in Opera und Firefox) über die Spalte hinausläuft.
Hi,
Nur mal ein Beispiel was CSS so darstellerisch negativ anstellen kann.
Ein gutes Beispiel. Man sieht schön, dass ganz rechts unten der Text (selbst in Opera und Firefox) über die Spalte hinausläuft.
Im Opera nur minimal, weil der anders umbricht.
Und mit deiner geliebten Tabelle, was haetten wir da jetzt? Eine rechte Spalte, die sehr viel breiter geworden waere, als beabsichtigt. Ob das "besser" waere, bzw. wie die per CSS erreichbaren Alternativen optisch zu bewerten waeren, bleibt jedem selbst uerberlassen.
MfG ChrisB
Hi,
Nur mal ein Beispiel was CSS so darstellerisch negativ anstellen kann.
Ein gutes Beispiel. Man sieht schön, dass ganz rechts unten der Text (selbst in Opera und Firefox) über die Spalte hinausläuft.
Im Opera nur minimal, weil der anders umbricht.
Und mit deiner geliebten Tabelle, was haetten wir da jetzt? Eine rechte Spalte, die sehr viel breiter geworden waere, als beabsichtigt. Ob das "besser" waere, bzw. wie die per CSS erreichbaren Alternativen optisch zu bewerten waeren, bleibt jedem selbst uerberlassen.
Ja. Wem das nicht wichtig ist, der hat Glück gehabt. Nur geht es darum wiedermal nicht. Es geht nur um die Fälle, in denen es eben wichtig ist. Und in denen hat man mit CSS leider wenig Chancen.
Hi,
Und mit deiner geliebten Tabelle, was haetten wir da jetzt? Eine rechte Spalte, die sehr viel breiter geworden waere, als beabsichtigt. Ob das "besser" waere, bzw. wie die per CSS erreichbaren Alternativen optisch zu bewerten waeren, bleibt jedem selbst uerberlassen.
Ja. Wem das nicht wichtig ist, der hat Glück gehabt.
Wem *was* nicht wichtig ist?
Es geht nur um die Fälle, in denen es eben wichtig ist.
Mir waere im vorliegenden Falle wichtig gewesen, dass die rechte Spalte ihr beabsichtige Breite einhaelt (zu Gunsten eines der erwaehnten Kompromisse), aber -
Und in denen hat man mit CSS leider wenig Chancen.
(Wenn jetzt von dir wieder "ja, aber *mit* CSS schon" kommt - ja, aber CSS *ohne* die Tabelle die gleichen.)
MfG ChrisB
Hi,
Und mit deiner geliebten Tabelle, was haetten wir da jetzt? Eine rechte Spalte, die sehr viel breiter geworden waere, als beabsichtigt. Ob das "besser" waere, bzw. wie die per CSS erreichbaren Alternativen optisch zu bewerten waeren, bleibt jedem selbst uerberlassen.
Ja. Wem das nicht wichtig ist, der hat Glück gehabt.
Wem *was* nicht wichtig ist?
Wem es nicht wichtig ist, dass sich die Spalte dem Inhalt anpasst und wer es O.K. findet, wenn mal Text übersteht oder versteckt wird. Also zusammengefasst, wer es besser findet, wenn die Spalte eine "fixe" Größe hat. (was bei mir "fix" heißt, weißt du ja nun jetzt)
Es geht nur um die Fälle, in denen es eben wichtig ist.
Mir waere im vorliegenden Falle wichtig gewesen, dass die rechte Spalte ihr beabsichtige Breite einhaelt (zu Gunsten eines der erwaehnten Kompromisse), aber -
Ich fände es besser, wenn sie (und die linke Spalte) sich beide vergrößert hätten. Geschmackssache. Wer das nicht findet, hat Glück gehabt. Das meinte ich mit obigem.
Und in denen hat man mit CSS leider wenig Chancen.
- da hat deine Tabelle (allein) keine Chance.
(Wenn jetzt von dir wieder "ja, aber *mit* CSS schon" kommt - ja, aber CSS *ohne* die Tabelle die gleichen.)
???
Hi,
Ich fände es besser, wenn sie (und die linke Spalte) sich beide vergrößert hätten. Geschmackssache. Wer das nicht findet, hat Glück gehabt. Das meinte ich mit obigem.
Gut, dann beschreibe mir jetzt bitte, wie du das mit der Tabelle umsetzt, dass *auch* die linke Spalte analog breiter wird, wenn nur die rechte einen ueberbreiten Inhalt hat, der das fuer sie erfordert.
MfG ChrisB
Hallo,
Ich fände es besser, wenn sie (und die linke Spalte) sich beide vergrößert hätten. Geschmackssache. Wer das nicht findet, hat Glück gehabt. Das meinte ich mit obigem.
zu der Magie der analogen Verbreiterung der linken Spalte hat ChrisB schon
nachgefragt, ich bin auch auf Deine Antwort auch gespannt.
Nun schauen wir uns den vorliegenden Fall doch nochmal an ...
Also da werden unten in der rechten Spalte automatisch Forenbeiträge ange-
zeigt. Die können jetzt, gestern 14:23 Uhr oder vorgestern um 0:01 Uhr
erstellt wurden sein. Darin hat jemand eine Fehlermeldung gepostet, die von
den meisten Browsern nicht umgebrochen wird. Also wenn Du mich fragst, da
wäre ich doch sehr dafür, wenn in diesem speziellen Fall sowas server-
seitig abgefangen wird und nach einer bestimmten Zeichenzahl da Leer-
zeichen eingefügt werden (damit die Browser umbrechen).
Warum? Na dann frag mal irgendeinen Designer, was er davon hält, dass sich
sein Layout auflöst (und was anderes passiert nicht, wenn sich da Spalten
automatisch verbreitern, stell Dir mal die linke vor und schaue Dir die
Kopfgrafik an ...), also auf Begeisterung wirst Du da in keinem Fall
stoßen. Und wenn Du da jetzt anderer Meinung bist, dann erstelle doch
mal so eine schönen Tabellenseite und ich schreibe Dir in die linke
Spalten dreitausend 'W' am Stück rein. Viel Spaß beim Scrollen :-)
Viele Grüße,
Stefan
Moin!
Nur mal ein Beispiel was CSS so darstellerisch negativ anstellen kann.
Das ist kein Beispiel für schlechtes CSS, sondern für den schlechten Browser IE 6 (und vermutlich auch 7).
Aufgrund des zu breiten Inhalts in der rechten Spalte (vom Browser nicht umbrechbare, da nicht durch Leerzeichen oder sonstigen Whitespace unterbrochene, Buchstabenketten) ragt dieser Inhalt in standardkonformen Browsern leicht über den rechten Rand dieser Spalte - und der IE 6 zerstört die Darstellung aufgrund seiner unzureichenden Umsetzung von CSS-Float.
Ein gutes Beispiel. Man sieht schön, dass ganz rechts unten der Text (selbst in Opera und Firefox) über die Spalte hinausläuft.
Im Opera nur minimal, weil der anders umbricht.
Und mit deiner geliebten Tabelle, was haetten wir da jetzt? Eine rechte Spalte, die sehr viel breiter geworden waere, als beabsichtigt. Ob das "besser" waere, bzw. wie die per CSS erreichbaren Alternativen optisch zu bewerten waeren, bleibt jedem selbst uerberlassen.
Ja. Wem das nicht wichtig ist, der hat Glück gehabt. Nur geht es darum wiedermal nicht. Es geht nur um die Fälle, in denen es eben wichtig ist. Und in denen hat man mit CSS leider wenig Chancen.
Wem wichtig ist, dass die rechte Spalte den Inhalt nicht breiter darstellt, als beabsichtigt (denn offenbar handelt es sich um ein Layout mit fixer Spaltenbreite), der könnte overflow:hidden definieren, das würde das Problem vermutlich in allen Browsern inklusive IE beseitigen.
Ich sehe nicht, dass dieses Beispiel irgendetwas in der Sache "Tabellen mit CSS sind besser als keine Tabellen mit CSS" beiträgt. Ein Layout ist in einer grenzwertigen Situation zu einem unvorhergesehenen Verhalten gezwungen, welches im bekanntermaßen schlechtesten aller Browser zu einer extremen, aber vermutlich (siehe "powered by Mozilla" oben auf der Seite) beabsichtigten, mindestens aber ignorierten Unschönheit führt.
Aus meiner Sicht würde ich sagen: Das Layout erfüllt alle an es gestellten Anforderungen. Fixe Spaltenbreiten, optimale Darstellung in Firefox, vernünftiges Verhalten bei überlangem Content.
Ob "IE 6 muß es immer optimal anzeigen" auf der Anforderungsliste stand, wissen wir ja nicht - ich glaube aber nein.
- Sven Rautenberg
Und mit deiner geliebten Tabelle, was haetten wir da jetzt? Eine rechte Spalte, die sehr viel breiter geworden waere, als beabsichtigt. Ob das "besser" waere, bzw. wie die per CSS erreichbaren Alternativen optisch zu bewerten waeren, bleibt jedem selbst uerberlassen.
Ja. Wem das nicht wichtig ist, der hat Glück gehabt. Nur geht es darum wiedermal nicht. Es geht nur um die Fälle, in denen es eben wichtig ist. Und in denen hat man mit CSS leider wenig Chancen.
Wem wichtig ist, dass die rechte Spalte den Inhalt nicht breiter darstellt, als beabsichtigt (denn offenbar handelt es sich um ein Layout mit fixer Spaltenbreite), der könnte overflow:hidden definieren, das würde das Problem vermutlich in allen Browsern inklusive IE beseitigen.
Ich sehe nicht, dass dieses Beispiel irgendetwas in der Sache "Tabellen mit CSS sind besser als keine Tabellen mit CSS" beiträgt. Ein Layout ist in einer grenzwertigen Situation zu einem unvorhergesehenen Verhalten gezwungen, welches im bekanntermaßen schlechtesten aller Browser zu einer extremen, aber vermutlich (siehe "powered by Mozilla" oben auf der Seite) beabsichtigten, mindestens aber ignorierten Unschönheit führt.
Aus meiner Sicht würde ich sagen: Das Layout erfüllt alle an es gestellten Anforderungen. Fixe Spaltenbreiten, optimale Darstellung in Firefox, vernünftiges Verhalten bei überlangem Content.
Ja, wenn das die Anforderungen sind, ist es O.K..
Aber angenommen, es wäre meine Seite und ich hätte es gerne so, dass der Text nicht übersteht sondern sich die Spalte vergrößert. Und damit es gut aussieht, soll sich die Spalte ganz rechts auch vergrößern.
Mit CSS geht das nicht, mit CSS und Tabellen aber schon.
Hi,
Aber angenommen, es wäre meine Seite und ich hätte es gerne so, dass der Text nicht übersteht sondern sich die Spalte vergrößert. Und damit es gut aussieht, soll sich die Spalte ganz rechts auch vergrößern.
Du meinst vermutlich immer noch die links?
Mit CSS geht das nicht, mit CSS und Tabellen aber schon.
Wie gesagt, sehen will ich das immer noch.
MfG ChrisB
Moin!
Aus meiner Sicht würde ich sagen: Das Layout erfüllt alle an es gestellten Anforderungen. Fixe Spaltenbreiten, optimale Darstellung in Firefox, vernünftiges Verhalten bei überlangem Content.
Ja, wenn das die Anforderungen sind, ist es O.K..
Wie schön.
Aber angenommen, es wäre meine Seite und ich hätte es gerne so, dass der Text nicht übersteht sondern sich die Spalte vergrößert. Und damit es gut aussieht, soll sich die Spalte ganz rechts auch vergrößern.
Mit CSS geht das nicht, mit CSS und Tabellen aber schon.
Es geht auch ohne Tabellen.
- Sven Rautenberg
Hallo Johann
Ist das deine Seite?
Wenn nein, dann stelle Sie hier nicht zur Diskussion.
Jaaa, ich weiss, der Designer ist schuld, nicht etwa css....
Klar, er kennt halt nicht alle dämlichen Tücken und Workarounds von CSS.
Du hast noch nie eine Tabellenlayout-Seite gesehen, die in irgendeinem Browser anders aussieht, als der Seitenersteller wollte?
Auf Wiederlesen
Detlef
Hi Detlef,
Ist das deine Seite?
Wenn nein, dann stelle Sie hier nicht zur Diskussion.
Hier steht keine Seite zur Diskussion sondern sie dient als Beispiel.
Aber was soll dasm darf man hier keine Beispiele verlinken?
Das wäre äusserst seltsam und wider normalen Forumsverhalten.
Du hast noch nie eine Tabellenlayout-Seite gesehen, die in irgendeinem Browser anders aussieht, als der Seitenersteller wollte?
Doch aber eben in allen Browsern gleich.
Johann
Hiho!
Du hast noch nie eine Tabellenlayout-Seite gesehen, die in irgendeinem Browser anders aussieht, als der Seitenersteller wollte?
Doch aber eben in allen Browsern gleich.
In Deiner Welt moechte ich leben.
Oder nutzt du nur den IE in verschiedenen Versionen und verstehst das unter anderen Browsern? Mein letzter Webspace-Provider hatte das, von ihm zur Verfuegung gestellte, phpmyadmin in einem eigenen Layout aus Tabellen zur Verfuegung gestellt. Mit dem Erfolg, dass es nur per IE nutzbar war. Richtige Browser haben (korrekterweise) einfach nichts angezeigt. Einer der Gruende, warum ich dort weg bin.
Hallo!
Also mir scheint dieser Thread mittlerweile völlig sinnlos. Der OP hat keine wirklichen Argumente, bringt keine Beispiele, und vor allem geht er in keiner vernünftigen Weise auf die hier zahlreich vorgebrachten Argumente ein.
Die Aussage, dass er weiß wovon er redet, kann ich nach diversen Aussagen in diesem Thread auch nicht (mehr) ganz ernst nehmen.
Von daher halte ich jede weitere "Fütterung" für zwecklos.
Gruß Gunther
Hallo!
Also mir scheint dieser Thread mittlerweile völlig sinnlos. Der OP hat keine wirklichen Argumente, bringt keine Beispiele,
Gleich lange Spalten, Probleme bezüglich des Footers, teilweise bessere Kompatibilität, teilweise leichter zu pflegen, weniger Hacks benötigt, semantischer. Ich habe für alle diese Punkte irgendwo hier schon Beispiele gebracht.
und vor allem geht er in keiner vernünftigen Weise auf die hier zahlreich vorgebrachten Argumente ein.
Auf welche z.B. gehe ich nicht ein?
Die Aussage, dass er weiß wovon er redet, kann ich nach diversen Aussagen in diesem Thread auch nicht (mehr) ganz ernst nehmen.
Nach welchen Aussagen? Wo habe ich geschrieben, dass ich weiß, wovon ich rede?
Von daher halte ich jede weitere "Fütterung" für zwecklos.
Also _das_ ist untrolllich. ;)
Hi,
Gleich lange Spalten,
Wurde als Punkt anerkannt, ja.
Probleme bezüglich des Footers,
Die da waeren?
teilweise bessere Kompatibilität,
teilweise schlechtere, oder andere Nachteile
teilweise leichter zu pflegen,
groesstenteils aber nicht; wurde von dir als Argument aber auch mit fadenscheiniger Begruendung abgelehnt
weniger Hacks benötigt,
du wolltest gerade noch die Navigation doppelt ins HTML aufnehmen, um einen bestimmten Effekt zu erreichen ...
semantischer.
Dass dein Verstaendnis davon sich mit dem der Allgemeinheit hier wenig zu decken scheint, haben wir bereits festgestellt.
Ich habe für alle diese Punkte irgendwo hier schon Beispiele gebracht.
Von denen die meisten als unzureichend bis bloedsinnig abgelehnt wurden.
Die Aussage, dass er weiß wovon er redet, kann ich nach diversen Aussagen in diesem Thread auch nicht (mehr) ganz ernst nehmen.
Nach welchen Aussagen? Wo habe ich geschrieben, dass ich weiß, wovon ich rede?
Nehmen wir einfach an, du haettest es nicht getan - dann ist uns glaube ich allen wohler.
MfG ChrisB
Hi,
Gleich lange Spalten,
Wurde als Punkt anerkannt, ja.
Probleme bezüglich des Footers,
Die da waeren?
Kann nicht am Ende der gesamten im Browser angezeigten Fläche für die Seite platziert werden. Zumindest nicht ohne Hacks. Mit Tabellen schon.
teilweise bessere Kompatibilität,
teilweise schlechtere, oder andere Nachteile
teilweise leichter zu pflegen,
groesstenteils aber nicht; wurde von dir als Argument aber auch mit fadenscheiniger Begruendung abgelehnt
Meistens nicht das stimmt. In solchen Fällen sollte man zu CSS greifen. Aber es gibt eben auch die anderen, um die ging es mir.
weniger Hacks benötigt,
du wolltest gerade noch die Navigation doppelt ins HTML aufnehmen, um einen bestimmten Effekt zu erreichen ...
Dort würde ich es auch nicht machen. Ich rede von Beispielen, bei denen das CSS schlimmere oder mehr hacks als die Tabelle benötigt
semantischer.
Dass dein Verstaendnis davon sich mit dem der Allgemeinheit hier wenig zu decken scheint, haben wir bereits festgestellt.
Gut, "für mich semantischer".
Ich habe für alle diese Punkte irgendwo hier schon Beispiele gebracht.
Von denen die meisten als unzureichend bis bloedsinnig abgelehnt wurden.
...von dir. ;)
Die Aussage, dass er weiß wovon er redet, kann ich nach diversen Aussagen in diesem Thread auch nicht (mehr) ganz ernst nehmen.
Nach welchen Aussagen? Wo habe ich geschrieben, dass ich weiß, wovon ich rede?
Nehmen wir einfach an, du haettest es nicht getan - dann ist uns glaube ich allen wohler.
... ich werde jetzt meinen benötigten Schlaf bekommen. Durch die Diskussion ist es schon wieder so spät. Hat aber auch Spaß gemacht und Ehrenwort: ich bin kein Troll.
Gute Nacht allen, die an der Diskussion teilgenommen haben.
Hallo Gunther,
das sagte ich bereits kurz nach Threaderöffnung, das führt immer dazu.
ZITAT: "Das Thema gabs hier schon oft genug. Die zugehörigen Diskussionen
eine Sackgasse. Also soll doch jeder machen wie es ihm beliebt."
Gruss
Heinz
Hallo,
Wir haben auf der Arbeit ein Interessantes Produkt, das die Vorteile eines CSS-Layouts ziemlich gut darstellt. Es ist die Light-Version unseres CMS, die dem Kunden zwar erlaubt die Inhalte zu ändern, aber nicht das HTML. Wir haben jetzt etwa 150 Webseiten damit umgesetzt. Neben der Inhalte dürfen nur die CSS-Dateien verändert werden. Diese 150 Webseiten sehen wirklich sehr unterschiedlich aus (im Prinzip ähnlich CSS-Zen-Garden). Das wäre mit einem Tabellenlayout nicht im entferntesten möglich.
Auch sachen wie die Linearisierung der Inhalte für das Druck- oder Handheldlayout wären unmöglich.
Natürlich gibt es manchmal Sachen die auf den Ersten Blick wirklich einfacher mit einer Layouttabelle gehen würden, langsichtig gesehen und vor allem das nächste Redesign vor den Augen ist es doch viel einfacher und insgesammt schneller CSS zu nutzen (und kein ich muss keine 1000 Hacks jedes mal nachgucken, ich bin Profi und habe sie mittlerweile im Kopf/Blut).
Jeena
