Bug ou absurdité normalisée ?

Olivier Miakinen a écrit :

Le 09/12/2007 14:04, Gerard Menvussa a écrit :

Si vous essayez le code suivant dans votre navigateur préféré il y a des
chances que le résultat ne soit pas conforme à ce que défini le style
(marge à 0, padding à 0 les "div" devraient être collés ? Eh bien non).
D'où ma question.

Si, si, les div sont collés. La question consiste à savoir pourquoi la
couleur de fond remplit la marge du h1 quand il y a une bordure au div
et pas quand elle est absente.

Vous remarquerez également que l'espace en haut et en bas n'a rien à
voir avec la valeur définie : 16px...

Olivier Miakinen a écrit :

Le 09/12/2007 15:33, Olivier Miakinen a écrit :

Voici une mise en évidence un peu plus directe du phénomène. Noter que
les valeurs de margin et de padding sur le div n'y ont aucune influence
(chez moi elles sont déjà à 0) mais qu'il faut une marge non nulle à h1
et la présence ou l'absence de bordure au div.

http://www.miakinen.net/vrac/Menvussa/bug.html

Un autre exemple :
http://www.miakinen.net/vrac/Menvussa/bug2.html

Il semblerait que le phénomène soit lié à la fusion ou la non fusion des
marges.

Oui ou alors plus drôle :

http://tetraedre.org/bug2.html

Bref tout cela est un peu décourageant. Surtout lorsqu'on constate que
tous les navigateurs les plus récents sous windows font la même erreur
(Firefox 2, IE 6, Opera 9, Safari 3)

Le web, quelle catastrophe !

Patrick 'Zener' Brunet a écrit :

Bonjour.

"Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> a écrit dans
le message de news: 475bec6f$0$643$426a74cc@news.free.fr...

Gerard Menvussa a écrit :

Si vous essayez le code suivant dans votre navigateur préféré il y a
des chances que le résultat ne soit pas conforme à ce que défini le
style (marge à 0, padding à 0 les "div" devraient être collés ? Eh
bien non).

Tu oublie le margin par défaut du h1. Si tu lui défini un margin
à 0, tes div seront bien collées les unes aux autres.

Tiens, c'est bizarre... et contre-intuitif:

Les Hn comme les P ont une marge (haute et basse) par défaut, et ça me
semble normal :
- qu'un paragraphe se distingue d'un autre par un petit espace
- qu'un titre(sous-titre) se distingue(nt) par un petit espace

Pourquoi le container div hérite-t-il d'une propriété de son contenu ?

