nicht angemeldet
Collapsing Margins Strategie
Hallo werte Selfgemeinde!
Mich würde mal interessieren, wie ihr eigentlich (generell) mit "collapsing margins" umgeht?
Prinzipiell gibt es ja eigentlich nur 2 grundlegende Varianten:
1. Man nutzt/ verwendet sie
2. Man vermeidet/ unterbindet sie
Oder habt ihr noch eine andere Variante?
Wenn ihr nach Variante 2 verfahrt, wie sieht eure Vorgehensweise zur Vermeidung aus (padding, border etc.)?
Gruß Gunther
-
Hallo,
ich habe eigentlich nie große Probleme mit Collapsing Margins, sondern mit sich addierenden Margins. Solange Margins collapsen, ist alles in Ordnung, solange man konsistente Abstände und wiederkehrende Strukturen hat.
Generell lege ich Regeln fest wie: Alle Low-Level- und High-Level-Komponenten haben vertikale Margins, am besten nur margin-bottom.
Das führt dann aber zu doppelten Margins, wenn Floats und andere Block Formatting Contexts das Zusammenfallen von Margins verhindern. Beispiel:
http://codepen.io/molily/pen/oEwnm?editors=110
Hier musste ich zwei Regeln anwenden, um die Margins für die letzten Elemente wieder auszuschalten. Das ist nicht robust und skalierbar, weil ich tief in die Komponenten hineingehen muss bzw. wilde Kombinationen und Reihenfolgen annehmen muss. Auf einer wirklichen Seite gibt es dutzende mögliche Komponenten dieser Art und viele Arten, wie deren Inhalt aufgebaut sein kann.
Mathias
-
Hallo Mathias!
ich habe eigentlich nie große Probleme mit Collapsing Margins, sondern mit sich addierenden Margins.
OK, aber das ist ja nur dann ein "Problem", wenn man generell Collapsing Margins verwendet. ;-)
Solange Margins collapsen, ist alles in Ordnung, solange man konsistente Abstände und wiederkehrende Strukturen hat.
Generell lege ich Regeln fest wie: Alle Low-Level- und High-Level-Komponenten haben vertikale Margins, am besten nur margin-bottom.
Das führt dann aber zu doppelten Margins, wenn Floats und andere Block Formatting Contexts das Zusammenfallen von Margins verhindern.
Collapsing Margins sind ja einer der "Automatismen" in CSS.
Sicherlich einerseits ganz praktisch, solange sie da greifen, wo man sie als Autor auch gebrauchen kann/ haben will.Aber "der Preis, den man dafür bezahlt" hast du ja in deinem Beispiel u.a. auch schon aufgezeigt.
Außerdem macht es das ganze Gebilde einer Website auch ziemlich "fragil" im Bezug auf Änderungen/ Anpassungen, wenn man bspw. etwas hinzufügt/ ändert, was dann bspw. das Collapsing verhindert.Das ist nicht robust und skalierbar, weil ich tief in die Komponenten hineingehen muss bzw. wilde Kombinationen und Reihenfolgen annehmen muss. Auf einer wirklichen Seite gibt es dutzende mögliche Komponenten dieser Art und viele Arten, wie deren Inhalt aufgebaut sein kann.
Das ist eben einer der Gründe, warum ich mir die Frage stelle, ob es nicht "besser" ist, generell auf Collapsing Margins zu verzichten (sie also grundsätzlich zu unterbinden/ verhindern)?
Das hätte imho den Vorteil, dass man keine "unliebsamen Überraschungen" erlebt.
Der Nachteil ist u.a., dass man einen (geringfügig?) höheren Aufwand betreiben muss.Passend zum Thema:
http://css-tricks.com/spacing-the-bottom-of-modules/Gruß Gunther
-
Hallo,
ob es nicht "besser" ist, generell auf Collapsing Margins zu verzichten
Mit welchem Gewinn? Wenn ich mein Beispiel z.B. mit Padding-Bottoms baue, hätte ich dieselben Probleme.
Das hätte imho den Vorteil, dass man keine "unliebsamen Überraschungen" erlebt.
Ich wüsste nicht, welches unliebsame Verhalten ich durch Collapsing Margins habe, das ich ohne bzw. bei Paddings nicht habe. Bei Paddings habe ich vielmehr *konsequent* unliebsames Verhalten.
Das beschreibt meine Probleme sehr gut, eine Lösung scheint es nicht zu geben.
Mathias
-
Hallo,
ob es nicht "besser" ist, generell auf Collapsing Margins zu verzichten
Mit welchem Gewinn?
Na u.a. mit dem, dass du "einheitliche" Abstände hast, und zwar unabhängig davon, ob Collapsing Margins gerade greifen, oder nicht!
Wenn ich mein Beispiel z.B. mit Padding-Bottoms baue, hätte ich dieselben Probleme.
In deinem Beispiel vielleicht. Aber gerade bei responsiven Layouts mit diversen Breakpoints und unterschiedlichen Formatierungen für ein und dasselbe Element, hätte es imho Vorteile.
Das hätte imho den Vorteil, dass man keine "unliebsamen Überraschungen" erlebt.
Ich wüsste nicht, welches unliebsame Verhalten ich durch Collapsing Margins habe, das ich ohne bzw. bei Paddings nicht habe. Bei Paddings habe ich vielmehr *konsequent* unliebsames Verhalten.
Du verwendest ja schon eine mögliche Variante zur Vermeidung der Collapsing Margins Problematik. Denn wenn 'margin-top' generell '0' ist, kann auch nicht "collapsen"! ;-)
Das beschreibt meine Probleme sehr gut, eine Lösung scheint es nicht zu geben.
Was gefällt dir an der angegebenen "Lösung/ Variante" nicht?
Gruß Gunther
-
Hallo,
Du verwendest ja schon eine mögliche Variante zur Vermeidung der Collapsing Margins Problematik. Denn wenn 'margin-top' generell '0' ist, kann auch nicht "collapsen"! ;-)
Ja, margin-top und margin-bottom collapsen nicht, wenn margin-top vermieden wird. Dann muss man sich aber bewusst sein, dass der Abstand immer vom *vorherigen* Element gesteuert wird. Das ist problematisch, wenn z.B. vor einer Überschrift ein größerer Abstand sein soll als der Standardabstand, den z.B. ein p-Element davor bringt. Entweder man arbeitet dann mit margin-top oder man wrappt beide Abschnitte in entsprechende Module, die passende margin-bottom erhalten.
Ich nutze wie gesagt immer noch Collapsing Margins, nämlich von den margin-bottoms:
<div style="margin-bottom: 10px"> <div style="margin-bottom: 10px"> <div style="margin-bottom: 10px"> foo </div> </div> </div> <div>bar</div>Der Abstand zwischen den »foo«- und »bar«-Boxen ist hier durch den Collapse eben 10px und nicht 30px. Erst durch Block Formatting Contexts wird dieses an sich nützliche Verhalten unterbunden.
Was gefällt dir an der angegebenen "Lösung/ Variante" nicht?
.module > *:last-child, .module > *:last-child > *:last-child, .module > *:last-child > *:last-child > *:last-child { margin: 0; }Das ist m.E. keine Lösung, sondern ein fieser, unperformanter, unzureichender Hack. Den würde ich so auf keine Site einsetzen, auf der ich wirklich flexiblen Inhalt erwarte (d.h. beliebige Verschachtelung von Modulen, beliebige Kombinierbarkeit von Modulen).
Ich sage nicht, dass ich eine bessere Lösung kenne. Ich versuche das Problem meist zu begrenzen und ggf. wenige spezifische :last-child-Regeln zu notieren, anstatt obiges »Bombardement«.
Grüße
Mathias-
Hallo,
Du verwendest ja schon eine mögliche Variante zur Vermeidung der Collapsing Margins Problematik. Denn wenn 'margin-top' generell '0' ist, kann auch nicht "collapsen"! ;-)
Ja, margin-top und margin-bottom collapsen nicht, wenn margin-top vermieden wird. Dann muss man sich aber bewusst sein, dass der Abstand immer vom *vorherigen* Element gesteuert wird. Das ist problematisch, wenn z.B. vor einer Überschrift ein größerer Abstand sein soll als der Standardabstand, den z.B. ein p-Element davor bringt. Entweder man arbeitet dann mit margin-top oder man wrappt beide Abschnitte in entsprechende Module, die passende margin-bottom erhalten.
Ich nutze wie gesagt immer noch Collapsing Margins, nämlich von den margin-bottoms:
<div style="margin-bottom: 10px">
<div style="margin-bottom: 10px">
<div style="margin-bottom: 10px">
foo
</div>
</div>
</div>
<div>bar</div>Ich habe dein Beispiel mal eben als JSFiddle erstellt: <http://jsfiddle.net/pSmW7/> > Der Abstand zwischen den »foo«- und »bar«-Boxen ist hier durch den Collapse eben 10px und nicht 30px. Erst durch Block Formatting Contexts wird dieses an sich nützliche Verhalten unterbunden. Oder dir fällt ein, dass du um die äußeren DIV-Elemente doch eine Border haben möchtest ...! Hier wieder als JSFiddle: <http://jsfiddle.net/WLA9d/1/> (die zusätzliche blaue Umrandung der P-Elemente dient nur der besseren Erkennbarkeit) Das demonstriert die "Fragilität" solcher Konstrukte, die ich meine/ meinte. Und auch hier zeigt sich wieder eine der sagen wir mal "Unzulänglichkeiten" von CSS im Bezug auf die Selektoren. Denn um mit der "nur margin-bottom Methode" das gewünschte Ergebnis zu erreichen, bräuchte man entweder einen 'Parent-Selektor', oder müsste Rückschlüsse auf die jeweiligen Kind-Elemente ziehen können - beides ist nicht möglich. Stattdessen muss man in diesem Fall dann bspw. auf 'margin-top' ausweichen, wie in diesem Beispiel: <http://jsfiddle.net/y25k8/> Oder eben alternativ 'margin-bottom' (in diesem Fall für die Klasse "mb") für verschachtelte Elemente wieder aufheben (auf Null setzen) - Beispiel: <http://jsfiddle.net/L7uvy/> Je mehr ich darüber nachdenke, umso mehr komme ich zu der Überzeugung, dass es sich "nicht lohnt", für die Fälle, wo man das Collapsing tatsächlich bewusst haben will, die möglichen unerwünschten "Nebenwirkungen" (also Collapsing, wo nichts collapsen soll, und nicht-collapsen, wo es collapsen soll) in Kauf zu nehmen. Die Variante grundsätzlich nur 'margin-bottom' zu verwenden, erscheint mir dabei als die beste Ausgangsbasis. Aber wie gesagt, ohne Collapsing Margins "einzuplanen/ -bauen". Gruß Gunther-
Hallo,
da sind mir doch ein paar Fehler unterlaufen, sorry!
Unten jetzt mit den (hoffentlich) korrekten Links:
Stattdessen muss man in diesem Fall dann bspw. auf 'margin-top' ausweichen, wie in diesem Beispiel: http://jsfiddle.net/y25k8/1/
Oder eben alternativ 'margin-bottom' (in diesem Fall für die Klasse "mb") für verschachtelte Elemente wieder aufheben (auf Null setzen) - Beispiel: http://jsfiddle.net/L7uvy/1/
Gruß Gunther
-
-
-
-
-
-