nicht angemeldet
Moin!
genau die beiden sehe ich auch als Problem, 5 vielleicht noch weniger, weil die Höhe des Linken oberen Elementes genau feststeht. CSS-Layouts sind in dem moment ein Problem, wo man eine "vertikale Linie" in dem Layout hat, bei der sich nicht die Elemente auf der einen oder anderen Seite in ein "gesamt-Element" stecken lassen. Damit ist evtl. auch 9 "abgehakt", wo sich ja Links nur ein Block befindet -> float:left;
Also, ich würde die 9 eigentlich als eher CSS-geeignet betrachten, als die Nummer 5. Das ist doch ein klassisches 2-Spalten-Design, wie man es beim Noocle-Incident nachgeworfen kriegt. Die breite Spalte ist eine Abfolge von DIVs, und die linke Spalte positioniert. Der Streifen links kommt per Hintergrundbild im Body rein, und die breiten DIVs haben auch ihr eigenes Bild.
Und da ich gerade sehe, daß die 9 eine feste Breite hat (zentriert), dürften auch sonst alle Tricks greifen, die man so anwenden kann.
Nummer 5 wird hingegen schon wesentlich interessanter. Da wird man vermutlich mit position:relative arbeiten müssen, um den unteren linken Block zu positionieren.
Dagegen schreit für mit Layout 4 nach einer reinen CSS-Lösung, da hier alle Elemente klar erkennbar sind und sich entsprechend "hinschieben" lassen
Exakt. Nummer 4 ist das klassische CSS-Layout, wie man es relativ leicht für alle Browser hinkriegen kann. Das ist bei Nr. 9 eher nicht der Fall, da wird (wenn man sich nicht sehr viel Mühe gibt) Netscape 4 aussteigen.
Ich glaube einfach, wir muessen noch genauer herausfinden, welche Art der Layoutierungsumsetzung fuer welche Zwecke sinnvoller ist. Das halte ich jedenfalls fuer sinnvoller als jeglichen Fundamentalismus von der Sorte "Tabellen sind Tabu".
genauso, wie das hier genannte "mit Tabellen geht alles einfacher und kompatibler". Tabellen-Layouts haben einen großen Nachteil, sie sind nur bis zu einer gewissen Breite herunterskalierbar, danach ist eine vertikale Scrollbar fast unumgänglich. Dagegen habe ich heute erst ein solches CSS-Layout entworfen, dass extra auf Browserfenster mit 200Pixel Breite ausgelegt ist -> PDAs. Auch kann man mit Tabellen Benutzer von Screenreadern oder lynx-User in den Wahnsinn treiben. Interessant übrigens, was viele der sog. "Pixelschubser" über lynx sagen: "Wird doch eh nur von Assos benutzt, um Webmaster zu schikanieren oder um sich einen hochzugeilen".. Eine echte Accessibility ist mit Tabellen nicht möglich, der Inhalt ist eben nicht linear, sondern in Blöcken in Reihenfolge der Darstellung (die nicht immer mit der logischen Reihenfolge übereinstimmen muss).
Die Aussage "Mit CSS geht _alles_" ist sicher genauso falsch wie die Aussage "Mit Tabellen geht _alles_". Mit CSS geht auch nicht immer alles. Die Frage ist nur: Wie flexibel ist man bei der Erstellung eines Layouts, wenn CSS nicht ganz das leisten kann, was man möchte, aber gewisse nicht-sichtbare Features gefordert sind, wie beispielsweise Druck-CSS oder PDA-CSS - alles in einer HTML-Datei eingebunden.
Es ist ja nicht so, daß CSS ermöglicht, Blöcke in der HTML-Datei beliebig umherzusortieren. Diese Freiheit hat man eher selten, wenn man viele Forderungen erfüllen muß. Aber die Zwänge, die Tabellen einem auferlegen - die hat man garantiert nicht.
Ach ja, ich hab' den Kopf des Self-Layouts (ohne die Grafiken - die lassen sich relativ zu den Layern absolut positionieren wie beim Zwei-Spalten-Design vom Noodle-Incident) strukturell innerhalb von etwa 5 Minuten in Layern nachgebastelt. Das ist nicht das Problem. Das Problem ist: Was macht Netscape 4 daraus? Und da ist leider die bekannte Hiobsbotschaft zu vermelden: Netscape schafft es nicht, Layer komplett durchzufärben, sondern macht das nur im Bereich des Textes. Persönliches Pech für dessen User - unbenutzbar wird die Seite dadurch nicht, sie sieht nur nicht mehr so schön aus.
Merke: Das Problem des Tabellenlayouts besteht vor allem deswegen, weil manche Seiten ohne großen Zusatzaufwand auch im Netscape 4 noch top designt aussehen müssen. Und mit Tabellen kann er ja ganz gut umgehen.
- Sven Rautenberg