Jak to jest w HTMLu (przynajmniej 4tym) - czy znaczniki typu blokowego nie
pozwalają się tak ostylować aby wizualnie wyglądały tak samo w każdej
sytuacji? Czy jest jakiś magiczny, nie podlegający nadpisaniu CSS
przeglądarki, który nie pozwoli np. tagowi <fieldset> wyglądać tak jak
<div>?

do góry

W dniu 2012-01-04 23:28, Marek pisze:
> Jak to jest w HTMLu (przynajmniej 4tym) - czy znaczniki typu blokowego nie
> pozwalają się tak ostylować aby wizualnie wyglądały tak samo w każdej
> sytuacji? Czy jest jakiś magiczny, nie podlegający nadpisaniu CSS
> przeglądarki, który nie pozwoli np. tagowi<fieldset> wyglądać tak jak
> <div>?

display:inline; / display:block;
o to kaman?
pozdr,b

do góry

Dnia Thu, 05 Jan 2012 15:07:45 +0100, beherit napisał(a):

> display:inline; / display:block;
> o to kaman?

Mniej więcej. A teraz test z innym typem display przypisanym do fieldsetu.

<div style="display:table;">
<fieldset style="display:table-cell; margin: 0px; padding: 0px;
background-color:#FF0000; border: none">
aaa
</fieldset>
<div style="display:table-cell; height:500px;
background-color:#00FF00">bbb</div>
<div style="display:table-cell; background-color:#0000FF">ccc</div>
</div>

No i teraz fieldset zaczyna wyglądać inaczej niż DIV. Wygląda na to, że ma
on awersję na bycie table-cell i to w IE9 jak i FF lub też posiada jakieś
boskie style dziedziczone z przeglądarek.Przypuszczam, że znów W3C
wymyśliło kolejną kretyńską, niczym nie uzasadnioną zasadę obok kilku
innych takich jak:

I
<div style="display: table-cell"> nie może być position:relative

II
Niczym nie uzasadniony i cholernie przeszkadzający efekt margin collapse.

to tak na gorąco...

do góry

On Wed, 04 Jan 2012 22:28:04 -0000, Marek <p...@s...com> wrote:

> Jak to jest w HTMLu (przynajmniej 4tym) - czy znaczniki typu blokowego
> nie pozwalają się tak ostylować aby wizualnie wyglądały tak samo w każdej
> sytuacji? Czy jest jakiś magiczny, nie podlegający nadpisaniu CSS
> przeglądarki, który nie pozwoli np. tagowi <fieldset> wyglądać tak jak
> <div>?

Tak, przeglądarki mogą mieć "replaced elements", które nie są stylowalne.
Niegdyś to się tyczyło wszystkich elementów formularzy, bo były rysowane
przez system operacyjny, a nie przeglądarkę.

Poza tym zachowania <br> nie da się dokładnie opisać za pomocą CSS.

> <div style="display: table-cell"> nie może być position:relative

To jest reguła w CSS. Komórki tabel mają inny box-model i robienie z nich
"containing block" komplikuje wiele rzeczy.

> Niczym nie uzasadniony i cholernie przeszkadzający efekt margin collapse.

Próbowałeś uzyskać spójne odstępy między akapitami, listami i nagłówkami
bez zapadania marginesów? (np. stylami w MS Word [amatorskie robienie
odstępów "enterami" się nie liczy]) IMHO tragedia.

Zapadanie się marginesów może i jest skomplikowane i czasem przeszkadza,
ale ma swój cel: dzięki niemu `p,ul {margin: 1em 0;}` po prostu działa,
zamiast robić podwójne odstępy lub wymagać "ręcznego zapadania" `p + ul
{margin-top:0;}`.

--
regards, porneL

do góry

Dnia Thu, 05 Jan 2012 19:02:01 -0000, porneL napisał(a):

> Tak, przeglądarki mogą mieć "replaced elements", które nie są stylowalne.
> Niegdyś to się tyczyło wszystkich elementów formularzy, bo były rysowane
> przez system operacyjny, a nie przeglądarkę.

Zauważ, że <fieldset> ładnie działa we wszystkich innych sytuacjach niż
table-cell. Czy to może oznaczać, że jeśli rysunek tej kontrolki podaje
system, to że nie poradzi sobie z obsługą jej w "trybie" table-cell? Czy to
właśnie miałeś na myśli?

> Poza tym zachowania <br> nie da się dokładnie opisać za pomocą CSS.

Może z wyjątkiem line-height :-)

>> <div style="display: table-cell"> nie może być position:relative
>
> To jest reguła w CSS. Komórki tabel mają inny box-model i robienie z nich
> "containing block" komplikuje wiele rzeczy.

A czy możesz podać jakiś przykład w jaki position: relative mógłby
zaszkodzić w "działaniu" komórki tabeli?
Jest też pewna sprzeczność. Konstrukcja:

