zwei kästen ineinander

[schneehuhn]

Hallo,

ich versuch jetzt schon seit einiger zeit zwei css kästen ineinander zu bekommen. Hab mir jetzt testweise einen "mainkasten gemacht" mit divs definiert. in diesen hinein hab ich einen weiteren <div kasten gemacht der allerdings float:left hat und noch einen in den mainkasten mit float:right. der linke soll für ein menü werden, der rechte für den content der seite. Der ausenherum  einfach als abgrenzung. Hört sich einfach an, bringt mich aber zur weißglut. Da die beiden Kästen die eigentlich in den Großen hinein sollen sich immer außerhalb unten dran kleben. Hab nun erfahren dass float "ausgestattete" elemente nicht außen  liegende kästen vergrößeren können. Wie löse ich das prob denn nun? poisitonieren mit position:relative hab ich auch schon probiert, da macht dann allerdings der IE probleme.

http://toni.toflo.no-ip.com/fuwas2 << so sieht das bisher aus :/
Würde mich freuen, wenn mir da jemand weiterhelfen kann.

Toni

[wahsaga]

hi,

Da die beiden Kästen die eigentlich in den Großen hinein sollen sich immer außerhalb unten dran kleben. Hab nun erfahren dass float "ausgestattete" elemente nicht außen  liegende kästen vergrößeren können.

richtig, float nimmt ein element aus dem normalen fluss heraus - somit kann es nicht mehr die höhe seines elternelements beeinflussen (ganz ähnlich wie bei absoluter positionierung auch).

Wie löse ich das prob denn nun? poisitonieren mit position:relative hab ich auch schon probiert, da macht dann allerdings der IE probleme.

du fügst hinter die beiden gefloateten elemente, aber noch innerhalb des äuseren containers, ein weiteres (ggf. leeres) element ein, in dem du mittels clear das floaten wieder aufhebst.

gruß,
wahsaga

[Mathias Bigge]

Hi wahsaga,

du fügst hinter die beiden gefloateten elemente, aber noch innerhalb des äuseren containers, ein weiteres (ggf. leeres) element ein, in dem du das floaten wieder aufhebst.

Bitte nicht als Provokation nehmen, sondern als ehrliche Frage: Wenn dieses Element leer ist, hat es dann nicht reine Layoutfunktion wie ein Leergif?

Viele Grüße
Mathias Bigge

[wahsaga]

hi,

Bitte nicht als Provokation nehmen, sondern als ehrliche Frage: Wenn dieses Element leer ist, hat es dann nicht reine Layoutfunktion wie ein Leergif?

ja, kann man durchaus so sehen.

aber was will man sonst machen, wenn man einen umgebenden container "auf höhe" bringen will, und es keinen _inhalt_ mehr gibt, der nach den gefloateten elementen im container sein soll?

da fällt mir ein, es wird auch des öfteren empfohlen, den container auch noch floaten zu lassen, um diese aufgabe ohne zusätzliches clearendes element zu lösen.
das habe ich, ehrlich gesagt, noch nie ausprobiert - und habe auch bedenken, ob das nicht wiederum anderen unerwünschte nebeneffekte nach sich ziehen kann, je nachdem wie der container selbst angeordnet/positioniert ist.

gruß,
wahsaga

[Thomas J.S.]

Hallo,

ja, kann man durchaus so sehen.

aber was will man sonst machen, wenn man einen umgebenden container "auf höhe" bringen will, und es keinen _inhalt_ mehr gibt, der nach den gefloateten elementen im container sein soll?

Einfach ganz böse ein <br clear="all"> hineinschustern ;-)

Grüße
Thomas

[Mathias Bigge]

Hi Thomas,

Einfach ganz böse ein <br clear="all"> hineinschustern ;-)

Wenn die Entwicklung im CSS-Bereich so weitergeht, haben wir wenigstens bald alle Unarten der Tabellentrickserei wieder versammelt und können dann wieder vorurteilsfrei herumfummeln....

Viele Grüße
Mathias Bigge

[schneehuhn]

Habs nun hinbekommen. ... mit dem <br clear usw ... Habs auch mit nem weiteren <div kasten probiert den ich dann unter die zwei inneren kästen machen wollte mit clear:float ... war aber leider nicht so der erfolg :/

