negatives margin-top - Opera und FireFox spinnen rum

[wahsaga]

hi,

kann mir das mal bitte einer erklären ...?

Ich habe ein OL, darin ein LI [1], und darin eine DL mit vier DT/DD-Paaren.

Jetzt blende ich das erste DT über display:none aus, das erste DD bekommt eine Höhe von 2em, etwas padding, kein margin, und einen Rahmen verpasst.

Die restlichen drei DT/DD-Paare bekommen alle eine Breite von 4em, und werden nach links gefloatet, so dass drei mal DT - DD nebeneinander stehen auf einer gemeinsamen Zeile.

Jetzt möchte ich diese drei Paare per negativem margin-top ein wenig nach oben "hieven", so dass sie über dem ersten, großen DT zu liegen kommen.

OK, margin-top für alle -1em - klappt wunderbar, nur liegen sie damit noch über dem unteren border des großen DD - siehe Beispiel #1.

Also möchte ich das negative margin-top noch etwas vergrößern, auf -2em.

Huh, what's that? - Beispiel #2 [2]

Opera (8.51) und Firefox (1.5) stellen plötzlich den Text aller drei hochgezogenen DT/DD-Paare auf einem Fleck übereinander dar!
IE 6 hat damit kein Problem, der stellt wie gewünscht die drei Paare noch etwas höher als im ersten Beispiel, und damit "innerhalb" des Rahmens des ersten DD dar.

Habe ich in der CSS-Spezifikation bzgl. float etwas übersehen, was dieses Verhalten von Opera und Firefox logisch und nachvollziehbar für korrekt erklärt?
Aber ich durch das Erhöhen des negativen Margins von -1em auf -2em irgendeinen für mich unsichtbaren Bestandteil des ersten großen DD "berührt", der dieses absonderliche Verhalten auslöst?

Oder ist das ein gemeinsamer Bug?

gruß,
wahsaga

[1] OL und LI tun nichts zur Sache, Verhalten bleibt auch ohne sie gleich.
[2] Die Hintergrundfarben der DT/DD aus dem ersten Beispiel habe ich hier entfernt, da man so besser erkennt, dass alle Textinhalte einander überlagern.

[wahsaga]

hi,

OK, dann mach ich's halt anders - dann nutze ich kein negatives margin-top, sondern positioniere relativ mit negativem top - dann sieht es auch im Opera und FF wie gewünscht aus.
Dann muss ich nur schauen, ob ich dann die nachfolgenden, wiederum solche DLs enthaltenden LI dann ihrerseits wieder mit negativem margin-top nach oben ziehen kann, um die Platzreservierung der relativ positionierten DL-Kinder des vorherigen Elements wieder zu kompensieren - oder ob dann auch wieder irgendeiner rumzicken möchte.

Der Grund für das Verhalten von Opera und FF beim Beispiel interessiert mich aber trotzdem immer noch.

Habe mich jetzt noch mal mit http://www.w3.org/TR/CSS21/visuren.html#float-position beschäftigt - kann es sein, dass da einer der Punkte 4., 5. oder 6. auf mein Beispiel zutrifft? [1]

"4. Die äußere obere Kante einer Floating-Box darf nicht höher sein als die oberste Kante des umschließenden Blocks."

• der umschließende Block dürfte m.E. immer noch das DL sein (oder habe ich durch irgendeine weitere Formatierung noch die Bildung eines weiteren containing blocks bewirkt?), und über dessen obere Kante ziehe ich die DT und DD mit einem negativen margin von -2em noch nicht hinaus.

"5. Die äußere obere Kante einer Floating-Box darf nicht höher als die äußere obere Kante einer Block- oder Floating-Box liegen, die von einem früheren Element im Quelldokument erzeugt wurde."

• nun, über meinen drei gefloateten DT/DD-Paaren liegt das große DD im Fluss, und über dessen obere Kante ziehe ich sie auch nicht hinaus.

"6. Die äußere obere Kante der Floating-Box eines Elements darf nicht höher liegen als die obere Kante einer Zeilen-Box, die eine Box enthält, die von einem früheren Element im Quelldokument erzeugt wurde."