<div style="display: table-cell">
<div style="position:relative>
....tu kod
</div>
</div>

zadziała. Czyli pozycjonowanie elementu względem górnego lewego rogu
komórki może zadziałać poprawnie za pomocą takiej sztuczki. Jednakże będzie
problem z równaniem do dołu tejże komórki gdy ma ona automatyczną wysokość.

A'propos: kolejnym takim absurdem jest dla mnie to, że vertical-align może
działać tylko w obrębie komórki tabeli. Dlaczego nie można wyrównać
zawartości DIVa do jego dolnej krawędzi a do prawej lub lewej owszem?

<div style="height:500px; vertical-align:bottom">
bla bla bla
</div>


>> Niczym nie uzasadniony i cholernie przeszkadzający efekt margin collapse.
>
> Próbowałeś uzyskać spójne odstępy między akapitami, listami i nagłówkami
> bez zapadania marginesów ?

Pogubiłem się. Wydaje mi się to banalne:

<p>aaa</p>
<p>bbb</p>
<ul>
....

gdzie

p, ul {
margin-top: 0; - zero musi być jako zabezpieczenie przed collapsing margins
margin-bottom: 10px;
}

Natomiast nie zapanuję nad tym gdy:

<head>
<style type="text/css">
p {
margin-top: 20px;
margin-bottom: 0px;
}
</style>
</head>

<body style="margin:0; padding:0;">
<div style="background-color:#090">
<p>aaaaa</p>
</div>
</body>

Wtedy pomiędzy <div> a <body> tworzy się dziura. Ma to przykre konsekwencje
np. dla twórców CMSów. Jeśli cały kod z wyjątkiem <p> jest formatką a
użytkownik wprowadzi do treści <p>, to w tym momencie rozpadnie się strona
w zupełnie innym miejscu niż jest wprowadzona treść. To tak jakbyś
potrząsał śliwą aby owoce z niej spadły a zamiast tego opadnły jabłka i to
w sąsiednim ogrodzie.


> (np. stylami w MS Word [amatorskie robienie
> odstępów "enterami" się nie liczy]) IMHO tragedia.

Wcale nie! Dzięki wielokrotnym spacjom (najczęściej w Wordzie popełnianych)
nauczyłem się kiedyś wyrażeń regularnych do usuwania wielokrotnych spacji
:-D

> Zapadanie się marginesów może i jest skomplikowane i czasem przeszkadza,

Ba! Ja tego doświadczałem tylko w taki sposób, że przeszkadza.Nauczyłem się
robić pułapki w odpowiednim ostylowywaniu zabezpieczające przez
wystąpieniem efektu. Nie znam żadnego praktycznego zastosowania tego
pokrętnego mechanizmu.

> ale ma swój cel: dzięki niemu `p,ul {margin: 1em 0;}` po prostu działa,
> zamiast robić podwójne odstępy lub wymagać "ręcznego zapadania" `p + ul
> {margin-top:0;}`.

Ale ten odstęp nie przepada lecz pojawia się w najmniej oczekiwanym
miejscu. Powędruje sobie przez strukturę dokumentu i wypłynie jak zwłoki
topielca w innym miejscu.

do góry

W dniu 2012-01-05 23:02, Marek pisze:
> p, ul {
> margin-top: 0; - zero musi być jako zabezpieczenie przed collapsing margins

Żądamy gwarantowanego odstępu od góry i od dołu niezależnie od tego, z
jakimi elementami P sąsiaduje. Lepiej widać to na przykładzie Hx. Z
reguły definiujesz bardzo duży odstęp od góry i sporo mniejszy od dołu.

> <head>
> <style type="text/css">
> p {
> margin-top: 20px;
> margin-bottom: 0px;
> }
> </style>
> </head>
>
> <body style="margin:0; padding:0;">
> <div style="background-color:#090">
> <p>aaaaa</p>
> </div>
> </body>
>
> Wtedy pomiędzy<div> a<body> tworzy się dziura. Ma to przykre konsekwencje
> np. dla twórców CMSów.

Przykre? Treści to akurat nie przeszkadza.

-webkit-margin-collapse padding>0 lub border :-)

Pociesz się, że boxing model dla XSL-FO jest jeszcze bardziej pokręcony,
a przy tym gorzej udokumentowany :-)

artur

do góry

On Thu, 05 Jan 2012 22:02:10 -0000, Marek <p...@s...com> wrote:

>> To jest reguła w CSS. Komórki tabel mają inny box-model i robienie z
>> nich
>> "containing block" komplikuje wiele rzeczy.
>
> A czy możesz podać jakiś przykład w jaki position: relative mógłby
> zaszkodzić w "działaniu" komórki tabeli?

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 :)