Toni

[Thomas J.S.]

Hallo Mathias,

Einfach ganz böse ein <br clear="all"> hineinschustern ;-)
Wenn die Entwicklung im CSS-Bereich so weitergeht,[...] können dann wieder vorurteilsfrei herumfummeln....

Das macht man so oder so, fürher oder später. Erst das herumtun, dann die Spezifikationsexegese und schließlich die Erkenntnis, dass man nur mit beiden zusammen wirklich gut leben kann ;-)

Grüße
Thomas

[Ingo Turski]

Hi,

Bitte nicht als Provokation nehmen, sondern als ehrliche Frage: Wenn dieses Element leer ist, hat es dann nicht reine Layoutfunktion wie ein Leergif?

natürlich. Aber das geht halt nicht anders - außer wenn man zufällig ein sinnvolles Element hat, um es hier zu plazieren.

freundliche Grüße
Ingo

[Detlef G.]

Hallo Mathias

Bitte nicht als Provokation nehmen, sondern als ehrliche Frage: Wenn dieses Element leer ist, hat es dann nicht reine Layoutfunktion wie ein Leergif?

Ja, es hat in diesem Fall eine reine Layoutfunktion.

Ein Leergif ist als IMG eingebunden und muss extra vom Server geladen
werden. Es hat im HTML eine Bedeutung (hier kommt eine Grafik).
Div und Span sind nach meinem Verständnis extra geschaffen worden, um andere
Elemente zu gruppieren oder als Platzhalter für Formatierungen zu dienen, ohne
selbst eine Bedeutung im HTML zu haben.

Auf Wiederlesen
Detlef

[Mathias Bigge]

Hi Detlef,

Div und Span ... als Platzhalter für Formatierungen .... ohne selbst eine Bedeutung im HTML zu haben.

Eigentlich ist mir das Argument, zu welchem Zweck etwas geschaffen wurde, ziemlich gleichgültig. Mir schien das hier nur eins der Beispiele für das zu sein, was man bei div-Problemen einzusetzen pflegt und bei Tabellenlayouts verteufelt: HTML-Tags oder irgendwelche Tricks im body einzusetzen, um bestimmte Formatierungsprobleme zu lösen, von wegen der strikten Trennung von Form und Inhalt. Vielleicht wäre es gut, da von Ideologien zurück zu einem pragmatischen Umgang mit den vorhandenen Möglichkeiten zu kommen. Mir persönlich sind einige CSS-Hacks unsympathischer als die entsprechenden Tabellentricks, auch wenn man Leergifs natürlich vermeiden sollte, obwohl man sie beim Druck ausblenden kann.

Um meine Position zu beschreiben, würde ich mir immer noch bessere Layoutmöglichkeiten wünschen, die in allen Browsern funktionieren. Aber das ist wohl immer noch Zukunftsmusik.

Viele Grüße
Mathias Bigge

[Detlef G.]

Hallo Mathias

Eigentlich ist mir das Argument, zu welchem Zweck etwas geschaffen wurde, ziemlich gleichgültig.

Du nimmst also für die Seitenüberschrift ein <h4> oder gleich ein <b> mit <br>
dahinter, wenn diese nicht so groß sein soll, und verwendest eine <h1>, wenn
irgendwo auf der Seite etwas ganz groß und fett sein soll, ohne eine
Überschrift zu sein? ;-)

Auf Wiederlesen
Detlef

[Mathias Bigge]

Hi Detlef,

Du nimmst also für die Seitenüberschrift ein <h4> ...

Das Beispiel ist nicht weiterführend, weil trivial. Worauf ich hinaus wollte, sind zwei Dinge:

1. Ich pfeife darauf, wofür jemand etwas geplant hat, wenn ich es anders für mich nutzen kann, trinke einen Schluck Cola aus dem Weißweinglas, wenn mir das passt, das macht das Leben lustiger. Mein Kriterium ist der Gebrauchswert für meine Zwecke. Bei den Überschriftenhierarchien ist er gegeben. Du weißt aber genau, dass diese nicht die Demarkationslinien unserer Debatte markieren.

