Dnia Fri, 10 Feb 2012 01:03:13 +0100, NotBear napisał(a):

> Pytalem o nature elementu, nie jego zastosowanie.
>
> Swoją drogą, piszesz "rozdzielanie", a w przykladzie nizej stawiasz HR
> na poczatku bloku. Jaki to ma sens?

Ma to zastosowanie gdy np. ten blok zawiera serię przylegających do siebie
przycisków. Chciałbym aby nad nimi był HR i wyglądał tak samo jak w każdej
innej sekcji.

Blok powyżej tego bloku z przyciskami zawiera inną treść. No i powstawał
niepożądany odstęp pomiedzy blokami wskutek collapsingu a raczej nazwałbym
to zjawisko "bąbelkowaniem" a nie "zapadaniem" się marginesów gdyż margines
nie znika lecz przenosi się w górę kodu do innych elementów.

>
>> Co mi z elementu, w którym nie da się ustawić obu odległości (od góry i od
>> dołu)?
>
> Ależ da się. Margin top/bottom działa.

Tyle tylko, że margin top znika przy HR a pojawia się ponad DIVem. Wiec w
tym konkretnym przypadku nie działa a nawet więcej: psuje layout w innym
miejscu strony WWW. Dlatego napisałem, że nie działa.

>> Collapsing przenika przez elementy po to aby wypłynąć w "przypadkowym"
>> miejscu layoutu. Nagle ni z gruszki ni z pietruszki dostajesz odstęp miedzy
>> elementami, które nigdy go wcześniej nie miały zanim ktoś gdzieś dalej w
>> kodzie zastosował HR. Powtórzę ten przypadek poniżej.
>
> Nieprzypadkowym. Sa zasady, ktore to okreslaja.

I o nich mówię, krytycznie zresztą. Ale to tylko dygresja.

> Ale wrocmy do pierwotnego problemu. Moim zdaniem zamiast tworzyc wyjatki
> dla roznistych elementow, wystarczy "zatamowac" raz a dobrze collapsing
> tam gdzie jest zbedny.

Tak, ideologicznie masz rację. Jednakże ja nie potrafię tego dokonać.
Rozważmy konkretny przypadek jaki zaprezentowałem. Bez overflow:hidden
layout strony będzie się rozpadał. Jak w takich warunkach można zapanować
nad collapsingiem?

Problem dla mnie jest istotny gdyż nierzadko stosuję HR zaraz po DIV z
powyższego powodu. Po drugie nie mogę wykluczyć sytuacji, w której w CMS
redaktor treści strony nie uczyni tego samego. Dlatego muszę "zabezpieczyć"
się jakoś przed destrukcją layoutu wskutek użycia HR.

> Zaleznie od mozliwosci i zamierzen (dlatego prosilem o pokazanie tej
> problematycznej strony, bo kazda metoda ma jakies uwarunkowania) mozna
> zastosowac na rodzicu:
> - border

Ale wtedy powstaje linia przerwy w layoucie i aby się jej pozbyć to na
poziomie potomka należy podsuwać o 1 px do góry. Pisałem o tym wcześniej.
Owszem, można tego dokonać jednakże trzeba te "łatki" stosować na parach
elementów rodzic/potomek w wielu miejscach kodu gdzie HR może potencjalnie
wystąpić a to czasem jest trudne do przewidzenia. Dlatego rozwiązanie z
overflow: auto wydaje mi się bezpieczniejszym (mniejsze ryzyko
niedopatrzenia).

> - padding
> - wspominane juz kombinacje border lub padding z ujemnym marginesem

Temat j/w. Ingerencja potrzebna jest wtedy w identyczny sposób.

> - display:inline-block

A to może faktycznie być użyteczne czasem.

>
> - #rodzic:before{content: "."; display:block; visibility:hidden;
> height:0;} (inspirowane clearfixem)

A to jest super. Rozumiem, że content nie musi kropki zawierać?

>> Pewnie zaproponujesz rozwiązanie aby w drugim DIVie ustawić
>> padding górny na 1 px i przesunąc DIVa o 1px po to aby zniwelować ten
>> niepotrzebny padding. Zapomnijmy o takim rozwiązaniu - jest chore. Powstaną
>> tylko kolejne problemy.
>
> Konkretnie jakie?

Opisałem powyżej w komentarzu do "border". Idealnym rozwiązaniem byłoby
ostylowanie HR, ale jeśli się nie da, to mogę to zrobić na poziomie
rodzica.