> Jest też pewna sprzeczność. Konstrukcja:
>
> <div style="display: table-cell">
> <div style="position:relative>
> ....tu kod
> </div>
> </div>
>
> zadziała. Czyli pozycjonowanie elementu względem górnego lewego rogu
> komórki może zadziałać poprawnie za pomocą takiej sztuczki. Jednakże
> będzie
> problem z równaniem do dołu tejże komórki gdy ma ona automatyczną
> wysokość.
>
> A'propos: kolejnym takim absurdem jest dla mnie to, że vertical-align
> może
> działać tylko w obrębie komórki tabeli. Dlaczego nie można wyrównać
> zawartości DIVa do jego dolnej krawędzi a do prawej lub lewej owszem?

CSS2 został zaprojektowany do progresywnego renderowania. Elementy później
w dokumencie nie powinny wypływać na to, co zostało narysowane na ekranie.
Z tego samego powodu też nie było selektora rodzica ("a < img" albo "$a >
img" w CSS4). Z tej cechy korzystał silnik Opery 6.

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.

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

> Pogubiłem się. Wydaje mi się to banalne:
>
> <p>aaa</p>
> <p>bbb</p>
> <ul>
> ....
>
> gdzie
>
> p, ul {
> margin-top: 0; - zero musi być jako zabezpieczenie przed collapsing
> margins
> margin-bottom: 10px;
> }

Ale wtedy:

<h1>x</h1>
<p>

się zleje.

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/>

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...

> Natomiast nie zapanuję nad tym gdy:
>
> <head>
> <style type="text/css">
> p {
> margin-top: 20px;
> margin-bottom: 0px;
> }
> </style>
> </head>
>
> <body style="margin:0; padding:0;">
> <div style="background-color:#090">
> <p>aaaaa</p>
> </div>
> </body>
>
> Wtedy pomiędzy <div> a <body> tworzy się dziura. Ma to przykre
> konsekwencje
> np. dla twórców CMSów.

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).

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

>> (np. stylami w MS Word [amatorskie robienie
>> odstępów "enterami" się nie liczy]) IMHO tragedia.
>
> 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 ;)

--
regards, porneL

do góry

Dnia Fri, 06 Jan 2012 00:22:04 +0100, Artur Muszyński napisał(a):

> W dniu 2012-01-05 23:02, Marek pisze:
>> p, ul {
>> margin-top: 0; - zero musi być jako zabezpieczenie przed collapsing margins
>
> Żądamy gwarantowanego odstępu od góry i od dołu niezależnie od tego, z
> jakimi elementami P sąsiaduje. Lepiej widać to na przykładzie Hx. Z
> reguły definiujesz bardzo duży odstęp od góry i sporo mniejszy od dołu.

Zgadza się. I to też powstaje mega-problem gdyż wskutek collapsing margins
odstęp nad znacznikiem P przechodzi nad znacznik H i opuszcza go w dół.
Zmienia on więc swoją pozycję w zależności od treści strony pod nim.

>> Wtedy pomiędzy<div> a<body> tworzy się dziura. Ma to przykre konsekwencje
>> np. dla twórców CMSów.
>
> Przykre? Treści to akurat nie przeszkadza.
>
> -webkit-margin-collapse padding>0 lub border :-)

No ale nie zawsze możemy zastosować border, a raczej prawie nigdy jeśli
robimy coś więcej niż czarny tekst na białym tle :-) Jeśli część grafiki
jest poniżej borderu a druga część - powyżej, to powstaje 1px przerwa.

>
> Pociesz się, że boxing model dla XSL-FO jest jeszcze bardziej pokręcony,
> a przy tym gorzej udokumentowany :-)

he he... już mi lepiej :-D

do góry

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 :-)

do góry

On Fri, 06 Jan 2012 17:54:27 -0000, Marek <p...@s...com> wrote:

>> 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ż ? :)

Nie wydaje mi się, żeby celem CSS było wymaganie nadawania stylów każdej
kombinacji elementów.

Masz kaskadę, dziedziczenie i 40 selektorów po to, żeby ustawić ogólne
reguły a'la "1 linia marginesu nad i pod <p>" i tyle, bez konieczności
dopisywnia "tak, przy <h1> też i przy <h2> i <h3> i <h4> i przy <ul> też i
też jak jest <li> z <p> w środku i tak, też jak jest w <div> i tak samo
jak jest obok <table> i jak jest przy <section> i nawet jak jest lista na
końcu <section> i nawet jak jest pod nim <hr> i... uhhh."

> 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.

Wygląda mi na to, że jak chcesz konkretny odstęp w wewnątrz konkretnego
elementu, to powinieneś użyć padding od początku. Możesz też dać #kontener
> :first-child {margin-top:0 !important;} jak nie chcesz
marginesów-niespodzianek.

> Ale wtedy masz linię przez podzieloną grafikę.

Jaką podzieloną grafikę? Netscape 4 już nikt nie używa.

Poza tym jak ci pasuje dawanie margin-top:-15px do kompensowania braku
zapadania się marginesów, to nie powinno cię ruszać margin-top:-1px dla
ukrycia padding-top:1px.

--
regards, porneL

do góry