2. Die Argumentation, dass Tabellen ausschließlich für tabellarische Daten genutzt werden sollen, divs und spans dagegen für jeden Mist geeignet sein sollen, und dass dieser Glaube das "semantische Web" voranbringe, überzeugt mich aufgrund der Konstrukte, die im CSS-Bereich inzwischen vorgeschlagen werden (JS-Hacks, diverse inhaltsleere divs und clears, Browserweichen aller Art, CSS-Tricks zur Überlistung der diversen Generationen eines Browsers, proprietäre CSS-Formate, DTD-Manipulationen,....) immer weniger. Im Endresultat wird es oft unübersichtlicher als ein gekonntes Tabellenlayout. Das Wissen ist gemessen an dem geringen Nutzeffekt inzwischen überkomplex (Browsereigenschaften, Positionierungseffekte, Box-Modell-Probleme, Float-Probleme, proprietäre Formate diverser Browser,...), die entstandenen Laokoon-Gruppen schlimmer als jeder Uraltspagetthicode.

Dann sind einige Positionierungsprobleme nur unsinnig kompliziert zu lösen, Beispiele ohne Ende füllen inzwischen das Archiv. Es ist nicht so, dass ich es nicht begrüßen würde, ganz von Tabellen weggehen zu können und sicher liegt da irgendwo die Zukunft, aber in der Gegenwart überzeugen mich viele Konstrukte nicht, auch wenn ich immer wieder fasziniert bin, welche Phantasie entwickelt wird, um bestimmte Probleme zu überlisten. Wann man da Elementen eine Weite geben muss, wann noch ein Container-div daherkommen muss, wann man clear einsetzt und welche Nebenwirkungen das hat, allerlei lustige Effekte von float und ihre Beherrschung.... Wieviel Hirnschmalz man allein anwenden muss, um eine simple Liste in bestimmten Konstrukten wieder in allen Browsern mit Listenpunkten anzeigen zu lassen, wie herrlich logisch dann abgeleitet wird, warum das so sein muss, warum man in vielen Fällen nicht nur dem unschuldigen Element ein bestimmtes Format zuordnen muss, sondern einer ganzen Kette von Elternelementen, weil die Vererbung nicht vernünftig funktioniert usw.

Manchmal freue ich mich auch über interessante Effekte, etwa body, html eine Höhe von 100% verpassen, dann absolut ein Element an den unteren Bildschirmrand gepappt und Inhalt, der die Seitenlänge überschreitet, und man hat plötzlich mit position absolute position fixed produziert, zumindest in einigen Browsern...

Oder warum die Breite nicht genau 100% betragen sollte, und was da der wahre Wert ist, erinnert mich an die 13,7 Pixel-Schriften zur Überlistung des NS 4 *g*

Ich lese weiter mit und versuche die Winkelzüge und Tricks zu begreifen, wenn's aber wirklich mal eine produktive Sache werden soll, wird sich wohl noch einiges ändern müssen. Und solange nütze ich die herrlichen HTML-Elemente genauso, wie's mit passt, halten zu Gnaden.

Na, angesichts der Komplexität der Entwicklung sind die meisten von uns ja schon ein bisschen lockerer in der Hüfte geworden, einige erfreuen sich eben noch für eine Zeit an der Predigerrolle, irgendwann wird es auch diesen wertguten Fachleuten zu heiß allein in der Wüste, mal sehen, welche Sau uns als nächstes durch's Dorf getrieben wird, na einen Unterhaltungswert hat das Ganze schon. ;-)

Kleine Nebenbemerkung: In vielen Fällen überzeugt mich der Einsatz von proprietären CSS-Formaten mehr als die tricksigen Hacks. Wie siehst Du das?

Was ich eher albern finde ist die Predigt, ein Layout müsse auf dem Handy-Display genauso gut funktionieren wie auf einem Riesenbildschirm, alle Browser glücklich machen und zudem noch valide sein. Das geht natürlich am besten durch Reduktion der Inhalte auf "Hello World!"....

Viele Grüße
Mathias Bigge

[Detlef G.]

Hallo Mathias

Das Beispiel ist nicht weiterführend, weil trivial...

und überspitzt und provokativ und extra mit ";-)" versehen.

1. ... Mein Kriterium ist der Gebrauchswert für meine Zwecke. Bei den Überschriftenhierarchien ist er gegeben.

Das Beispiel mit den Überschriften war bewusst gewählt, um deine Aussage zu
überspitzen:

