Je suis tombé sur ce problème plusieurs fois. N'avez toujours pas indifférent ce qui cause ceci.
reproduire:
.L-Search-index .top { @ Line 26
- Changer
bordure: 1px solide # FF0000; à bordure: 0;
- Whaaat?
Navigateur: Chrome, mais je pense que vous pouvez essayer dans n'importe quel autre ..
Veuillez conseiller!
3 Réponses :
C'est à faire avec le passage des marges qui se chevauchent et comment certaines propriétés les forcent à être contenues. Si vous placez 2x divs sur une page, les deux avec des marges 100px, l'espacement entre ces divs sera 100px. Pas 200px. C'est parce que les marges sont autorisées à chevaucher d'autres marges. C'est juste comment les marges fonctionnent. C'est une bonne chose.
Mais si vous mettez une DIV à l'intérieur d'un autre div, les deux avec des marges, alors ces marges se chevauchent également. Les marges de l'élément enfant chevauchent les parents.
Mais, certaines propriétés - frontière, comme vous l'avez découvertes, mais aussi le rembourrage et le débordement - forcer le parent à contenir les marges de son enfant au lieu de les chevaucher.
Je suis sûr que quelqu'un peut donner une explication plus technique, mais c'est comme ça que je pense à ce qui se passe.
Voici un cas de test simplifié: http://jsbin.com/ukodus/2/ de "Ce comportement s'appelle de la marge effondrement. Seules les marges supérieure / inférieure s'effondreront, pas de gauche / droite." - @CIMMANON
Supprimer le // avant l'une des lignes de CSS pour voir l'effet.
Ce comportement s'appelle marge effondrer . Seules les marges supérieures / inférieures s'effondreront, pas de gauche / droite.
+1, merci, vos cas de test sont très utiles. J'accepterais aussi cette réponse!
Voici la solution.
.l-search-index .top{border: 0; height: 70%; overflow: auto;}
Aide :), mais comme je l'ai mentionné dans ma question, je veux vraiment connaître le fond de ce phénomène.
Voici le lien qui aidera vos questions. Dustwell.com/div-span-inline-block.html - Lisez-les Dans le contexte de vos deux classes 1) .L-Search-index .top et 2) .L-Search-index .icon - @zsitro
Ceci est un cas tout à fait non intuitif de marges d'effondrement:
§ 8.3.1 de la spécification CSS explique comment Les marges sont manipulées et dans quelles circonstances ils s'effondrent. Les règles ne sont pas trop faciles à comprendre (ont plusieurs cas spéciaux), mais je cite les parties pertinentes de la spécification pour vous:
en CSS, les marges adjacentes de deux boîtes ou plus (
qui pourraient ou pourrait ne pas être des frères et sœurs ) peuvent combiner pour former une marge unique. Marges qui se combinent de cette façon sont censés s'effondrer et le résultant combiné La marge s'appelle une marge effondrée. Deux marges adjacentes si et seulement si: pas de boîtes de ligne, pas de dégagement, pas de rembourrage et Aucune frontière ne les séparez
(souligné par moi)
Donc, dès que vous enlevez la frontière, les marges verticales de vos éléments s'effondrent. Votre cas le rend un peu compliqué puisque vous avez des marges négatives.
Pour résoudre ce problème, vous pouvez définir la propriété
Overflow ou appliquer unPADDING: 1PX sur le.top élément.
La partie clé ici est " qui pourrait ou non être des frères et sœurs ". Dans l'exemple original, il est facile de voir qu'il n'était pas intuitif que les marges se touchent mutuellement.
Merci pour le référencement aux spécifications!
Peut-être un problème avec JSBIN .. Ou est-ce que cela se produit dans votre code de test aussi?
Dans l'environnement propre: JSBIN.com/IBOWED/1/Quiet -> F12, Cochez la frontière sur
.top div. Même.+1; très étrange. Il est déclenché par le négatif
Marge-top sur la DIV intérieure; Supprimer cela de l'équation et basculer la frontière fonctionne maintenant comme prévu. Je ne peux pas expliquer pour le moment pourquoi le style de l'élément interne devrait cependant avoir cet effet sur l'élément extérieur.C'est juste comment les marges fonctionnent. Ils se chevauchent naturellement. Voir ma réponse non technique de merde et la réponse du test JSBIN.
@Dominic - en effet et +1 pour la réponse. Je n'avais pas eu l'occasion de le penser encore pour atteindre cette conclusion, mais vous avez évidemment frappé le clou sur la tête.
@Spudley :) Je ne pense pas que le test de Zxitro rend évident ce qui se passe.