nicht angemeldet
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
Struppi