Dnia Fri, 06 Jan 2012 02:36:14 -0000, porneL napisał(a):

> Nie tyle szkodzi, co komplikuje implementację, bo pozycjonowanie zależy od
> wymiarów containing block, a wymiary komórek są obliczane w zupełnie inny
> sposób, niż inne boksy.
>
> Możliwe, że to ograniczenie zostanie w przyszłości zniesione. Było w
> czasach, gdy żadna przeglądarka nie przechodziła Acid2 i wszystkie miały
> problemy nawet z prostym position:relative :)

No dobrze - dajmy więc szansę developerom na dokończenie dzieła :-)

> CSS2 został zaprojektowany do progresywnego renderowania.

Rozumiem. Jednakże dla table-cell działa vertical-align a przecież dalsze
elementy HTML modyfikują wysokość poprzednich.

> CSS nie miał możliwości "naprawienia" zachowania komórek tabel (które
> niegdyś nie były progresywnie renderowane i do dziś są problematyczne i
> powolne do progresywnego renderowania), więc też nie było powodu, żeby
> ograniczać vertical-align.

No właśnie :-)

> Nowe właściwości CSS już nie trzymają się tych ograniczeń (np. możesz mieć
> vertical-align z flex-box).

Super ! :-)

> Ale wtedy:
>
> <h1>x</h1>
> <p>
> się zleje.

Nie, ponieważ pod H1 tez można odstęp zdefiniować.

h1 {
margin-top: 0px; - ochrona przed collapsingiem
margin-bottom: 20px;
}

Jeśli natomiast chciałbyś aby H2 był oddalony od H1 o np. 5px, ale
standardowe 20px od tekstu to dajesz:

H! H2 {
margin-top:-15px;
margin-bottom: 20px;
}

> Jak dodasz:
>
> <div style=background:red>
> <p/>
> <p/>
> </div>
>
> to będziesz mieć odstęp na dole, ale nie na górze, więc wtedy dajesz
> p:last-child {margin:0}, ale wtedy zepsuje ci się:
>
> <div>
> <p/>
> </div>
> <p/>

Wydaje mi się to komplikowaniem sobie życia: generalna zasada: zerujemy
górne marginesy elementp P, Hx, UL itp i ustawiamy dolne. Wszystko będzie
wyglądać jak należy.

> Ponadto:
>
> <ul>
> <li><p/></li>
> <li><p/></li>
> </ul>
>
> będzie miało podwójne marginesy na około listy. No i dorzucisz jeszcze
> więcej selektorów, żeby zrobić własne zapadanie marginesów...

Dlaczego podwójne? Pod P i pod LI? To masz na myśli? Bo nad elementami
zerujemy je.Jeśli są one niepożądane (czyli mają wygladać inaczej) to da
się to ostylować odpowiednio. Do tego właśnie stylowanie służy :-)
Nieprawdaż ? :)


> To zachowanie jest potrzebne dla przykładu z listą, które podałem powyżej.
> Ponadto bez zapadania marginesów nie było by różnicy między margin a
> padding w takiej liście (nie było by możliwości dodania tła do zawartości
> bez dodawania tła pod marginesami).

Ależ to nie tak :-) Jest różnica między marginesami i paddingami gdy
stosujemy tło. Ponadto zauważ, że jeśli padding zastosujesz to przerywasz
collapsingowanie i nagle rozwala się cała koncepcja strony. Często
doświadczam czegoś takiego we współpracy z klientami, którzy zażyczą sobie
"drobnej" korekty w istniejącym projekcie wymagającej dodania paddingu.
Dzięki wyłączaniu efektu collapsingu takie zmiany dokonuję bez
zastanawiania się bo wiem, że nic się nie rozpadnie.

> Jak dla <div> dasz border/padding-top:1px albo overflow:hidden, to
> margines się przez to nie "przebije".

Ale wtedy masz linię przez podzieloną grafikę. A gdy dasz overflow:hidden,
to zapomnij o elementach pozycjonowanych absolutnie, które mają wyjść poza
obrys rodzica. Nioe lubię zastawiać na siebie pułapek, które w przyszłości
będą mnie ograniczały.

>>
>> Wcale nie! Dzięki wielokrotnym spacjom (najczęściej w Wordzie
>> popełnianych)
>> nauczyłem się kiedyś wyrażeń regularnych do usuwania wielokrotnych spacji
>> :-D
>
> Jak ci pasuje "box model Worda", to spokojnie możesz używać &nbsp; i <br>
> zamiast CSS ;)

Mam badzieję, że odebrałeś moje słowa jako żart :-)