Le conteneur n'hérite de rien, c'est bien le Hn ou le P qui, par
défaut, gardent de l'air autour d'eux (cette marge reste bien
l'intérieur du div conteneur)

test :

<div style="margin:0;border:1px solid">
<h1 style="color:red;border:1px solid">titre<//h1>
</div>
<div style="border:1px solid">
<h1 style="margin:0;color:red;border:1px solid">titre<//h1>
</div>

Ou plutôt selon une autre interprétation, pourquoi son background
n'inclut-t-il pas les marges de son contenu ?

Là je ne comprends rien à ce que tu dis.
Tu veux dire :
pourquoi le H1 n'hérite pas des marges prévues par le div contenant ?

Si ça marchait comme ça ce serait vraiment le b...l !
tous les Hn, P et autres, sans plus leurs marges par défaut et à devoir
remettre à chaque fois ? pas glop !

--
sm

Olivier Miakinen <om+news@miakinen.net> wrote:

Le 09/12/2007 15:52, Olivier Miakinen a écrit :
> Un autre exemple :
> http://www.miakinen.net/vrac/Menvussa/bug2.html
> Il semblerait que le phénomène soit lié à la fusion ou la non fusion des
> marges.
Visiblement c'est ça. La bordure du div empêche la fusion de la marge du
h1 avec quelque chose en dehors du div, auquel cas la couleur du fond du
h1 s'étend à tout le div.
Voir par exemple comment la marge du deuxième h1 du premier div fusionne
avec celle du premier h1 du deuxième div, alors qu'une bordure -- même
transparente -- l'empêche (3e et 4e div):
http://www.miakinen.net/vrac/Menvussa/bug3.html

hum...

une tentative d'explication (en anglais) ici :
<http://complexspiral.com/publications/uncollapsing-margins/>
et la mère des sources (en anglais toujours) ici :
<http://www.w3.org/TR/CSS21/box.html#collapsing-margins>

--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|_ =="

denisb a écrit :

Olivier Miakinen <om+news@miakinen.net> wrote:

Le 09/12/2007 15:52, Olivier Miakinen a écrit :

Un autre exemple :
http://www.miakinen.net/vrac/Menvussa/bug2.html
Il semblerait que le phénomène soit lié à la fusion ou la non fusion des
marges.

Visiblement c'est ça. La bordure du div empêche la fusion de la marge du
h1 avec quelque chose en dehors du div, auquel cas la couleur du fond du
h1 s'étend à tout le div.
Voir par exemple comment la marge du deuxième h1 du premier div fusionne
avec celle du premier h1 du deuxième div, alors qu'une bordure -- même
transparente -- l'empêche (3e et 4e div):
http://www.miakinen.net/vrac/Menvussa/bug3.html

hum...

une tentative d'explication (en anglais) ici :
<http://complexspiral.com/publications/uncollapsing-margins/>
et la mère des sources (en anglais toujours) ici :
<http://www.w3.org/TR/CSS21/box.html#collapsing-margins>

Absurdité normalisée donc...

Le 09/12/2007 21:32, Gerard Menvussa a écrit :

Absurdité normalisée donc...

Je ne vois pas bien ce que cette remarque apporte à la discussion. Je
n'ai pas encore lu toute la page d'Eric Meyer, mais il semble que le
phénomène que j'ai constaté suite à ton premier article s'explique
assez bien comme étant un « moindre mal » pour arriver à rendre ce
qui semble naturel dans la plupart des cas.

Le 09/12/2007 20:35, denisb a écrit :

une tentative d'explication (en anglais) ici :
<http://complexspiral.com/publications/uncollapsing-margins/>

Merci pour cette page, qui est très claire (y compris sur la raison qui
a fait choisir ce comportement, par exemple pour les items de listes).

et la mère des sources (en anglais toujours) ici :
<http://www.w3.org/TR/CSS21/box.html#collapsing-margins>

Là par contre je n'y comprends rien. J'avais lu la dernière version
française, mais il s'agit de la traduction de CSS 2 et non CSS 2.1,
et elle est très incomplète :
http://www.yoyodesign.org/doc/w3c/css2/box.html#collapsing-margins

Il n'existe malheureusement pas de traduction en français de la 2.1.

Olivier Miakinen a écrit :

Le 09/12/2007 21:32, Gerard Menvussa a écrit :

Absurdité normalisée donc...

Je ne vois pas bien ce que cette remarque apporte à la discussion. Je
n'ai pas encore lu toute la page d'Eric Meyer, mais il semble que le
phénomène que j'ai constaté suite à ton premier article s'explique
assez bien comme étant un « moindre mal » pour arriver à rendre ce
qui semble naturel dans la plupart des cas.

Je ne suis pas d'accord. Ce qui semble naturel à qui ? Cela ne me semble
en aucun cas naturel c'est tortueux, totalement inutile et la raison
donnée dans le texte de "tentative d'explication" n'est pas valable pour
la raison qu'il est de mon point de vue facile de reproduire l'effet
décrit sans que les marges ne se chevauches. Cela me semble absurde
comme ce que je décrivais dans mon message "la quatrième dimension" et
auquel personne n'a répondu.

J'ai programmer dans plus d'une dizaine de langages et aucun ne m'a paru
aussi ambigüe, illogique, incomplet, incohérent et imprévisible que ce
que je trouve dans le monde du web. Après 7 années de bagarre
quotidienne, je suis véritablement fatigué par toute cette merde
invraisemblable nommée HTML, CSS, Javascript et qui semble donner tant
de fierté à ses concepteurs (et cela en faisant abstraction des
variations d'interprétation entre le client HTTP dominant du marché et
la "norme")

Le 09/12/2007 23:46, Gerard Menvussa a écrit :

Absurdité normalisée donc...

Je ne vois pas bien ce que cette remarque apporte à la discussion.

Je persiste et signe.

Je
n'ai pas encore lu toute la page d'Eric Meyer, mais il semble que le
phénomène que j'ai constaté suite à ton premier article s'explique
assez bien comme étant un « moindre mal » pour arriver à rendre ce
qui semble naturel dans la plupart des cas.

Je ne suis pas d'accord. Ce qui semble naturel à qui ? Cela ne me semble
en aucun cas naturel c'est tortueux, totalement inutile et la raison
donnée dans le texte de "tentative d'explication" n'est pas valable pour
la raison qu'il est de mon point de vue facile de reproduire l'effet
décrit sans que les marges ne se chevauches.

Hum... tout dépend de ce qu'on appelle facile. Sans chevauchement des
marges il faudrait traiter séparément le cas de la marge avant un
premier élément, celui de la marge après le dernier élément et celui
des marges entre les éléments. Et se rappeler bien sûr que dans CSS1
il n'existait ni :first-child ni le sélecteur +.

Cela me semble absurde
comme ce que je décrivais dans mon message "la quatrième dimension" et
auquel personne n'a répondu.

Il y *a* des choses absurdes. Certaines sont certainement l'effet d'une
mauvaise conception au départ, et toutes restent là à cause du besoin de
compatibilité d'une version à l'autre. Mais à quoi bon répondre à un
coup de gueule râlant contre l'absurdité de l'existant ? C'est comme ça
et on doit faire avec.

J'ai programmer dans plus d'une dizaine de langages et aucun ne m'a paru
aussi ambigüe, illogique, incomplet, incohérent et imprévisible que ce
que je trouve dans le monde du web.

Tu dis toi-même que tu as « programmé » dans plus d'une dizaine de
langages, mais HTML et CSS ne sont pas des langages de *programmation*.
Est-ce que parmi ces plus de dix langages il y en a au moins un qui
était déclaratif au lieu d'être impératif ?

Après 7 années de bagarre
quotidienne, je suis véritablement fatigué par toute cette merde

Soit. Tu l'as dit, et j'espère que ça t'a soulagé. Moi aussi j'ai
souvent du mal, surtout quand j'essaye de faire fonctionner des pages
aussi bien dans IE 6 que dans d'autres navigateurs. Mais ta question de
div collés ou pas a une explication, le comportement est reproductible,
et en outre il est facile d'obtenir ce que l'on veut quand on a compris
ce qui se passait.


En conclusion : ta question était utile, elle nous a permis d'avancer
dans la compréhension des choses, mais ton coup de gueule est stérile.

Olivier Miakinen <om+news@miakinen.net> wrote:

Le 09/12/2007 20:35, denisb a écrit :
> et la mère des sources (en anglais toujours) ici :
> <http://www.w3.org/TR/CSS21/box.html#collapsing-margins>
Là par contre je n'y comprends rien.

mouais, c'est pas trop tip top clairfull c't'affaire...


ma version (à deux balles) :


en css 2.1 les marges horizontales ne se superposent jamais.

- deux (ou plus) marges verticales adjacentes d'éléments de type bloc
qui se suivent dans le flux se superposent. l'épaisseur de la marge
résultante et celle de la plus importante des marges adjacentes.
dans le cas de marges négatives, la valeur absolue de la plus grande
marge négative est déduite de la valeur de la plus grande marge
positive.
s'il n'y a pas de marge positive, la valeur absolue de la plus grande
marge négative est déduite de zéro.
note : des boites peuvent être adjacentes sans être dans une relation de
fratrie (élément frêre) ou d'ancestralité (élément parent ou élément
enfant).