• Hm, ist es das?
  Nachdem ich das erste gefloatete DT mittels margin-top:-2em nach oben gezogen habe, fließt das nachfolgende DD bis ganz nach links an den Beginn der Zeile, und wenn ich dieses dann wiederum "entrücke", die nachfolgenden ebenso.
  Das könnte auch den mir zunächst unverständlichen "Sprung" erklären, warum dieses Phänomen erst beim Wechsel von -1em auf -2em (bzw. vermutlich irgendwo dazwischen) auftrat - an diesem Punkt habe ich wohl die Höhe einer Zeile überschritten ("recommended" für line-height, welches ich nicht angegeben hatte, ist laut Spec 1.0 bis 1.2) - woraufhin ich dann an dieser Stelle diesen Punkt 6. "verletzt" habe. Also habe ich das eine gefloatete Element "zu hoch" gehoben, und daraufhin rutscht das nachfolgende an den Anfang der Zeile nach.

Hell yeah, that's it.

Wenn ich für die gefloateten Elemente eine line-height von bspw. 3em vergebe, dann kann ich sie per negativem margin-top um bis zu -2.9em hinaufziehen - darüber tritt dann wieder der unangenehme Effekt auf.

gruß,
wahsaga

[1] Der Einfachheit halber halte ich mich hier im folgenden mal an die deutsche Übersetzung.

[Detlef G.]

Hallo wahsaga

OK, dann mach ich's halt anders - dann nutze ich kein negatives margin-top, sondern positioniere relativ mit negativem top - dann sieht es auch im Opera und FF wie gewünscht aus.

Wozu habe ich mir nun die Mühe gemacht? ;-)

Das könnte auch den mir zunächst unverständlichen "Sprung" erklären, warum dieses Phänomen erst beim Wechsel von -1em auf -2em (bzw. vermutlich irgendwo dazwischen) auftrat ...

ab 1.25em

... Wenn ich für die gefloateten Elemente eine line-height von bspw. 3em vergebe, dann kann ich sie per negativem margin-top um bis zu -2.9em hinaufziehen - darüber tritt dann wieder der unangenehme Effekt auf.

Da stellt sich mir dann allerdings die Frage, warum es auch bei height
funktioniert.

Auf Wiederlesen
Detlef

[wahsaga]

hi Detlef,

Wozu habe ich mir nun die Mühe gemacht? ;-)

Du willst mir ein "erst denken, dann (Problemstellung) posten"-Schildchen herüberreichen?
Ja, ich bin fast geneigt, es anzunehmen ...

ab 1.25em

In meinem Test mit dem Opera ab 1.2em, was wohl dessen Default für line-height zu entsprechen scheint (kann aber vermutlich auch mit von der Schriftgröße des Gesamtdokumentes und daraus resultierenden Rundungsunschärfen bei Dezimalbruchwerten abhängen).

Da stellt sich mir dann allerdings die Frage, warum es auch bei height funktioniert.

In meinem Beispiel gab es keine height-Angabe, d.h. die Höhe der gefloateten Elemente resultierte implizit aus der line-height.

Wir können also festhalten: Es kam hier auf das Überschreiten des computed value für height an (da dieser in meinem Falle die Höhe der "line-box" bestimmt) - damit stimmt auch deine Erklärung aus dem anderen Posting, mit dem "sich Berühren" der floats untereinander.

gruß,
wahsaga

[Detlef G.]

Hallo wahsaga

Du willst mir ein "erst denken, dann (Problemstellung) posten"-Schildchen herüberreichen?

Nein, nicht unbedingt (s. meine Signatur). Es wäre wirklich schade gewesen,
wenn dieser "Fallstrick" hier nicht zur Sprache gekommen wäre.

Auf Wiederlesen
Detlef

[wahsaga]

hi,

Du willst mir ein "erst denken, dann (Problemstellung) posten"-Schildchen herüberreichen?

Nein, nicht unbedingt (s. meine Signatur). Es wäre wirklich schade gewesen, wenn dieser "Fallstrick" hier nicht zur Sprache gekommen wäre.

Ja, ich bin dieser "Problematik" heute abend auch zum ersten Male über den Weg gelaufen.

"Wieder was gelernt™"

gruß,
wahsaga

[Detlef G.]

Hallo wahsaga

Huh, what's that? - Beispiel #2 [2]