Eigentlich ist mir das Argument, zu welchem Zweck etwas geschaffen wurde, ziemlich gleichgültig.

Das klang für mich so, als würdest du jegliche strukturelle Bedeutung der
Elemente ignorieren bzw. ablehnen.

2. Die Argumentation, dass Tabellen ausschließlich für tabellarische Daten genutzt werden sollen, divs und spans dagegen für jeden Mist geeignet sein sollen, ...

Nicht für jeden Mist, sondern für (leider) notwendige Elemente, die keine
logische strukturelle Bedeutung für den Inhalt tragen.
Wenn ich die Wahl zwischen einem Spacer-Gif oder einem leeren Span oder Div
hätte, um das selbe Resultat zu erzielen, würde ich kein Gif (mehr) nehmen.

... Im Endresultat wird es oft unübersichtlicher als ein gekonntes Tabellenlayout.

Dann sollte lieber ein Tabellenlayout verwendet werden!

Das Wissen ist gemessen an dem geringen Nutzeffekt inzwischen überkomplex

Dieses Wissen finde ich durchaus nötig, nicht unbedingt, um krampfhaft ein
reines CSS-Layout zu erstellen, sondern auch, um abschätzen zu können, bei
welchen Layoutvorgaben lieber auf ein solches verzichtet werden sollte.

Dann sind einige Positionierungsprobleme nur unsinnig kompliziert zu lösen, Beispiele ohne Ende füllen inzwischen das Archiv.

Auch zu Problemen mit Layouttabellen, Abständen zwischen Grafiken und
Zellenrändern, fast undurchschaubaren Tabellenverschachtelungen ...

Es ist nicht so, dass ich es nicht begrüßen würde, ganz von Tabellen weggehen zu können und sicher liegt da irgendwo die Zukunft, aber in der Gegenwart überzeugen mich viele Konstrukte nicht, auch wenn ich immer wieder fasziniert bin, welche Phantasie entwickelt wird, um bestimmte Probleme zu überlisten.

Es liegt auch ein besonderer Reiz darin, Lösungen zu finden.
Oft besteht das Hauptproblem aber auch nur darin, dass bei einem bestimmten
CSS-Layout genau entgegengesetzt herangegangen werden muss als bei einem
ähnlichen Tabellenlayout.

Wann man da Elementen eine Weite geben muss, wann noch ein Container-div daherkommen muss, wann man clear einsetzt und welche Nebenwirkungen das hat, allerlei lustige Effekte von float und ihre Beherrschung....

Wann die Tabelle oder eines ihrer Elemente eine Weite braucht, wann eine
Höhe, wann sie keine haben darf, wann ein colspan, wann ein rowspan, wann es
mit einer Tabelle nicht geht und geschachtelt werden muss und welche Nebenwirkungen dies hat, welcher Browser welche Zeilen oder Spalten
gleichmäßig verteilt oder nicht, sich an die angegeben Weiten oder Höhen
hält und wann nicht, diese lustigen Effekte und ihre Beherrschung.... ;-)

... warum man in vielen Fällen nicht nur dem unschuldigen Element ein bestimmtes Format zuordnen muss, sondern einer ganzen Kette von Elternelementen, weil die Vererbung nicht vernünftig funktioniert usw.

Das Problem gibt es bei Tabellen nicht?
Wie oft kommt hier die Frage: "Warum füllt meine Tabelle nicht den ganzen
Bildschirm, ich habe ihr doch height=100% gegeben?"

Ich lese weiter mit und versuche die Winkelzüge und Tricks zu begreifen, wenn's aber wirklich mal eine produktive Sache werden soll, wird sich wohl noch einiges ändern müssen.

Ja, es sollte sich noch einiges ändern besonders bei der einheitlichen und
standardkonformen CSS-Umsetzung durch die Browser.
Nur, solange niemand CSS-Layouts verwendet, wird sich auch nichts ändern.
Warum sollte es auch, wenn es nicht nötig ist weil alle tolle Tabellenlayouts
bauen.

... einige erfreuen sich eben noch für eine Zeit an der Predigerrolle, irgendwann wird es auch diesen wertguten Fachleuten zu heiß allein in der Wüste, mal sehen, welche Sau uns als nächstes durch's Dorf getrieben wird, na einen Unterhaltungswert hat das Ganze schon. ;-)