- les marges verticales entre boite flottantes ne se superposent pas (ni
celles entre une boite flottante et ses propres enfants).

- les marges verticales d'éléments de propriété 'overflow' autre que
'visible' ne se superposent pas avec celles des enfants de ces éléments.

- les marges de boite positionnées en 'absolute' ne se superposent pas.

- les marges d'éléments 'inline' ne se superposent pas.

- si les marges hautes et basses d'une boîte sont adjacentes, alors il
est possible pour les 2 marges de se superposer (à celles d'autres
boites). Dans ce cas, la position de cet boite dépend de sa relation
avec les autres éléments dont les marges sont superposées aux siennes :
-- si les marges de cette boite sont superposées avec la marge haute
de son parent la position de sa bordure haute sera la même que celle de
son parent ;
-- sinon, soit l'élément parent n'a pas de marge superposée, soit
seule la marge basse du parent est concernée. dans ce cas, la position
de la bordure haute de la boite est celle qu'elle aurait été si la boite
avait eu une bordure haute non nulle.
un élément qui a été passé en 'clear' ne verra jamais sa marge
haute superposée à la marge basse de ses parents.
note: le positionnement d'éléments aux marges superposées n'a aucun
effet sur le positionnement des autres éléments avec lequels leurs
marges ont été superposées ; la position de leur bordure haute n'est
nécessaire que pour le placement d'éléments qui seraient leurs enfants.

- les marges de l'élément racine ne se superposent pas.

la marge basse d'un élément de type bloc dans le flux normal est
toujours adjacente à la marge haute du bloc frêre suivant (dans le flux)
sauf si ce frêre a été passé en 'clear'.

la marge haute d'un élément de type bloc dans le flux normal est
adjacente à la marge haute du premier bloc enfant qui le suit dans le
flux si cet élément (le père) n'a ni 'border-top', ni 'padding-top' et
que l'enfant n'a pas été passé en 'clear'.

la marge basse d'un élément de type bloc affecté d'une 'height:auto' ;
et dont la 'min-height' est inférieure à sa 'height' réelle ; et dont la
'max-height' est supérieure à sa 'height' réelle est superposée aux
marges basses sera adjacente à la marge basse de son dernier enfant si
cet élément n'a ni 'padding-bottom', ni 'border'.

les propres marges d'un élément sont adjacentes s'il possède une
'min-height:0' ; et qu'il n'a ni 'border-top', ni 'border-bottom', ni
'padding-top', ni 'padding-bottom' ; et qu'il a une 'height:0' ou
'height:auto' ; et qu'il ne contient pas de boite en ligne ; et que
toutes les marges de ses éléments enfants (s'il en a) sont adjacentes.

quand les propres marges d'un élément se superposent et que sur cet
élément un 'clear' a été appliqué, sa marge haute se superpose avec les
marges adjacentes de ses éléments frêres mais cette marge résultante ne
se superpose pas avec la marge basse du bloc parent.

la superposition se base sur les valeurs passées à 'padding', 'margin'
et 'border' (c'est-à-dire après la résolution des divers pourcentages).
la valeur de la marge superposée est calculée en fonction des valeurs
affectées aux différentes marges.

pour une illustration et des exemples, voir :
<http://www.w3.org/TR/CSS21/box.html#mpb-examples>


--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|_ =="