Ich weiß nicht, was die Spezifikation zu gefloateten Boxen sagen, die sich
eigentlich gar nicht berühren (würden). ;-)

Dieses Verhalten tritt genau dann auf, wenn die Boxen die gleiche oder eine
geringere Höhe haben, als der negative margin.

Opera (8.51) und Firefox (1.5) stellen plötzlich den Text aller drei hochgezogenen DT/DD-Paare auf einem Fleck übereinander dar!

Das ist interessant, dass sich diese beiden einig sind.

Aber ich durch das Erhöhen des negativen Margins von -1em auf -2em irgendeinen für mich unsichtbaren Bestandteil des ersten großen DD "berührt", der dieses absonderliche Verhalten auslöst?

Nein, die Boxen würden sich einfach nicht mehr berühren, wenn sie nicht
_alle_ den negativen Margin hätten.

Wenn die Boxen keine Dekoration bekommen sollten (Rahmen, Hintergrund),
könntest du ihnen einfach eine genügende Höhe verpassen, ansonsten bleibt
wohl nur position:relative; um sie in den Rahmen zu bekommen.

Auf Wiederlesen
Detlef

[wahsaga]

hi Detlef,

danke dir für die Beschäftigung mit dem Problem - auch wenn ich mittlerweile Erklärung und Workaround selber herausfinden konnte.

Dieses Verhalten tritt genau dann auf, wenn die Boxen die gleiche oder eine geringere Höhe haben, als der negative margin.

Ja, da meine gefloateten Elemente ihre Höhe ja nur aus der line-height bezogen, auf die ich's dann mal geschoben habe, trifft deine Erklärung mit der height natürlich hier implizit ebenfalls zu.

Das ist interessant, dass sich diese beiden einig sind.

Und noch interessanter, dass sie offenbar laut Spezifikation mal wieder recht haben - im Gegensatz zum IE 6, auch wenn der tat, was ich "wollte" :-)

Nein, die Boxen würden sich einfach nicht mehr berühren, wenn sie nicht _alle_ den negativen Margin hätten.

Ja, das ist die Erklärung.
Dadurch, dass ich das erste gefloatete Element "zu hoch" hebe, fließt das nächste wieder bis an den linken Zeilenrand. Ob ich dieses zweite danach ebenfalls noch mit negativem Margin auf gleiche Höhe zu heben versuche, spielt keine Rolle mehr.

Wenn die Boxen keine Dekoration bekommen sollten (Rahmen, Hintergrund), könntest du ihnen einfach eine genügende Höhe verpassen, ansonsten bleibt wohl nur position:relative; um sie in den Rahmen zu bekommen.

Ja, danke nochmals - beide Möglichkeiten waren mir inzwischen auch eingefallen.

Das mit dem "Berühren" wird übrigens noch besser vorstellbar, wenn man berücksichtigt, dass bei relativer Positionierung der Effekt nicht auftritt - durch die Platzreservierung hat das nachfolgende floatende Element "noch jemanden vor sich", was es davon abhält, ganz an den linken Zeilenrand zu fliessen.

gruß,
wahsaga

[Detlef G.]

Hallo

Wenn die Boxen keine Dekoration bekommen sollten (Rahmen, Hintergrund),
könntest du ihnen einfach eine genügende Höhe verpassen, ansonsten bleibt
wohl nur position:relative; um sie in den Rahmen zu bekommen.

Auch ein passendes margin-bottom sorgt dafür, dass es wie gewünscht angezeigt
wird.

Egal wie, es muss dafür gesorgt werden, dass sich die Bereiche berühren, die
mit oder ohne negativem margin für die Elemente reserviert wären.

Auf Wiederlesen
Detlef

[wahsaga]

hi,

Auch ein passendes margin-bottom sorgt dafür, dass es wie gewünscht angezeigt wird.

Eine weitere Möglichkeit, die - nachdem man den Grund für dieses Verhalten erst einmal verstanden hat - recht logisch erscheint.

Egal wie, es muss dafür gesorgt werden, dass sich die Bereiche berühren, die mit oder ohne negativem margin für die Elemente reserviert wären.

Ja, ja, jaaa ...  (noch öfter möchte ich dir in diesem Thread jetzt aber nicht Recht geben müssen ;-)

gruß,
wahsaga