Ich sehe darin nicht nur einen Unterhaltungswert.
Ich finde es gut und nötig, zu diesen Themen zu diskutieren. Natürlich ist
nicht alles sofort und nicht zu 100%ig umsetzbar, es muss jeweils ein
praktikabler Kompromiss gefunden werden. Es sind sehr oft nachvollziehbare
Gedanken und Meinungen, die man zumindest im Hinterkopf behalten sollte.
Oft ergeben sich daraus durchaus Möglichkeiten, es anders, logischer zu
machen, ohne dass es mehr Aufwand bedeutet.

Wichtig finde ich allerdings nicht so sehr, wie genau etwas umgesetzt wird.
Viel wichtiger finde ich, dass der Seitenersteller nicht einfach irgendetwas
zusammenklickt, was dann zufällig so aussieht wie gewünscht, sondern dass er
weiß, warum er es genau so macht.

Kleine Nebenbemerkung: In vielen Fällen überzeugt mich der Einsatz von proprietären CSS-Formaten mehr als die tricksigen Hacks. Wie siehst Du das?

Das sehe ich auch so. Je ausgeklügelt komplizierter ein Hack ist, um so
größer ist die Gefahr, dabei einen Fehler zu machen, der mir auch nicht unbedingt auffällt, weil ich die Seiten kaum in allen Browsern unter allen
Betriebssystemen testen kann.
Bei Eigenschaften, die eindeutig nur ein bestimmter Browser kennt, oder z.B. bei Einbindung einer ie.css mittels Conditional Comments, kann ich mir
ziemlich sicher sein, dass diese Angaben nur der Browser bekommt, für den
sie bestimmt sind.

Was ich eher albern finde ist die Predigt, ein Layout müsse auf dem Handy-Display genauso gut funktionieren wie auf einem Riesenbildschirm, alle Browser glücklich machen und zudem noch valide sein. Das geht natürlich am besten durch Reduktion der Inhalte auf "Hello World!"....

Das ist auch etwas übertrieben, aber es sollten nicht unnötigerweise
bestimmte Bildschirmgrößen oder Browser ausgeschlossen werden. Das
Funktionieren kann auch darin bestehen, dass das Layout bei Altbrowsern
oder extrem kleinen Bildschirmen eben nicht mehr vorhanden ist, um so
wenigstens die rein textliche Information zugänglich zu lassen.

Meine Meinung ist: Eine Seite hat valide zu sein, es sei denn, ich weiß
genau, warum ich vom Standard abweichen musste.

Auf Wiederlesen
Detlef

[Detlef G.]

Hallo Mathias

... Mir schien das hier nur eins der Beispiele für das zu sein, was man bei div-Problemen einzusetzen pflegt und bei Tabellenlayouts verteufelt: HTML-Tags oder irgendwelche Tricks im body einzusetzen, um bestimmte Formatierungsprobleme zu lösen, von wegen der strikten Trennung von Form und Inhalt.

Es ist nicht gut, dass diese Elemente nötig sind, trotzdem:
Bedeutungsleere Elemente wie Div oder Span sind zwar zusätzliche Elemente,
sie ändern aber nicht die logische Struktur des Inhalts.
Sie legen auch nicht das Layout fest sondern dienen lediglich als
Angriffspunkte für die ausgelagerten Layoutvorgaben.
So kann das claerende Element, wenn das Layout geändert würde und dadurch
nicht nötig wäre, mittels CSS augeblendet werden oder mit entsprechenden
Größenangaben und einem Hintegrungbild eine Zierleiste werden.

... Vielleicht wäre es gut, da von Ideologien zurück zu einem pragmatischen Umgang mit den vorhandenen Möglichkeiten zu kommen.

Diese "Ideologien" sind doch nicht verkehrt, sie geben wünschenswerte Ziele
vor, die zur Zeit nicht (und vielleicht nie) wirklich erreichbar sind,
helfen aber bei kritischer Arbeit auch durchaus unsinnige logische Fehler zu
vermeiden.
Und der pragmatische Umgang damit ist es, der den Einsatz zusätzlicher
Elemente erlaubt, ohne damit gleich zu übertreiben und Div-Suppenkoch zu
werden.

Auf Wiederlesen
Detlef